Skip to main content
Glama

Run a market screen

run_screen
Idempotent

Runs a market screen on Sortefi and returns the symbols that match now. Sortefi screens US stocks, Indian NSE stocks, ETFs, forex pairs and crypto perpetual futures, on timeframes from 1 minute to monthly, with technical indicators, candlestick and chart patterns, price maths and fundamentals. Sortefi reads the request with its own rules and returns what it screened in plain English, the matching symbols and a link to the saved result. Requests that are not screens (advice, forecasts, trade setups) are declined. Runs on the user's Sortefi account: each completed screen is charged — a free screen if the account has one left, otherwise wallet credits, about 20 credits on average (1 credit = $0.01, or ₹1 on accounts topped up in rupees). The result states what was charged and the balance left. Follow-up questions and declines are free.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "screen_request": "<screen_request>",
      "market": "<market>"
    },
    "name": "run_screen"
  }
}

Input Schema

NameRequiredDescriptionDefault
marketYesUS_EQUITY = US stocks, INDIA_EQUITY = Indian NSE stocks, ETF = US-listed ETFs, FOREX = currency pairs, CRYPTO_PERPS = crypto perpetual futures (Binance, HyperLiquid).
screen_requestYesThe screening request in the user's own words, with the timeframe, market, indicators and thresholds exactly as they stated them. When answering a Sortefi follow-up question: the original request followed by the user's answer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: credit-based charging (~20 credits, or a free screen if one remains), that declines and follow-ups are free, and that the response carries what was charged and the remaining balance. One mild tension with idempotentHint=true: repeating an identical call still consumes a free screen or wallet credits, which the description does not reconcile.

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

Conciseness5/5

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

Front-loads capability and scope, then declines, then cost — a sensible order with no filler. The billing detail is verbose but every clause (rate, free-screen rule, currency note) answers a question the agent would otherwise get wrong.

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

Completeness5/5

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

Although there is no output schema, the description states what comes back (plain-English explanation, matching symbols, link, charge and balance), what is refused, and the account prerequisite. Nothing an agent needs in order to decide and call correctly is missing.

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 coverage is 100%, so both parameters and the market enum are already fully documented. The description adds that the request is interpreted by Sortefi's own rules and that follow-up answers should be appended to the original request, but it gives no guidance on phrasing, format or length of screen_request.

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?

Opens with a precise verb+resource+scope: runs a screen and returns matching symbols "now", then enumerates supported markets, timeframes and signal families. It never names the sibling get_screen_result, so the agent must infer the split between running a screen and fetching a prior result from "a link to the saved result".

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?

Gives explicit negative guidance — advice, forecasts and trade setups are declined — and covers the follow-up-answer case, which tells the agent how to phrase screen_request on a retry. It stops short of stating when to use get_screen_result instead of re-running a screen.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources