FILTRIX.net

scan_market

Read-onlyIdempotent

Run filters over the live market right now (or the filters of one of your scanner windows with monitor_id): matching symbols with symbol plus fields (default price, gap %, change %, volume), the filter columns and the sort column. limit max 100. Needs a Pro plan (check get_scanner_status first). For historical statistics of a setup use run_backtest.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "scan_market"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Symbols per page, 1..100.
`fields`	No	Scanner columns to return per symbol (from search_scanner_columns); default price, gap %, change % and volume.
`offset`	No	Number of symbols to skip, for paging.
`filters`	No	Live conditions, AND-joined. Column names come from search_scanner_columns, not search_filters.
`order_by`	No	Scanner column to sort by (from search_scanner_columns); an unknown column sorts by symbol.	symbol
`descending`	No	Sort from the highest value down instead of ascending.
`monitor_id`	No	Use the filters of this scanner window of yours (from list_scanner_monitors).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already establish read-only, idempotent, non-destructive and open-world behavior, so the description's extra value is the Pro-plan gate and the 100-result cap, both genuinely useful. It does not describe paging behavior beyond the cap, rate limits, or what happens with an invalid monitor_id; with annotations covering the safety profile, this is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with what the tool does, followed by what gets returned, the limit, the plan prerequisite and the alternative. Slight redundancy with the schema on 'limit max 100' and the default fields, but no wasted preamble.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, paginated screening tool with an output schema and full annotation coverage, the description covers purpose, plan gating, result cap, default projection and the historical alternative. Nothing an agent needs to call it correctly is missing, though the relationship to screen_tickers remains unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented, including filter value_type and operator semantics. The description only restates the default field set ('price, gap %, change %, volume'), the limit cap, and monitor_id's meaning, all of which the schema also states, so it adds little beyond the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: it runs filters over the live market and returns matching symbols with symbol, requested `fields`, filter columns and sort column. It clearly distinguishes itself from run_backtest (historical), but never mentions the similarly named siblings screen_tickers or get_scanner_matches, so an agent must still infer that boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete when-to-use context (live market 'right now', or a saved scanner window via monitor_id), a prerequisite ('check get_scanner_status first' for Pro plan), and an explicit alternative ('For historical statistics of a setup use run_backtest'). It stops short of ruling out the other screening siblings, which is the main remaining ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All FILTRIX.net tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?