Build a Scanning Agent
An AI agent with scanr.ai can answer questions like "which beaten-down large caps are starting to turn up, and which of them are in strong sectors?" by building a scan, running it and reading the results. This guide covers the two ways to get there, and the design choices that make the agent reliable.
Option 1: no code, with MCP
If the agent is Claude Code, Claude Desktop, Cursor, VS Code or Codex, connect the MCP server and install the Agent Skill. The client gets the scan tools, and the skill tells the model how to use them. Then ask:
Find stocks above their 200-day moving average with RSI under 35 and market cap over $5B. Show me what the scan checks before you run it.
That covers most interactive use. Build your own agent when you need it inside your product, on a schedule, or with tools the MCP server doesn't have (relative strength, themes, your own data).
Option 2: your own agent
The agent below uses the Claude API with four tools over the scanr.ai REST API. The model decides when to call them; the SDK's tool runner handles the loop.
Design the tools around the workflow
The tools mirror the reliable scanning workflow (generate → refine → run → enrich), and two design choices matter more than anything else:
- The model never writes payload JSON.
natural_scanandrefine_scanproduce payloads on the server, and the agent stores them and hands the model a short payload id. The model passes ids between tools instead of re-typing large JSON, which is where agents otherwise introduce errors. - Results are trimmed before the model sees them. A broad scan can match a thousand tickers.
run_scanreturns the count and the first 50 in sort order, which is what the model needs to reason with.
The code
Run it with SCANR_API_TOKEN and ANTHROPIC_API_KEY set. A typical run makes one natural_scan call, sometimes a refine_scan, one run_scan and one relative_strength call: a few scanr.ai requests and a few thousand AI credits. The relative_strength tool needs a Power User or Business token; on Starter, leave it out.
Adapting it
- Other frameworks. The four functions are plain HTTP calls. Wrap them as tools in any agent framework, or generate them from the OpenAPI spec.
- More tools. Useful additions are market status (
GET /misc/market-status), security search (GET /stocks/search-securities) for resolving company names, theme performance (Business) for "which groups are leading?", and saving a scan (POST /scan/save-filters) so the user can follow it. - Payloads from the scanner. Users often have the screen already. Add an
import_scantool that takes JSON the user exported from the scanr.ai scanner (Filters → Export filters), stores it withremember(), and returns a payload id. Refine and run it like a generated one, with no AI credits. - Hand-written payloads. If you want the model to write payloads directly (for full control, or to skip AI credits), give it Building Scan Payloads as context and a
run_payloadtool that accepts JSON, and return the API's400messages to it verbatim. It works, but expect more retries than withnatural_scan. - Scheduled agents. Run
ask()from a scheduler after the close for a daily written briefing; see Run an End-of-Day Screen.
What makes these agents reliable
- One scan, not a crawl. Agents left alone sometimes loop over tickers calling per-stock endpoints. The system prompt and tool descriptions steer them to scan first; keep it that way.
- Show the screen before the result. Having the agent say what the scan checks catches misreadings ("small caps" read as under $2B when the user meant under $300M) before they turn into confident wrong answers.
- Treat errors as instructions. Return scanr.ai's error text to the model. A
400names the bad field; a429means stop and wait. - Give it its own token. A dedicated,
read-only token makes the agent's usage visible under API Usage and easy to revoke.


