Introducing Scanner: From a Market Question to a Research Shortlist

A research run starts with a choice: which symbols deserve a closer look? When that choice lives only in a conversation, it is difficult to explain, repeat, or compare with the next attempt.

Scanner brings that first step into Algo Trade Analytics. Define a universe, describe the conditions you want to investigate, and inspect the results alongside their data coverage. You can build a screen with visual filters or write a custom Python screen when the question needs more flexibility.

Availability: Scanner and custom Python are available in environments where those capabilities are enabled. Scheduled monitoring has its own availability setting. If Scanner is unavailable in your workspace, contact support before following the walkthrough.

The current integrated Scanner uses historical US equity bars, including supported ETFs, from your linked Alpaca account. Connect a working Alpaca account with access to the required history before calibrating or running a screen.

Start with a question and an explicit universe

A useful screen begins with a question such as, “Which symbols in my list are above a moving average and have stronger recent volume?”

Choose an explicit symbol list or use the symbols from your Case Studies. Set the historical lookback and the completed session you want to inspect. The current integrated Scanner works with daily bars; it is not a live intraday alert feed.

This makes the selection process inspectable. You can see which universe was considered, which rule was used, and where data was missing. A match is a reason to investigate a symbol, not proof that a trading strategy will make money.

Two ways to express the same research question

The visual builder lets you choose fields, edit filter chips, and combine conditions in ALL and ANY groups. Start from a template or build your own screen, then save it for another run. The Python button reveals a read-only declaration of the visual rule, so you can inspect what the controls represent.

Custom Python is a separate screen type. It has an editable source file and parameters, with an evaluate(ctx) function for each symbol and an optional rank(universe) function for comparisons across the supplied universe. NumPy and pandas are supported in the custom runtime.

The distinction is deliberate: visual controls own the generated declaration; an editable Python screen owns its code. Selecting New Python screen starts an independent program. The product does not promise to translate arbitrary Python back into filter chips.

Inspect a result before acting on it

The results grid separates matches, nonmatches, unavailable data, and execution errors. Open a symbol to inspect its retained chart, computed values, and explanation. A missing-data row should not be mistaken for a symbol that failed your rule.

Saved runs retain their definition and scope. Editing today's screen does not rewrite yesterday's result. History and CSV or JSON downloads help you compare what was actually run, while the result drawer keeps the detail close to the shortlist.

When runs have a compatible definition, the comparison can show which symbols entered or exited the matched set. Symbols without conclusive coverage on both sides are excluded from those changes. That prevents a data outage from looking like a market event.

Check Python, then try a small sample

Custom Python has two different checks:

1. Check examines the source and parameters against the supported policy. It does not execute the program.
2. Save & calibrate executes a sample of up to ten symbols, reports runtime errors and resource use, and estimates the credit cost of a full run.

The sample helps you catch a broken calculation or an expensive ranking step before scanning the full universe. It is not a test of predictive value. In the app, calibration uses the latest completed session; an MCP client can explicitly request a historical calibration date inside its research scope.

Custom code receives the supplied bars and parameters inside a bounded runtime. It cannot fetch arbitrary external data, install packages, or use the filesystem as an unrestricted research environment. Full Python runs use credits; review the displayed quote before running. Visual-rule runs do not use Python execution credits.

Use the same saved screens with an MCP agent

An MCP client can inspect the available fields, create a screen, queue a run, and retrieve the saved results. You can review those same records in the Scanner page instead of relying only on an agent's summary.

Research access keeps its data boundaries. The agent must have an active research run, and the full scanner lookback must fit its authorized development window. Previously saved results and the baseline behind a comparison are checked too. Scanning another symbol does not make reserved research dates available.

For recurring monitoring, use the Scanner page's daily or weekly schedule controls where enabled. An MCP research client uses explicitly dated runs; it can disable a schedule but cannot enable recurring monitoring.

Turn a shortlist into a testable idea

Suppose several symbols meet your trend and volume conditions. The next useful question is whether that pattern suggests a specific entry, exit, and holding-period hypothesis. Take that question into Algo Lab and evaluate it with realistic costs and the existing evidence checks.

Scanner helps explain where an idea came from. A shortlist alone does not establish an edge, place an order, or promote a strategy.

Follow the Scanner quick start, write your first Python screen, or connect the workflow to MCP and monitoring.

If Scanner is enabled in your workspace, open Scanner to build your first saved screen.