Skip to main content
Glama
Sign In

autario-mcp

by io.github.Autario
OverviewDiscussionsAdmin

screen_stocks

Read-onlyIdempotent

Screen and rank the covered US companies (and the other stocks with a daily price series) by fundamentals and price technicals, from daily snapshots built on SEC filings and adjusted daily closes. Use this for questions like "fastest growing companies", "most profitable", "cheapest by earnings yield", "stocks below their 200-week moving average", "near a 52-week low", or to pull a screen for a backtest (as_of = a past day). A company without every input of the screen is not listed (never ranked as zero). Every row links its company page and source datasets.

Presets: growth (mean percentile of 1-year revenue and EPS growth), profitability (net margin), value (earnings yield), near-52-week-high, near-52-week-low, below-200-week-ma. most-held-by-13f (how many tracked investors list the company on their latest Form 13F). Planned, not answerable yet: dividend, insider-buying. Filter and sort columns: revenue_growth_1y, eps_growth_1y, net_margin, growth_score, earnings_yield, pct_from_52w_high, pct_from_52w_low, pct_vs_200w_ma (percent), holders_13f (count).

Examples:

  • "Fastest growing companies?" | preset="growth", limit=10

  • "Profitable stocks below their 200-week MA" | filters={"net_margin":{"min":10},"pct_vs_200w_ma":{"max":0}}, sort="pct_vs_200w_ma"

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": "screen_stocks"
  }
}

Input Schema

NameRequiredDescriptionDefault
sortNoColumn to order by (default: the rank column of the preset)
as_ofNoYYYY-MM-DD: the newest daily snapshot on or before this day (for backtests). Default: the newest.
limitNoRows to return (default 25, max 200)
orderNoasc | desc (default: best first)
formatNoOutput wire format for this MCP call. Default 'toon' (Token-Oriented Notation, fewest tokens, best for tabular rows). 'compact' = minified JSON. 'json' = pretty JSON for readability. The REST API always returns JSON regardless.
presetNogrowth | profitability | value | near-52-week-high | near-52-week-low | below-200-week-ma | most-held-by-13f
filtersNoColumn ranges, e.g. {"net_margin":{"min":10},"pct_vs_200w_ma":{"max":-20}}. A row without the column is excluded.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only cover safety (readOnly, idempotent, closed-world); the description adds the non-obvious rule that a company missing any screen input is excluded rather than ranked as zero, plus row-level linking to company pages and source datasets. It also discloses that results come from daily snapshots built on filings and adjusted closes, which tells the agent about freshness and provenance.

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?

Front-loaded with purpose, then preset semantics, then column vocabulary, then worked examples — a sensible information hierarchy with no filler sentences. Minor redundancy: the preset list and the as_of/limit semantics are restated from the schema enum and property descriptions.

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?

Seven optional parameters, a nested filters object and no output schema raise the bar, and the description addresses it: exclusion behavior for incomplete rows, preset ranking logic, valid column names, and row payload (company page plus source dataset links). An agent can construct a valid call and predict the row shape without further help.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes well beyond it: it defines what each preset computes (growth = mean percentile of 1-year revenue and EPS growth, profitability = net margin, value = earnings yield, most-held-by-13f = count of tracked 13F filers) and enumerates the valid filter/sort columns with units (pct_vs_200w_ma in percent, holders_13f as a count). That column vocabulary is not derivable from the schema's free-form filters object.

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

Purpose5/5

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

"Screen and rank the covered US companies ... by fundamentals and price technicals" states a specific verb plus resource and scope (cross-company ranking, not single-entity lookup), which separates it from siblings like get_company_fundamentals and who_holds. The data substrate (daily snapshots from SEC filings and adjusted closes) is named up front.

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?

Names concrete question shapes it answers ("fastest growing companies", "cheapest by earnings yield", "stocks below their 200-week moving average") and explains the backtest usage via as_of. It also flags what is not answerable yet (dividend, insider-buying), which is a genuine negative condition. It never names a sibling alternative, so it stops short of explicit routing.

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

All autario-mcp toolsInspect
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