Skip to main content
Glama

OptimistFi

screen

Read-only

Screen the market for companies that match a condition, returned ranked. kind selects the screen, and which arguments apply: - "universe" (aliases: metric, rank): rank every filer by a reported metric (e.g. revenue, net_income, assets), over period. - "valuation" (aliases: value, cheap): rank by a ratio (e.g. pe_ratio, ev_to_ebitda, price_to_book), bounded by min_value/max_value; multiples sort cheapest first. - "buybacks" (aliases: buyback, repurchases): which companies bought back the most stock — spent=True is cash actually spent, False is the amount authorised. - "filings" (aliases: filing_events, events, 8-k): companies that filed a form ("8-K", "SC 13D") or a specific 8-K item code (e.g. "5.02" a leadership change, "2.01" a completed acquisition). - "watchlist" (aliases: list): filter a supplied list of entities by a criteria dict (e.g. insider_buying, congress_buying, catalyst_within_days, rsi_below). - "cheap_insiders": companies under max_pe where an insider bought on the open market within the last days (default 90). Joins the valuation and insider stores. - "insider_before_event": insider open-market purchases that preceded an 8-K by the same company within days (default 30); item narrows to an 8-K item code. - "congress_before_upgrades": Senate purchases followed by an analyst upgrade in the same ticker within days (default 45). since bounds how old a filing may be; days/max_pe tune the cross-source screens; limit caps the rows. Read the coverage note returned with the rows: the store fills over time, so a ranking is over the companies read so far.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNo
formNo8-K
itemNo
kindNouniverse
limitNo
ratioNope_ratio
sinceNo
spentNo
max_peNo
metricNo
periodNoannual
criteriaNo
entitiesNo
max_valueNo
min_valueNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only provide readOnlyHint: true, so the description carries the behavioral burden and does so richly. It discloses ranking semantics, cheapest-first sorting, `spent=True` semantics, cross-store joins, default time windows, and the coverage-note caveat about partially filled data.

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?

The description is long but appropriately so: 9 modes and 15 parameters require this level of detail. It is front-loaded with a one-sentence purpose, then organized into scannable bullet points, and every sentence adds operational value.

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?

Given the high complexity and the polymorphic `kind` parameter, the description covers mode selection, parameter applicability, defaults, and even the data-coverage caveat. An output schema exists, so return-value documentation is not needed, and nothing essential is missing for calling this tool correctly.

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 description coverage is 0%, so the description must document parameters, and it does: kind, metric, period, ratio, min/max_value, form, item, entities, criteria, days, max_pe, spent, since, and limit are all explained with examples and defaults. This fully compensates for the empty schema.

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?

The description opens with a specific verb+resource ('Screen the market for companies that match a condition, returned ranked') and then enumerates distinct modes via `kind`. It clearly distinguishes this from sibling get_* tools and even disambiguates internal aliases.

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?

The description gives explicit guidance on selecting a `kind` and which arguments apply to each mode, with examples and defaults. It doesn't explicitly name sibling alternatives or say when not to use this tool, but the mode-by-mode context makes intended usage clear.

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