Skip to main content
Glama

FinancialMD

Screen all companies

screen
Read-onlyIdempotent

Screen every covered company on its latest period: range filters on metrics, a sort and paging, all applied on the server over the whole universe. A metric is a standardized concept id (from metrics_list, for example income_statement_total_revenues) or a ratio id (gross_margin, operating_margin, net_margin, fcf_margin, revenue_growth_yoy, roe, roa, asset_turnover, current_ratio, debt_to_equity, interest_coverage, eps_basic, eps_diluted, bank and insurer ratios) or a valuation id (market_cap, enterprise_value, pe_ttm, ps_ttm, pb, ev_ebitda_ttm, ev_ebit_ttm, fcf_yield, dividend_yield: the latest IEX close times the screened period, so use period_type ltm for trailing multiples). Filter bounds are raw values: 0.2 is 20 percent, amounts are in the reporting currency. A company with no value for a filtered metric does not match; when sorting, missing values come last. Each item has the company (with sector and industry), the period screened and one value object with proof per metric, so every number can be cited. data.total is the size of the whole match and data.next_cursor pages through it. as_of screens on what was known on a date. Metered call: 1 of 25 keyless calls a day. Free through this connector within the keyless limits; the per-call price on agent.financial.md is $0.05. Use it to find or rank companies by fundamentals or valuation instead of calling each company in turn. If a dataset, field, company or analysis you need is missing, call request_data.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "limit": 20,
      "filters": [
        {
          "min": 0.2,
          "metric": "net_margin"
        }
      ],
      "sort_by": "roe",
      "sort_dir": "desc"
    },
    "name": "screen"
  }
}

Input Schema

NameRequiredDescriptionDefault
as_ofNoKnowledge date or timestamp (YYYY-MM-DD or RFC 3339). The answer is what FinancialMD knew at that instant: only facts whose known interval contains as_of. Omit for the current view.
limitNoMaximum number of periods or items to return (default 25, at most 200).
queryNoOptional name or ticker search to narrow the universe.
cursorNoOpaque cursor from a previous page (data.next_cursor).
sectorNoOptional exact sector (case-insensitive).
countryNoOptional ISO 3166-1 alpha-2 country code.
filtersNoRange filters, all of which must hold. Give min, max or both (inclusive, raw values).
metricsNoColumns to return: concept ids or ratio ids (default: revenue, net income, the three margins, revenue growth, return on equity).
sort_byNoA metric id, "name" or "ticker" (default name).
industryNoOptional exact industry (case-insensitive).
sort_dirNoSort direction (default asc).asc
period_typeNoWhich latest period to screen: annual (default), quarterly or ltm.annual

Output Schema

NameRequiredDescriptionDefault
dataNo{ items: [{ company { fmd_id, cik, name, country, reporting_template, primary_ticker, primary_mic, sector, industry }, period, values: { <metric id>: value object or null } }], next_cursor, period_type, metrics: [{ id, kind, label, metric_format, formula }], sort, total, universe }.
metaNoRequest metadata: request_id, as_of, company resolution, coverage, pipeline_version, licence, terms, proof_base.
errorNoPresent only on isError results: the API error code and message plus remedy hints.

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?

Beyond the readOnly/idempotent annotations, it discloses match semantics ('A company with no value for a filtered metric does not match'), sort behavior for missing values, per-metric proof objects, pagination via data.total/data.next_cursor, as_of point-in-time semantics, and metering (1 of 25 keyless calls a day, $0.05 per call). These are exactly the operational facts an agent needs before invoking a metered bulk query.

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?

Purpose is front-loaded and every clause carries information, but the middle is a single dense run-on block enumerating ~20 ratio and valuation ids, which is hard to scan. Bullet-like separation or trimming the longer id lists (already discoverable via metrics_list) would improve it.

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?

An output schema exists, yet the description still explains the response envelope and pagination, and it covers the non-obvious pitfalls (percent scaling, missing-value matching, point-in-time as_of) for a 12-parameter tool. Nothing an agent needs to call this correctly is absent.

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

Parameters4/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 adds real meaning: the metric namespace split into concept ids, ratio ids (with named examples), and valuation ids with the IEX-close-times-period rule, plus the critical scale note that 0.2 means 20 percent and amounts are in reporting currency. It stops short of explaining query/sector/country/industry filters or the limit ceiling, which the schema already covers.

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?

Opens with a specific verb and scope: 'Screen every covered company on its latest period' with server-side range filters, sort, and paging over the whole universe. That is clearly distinguishable from per-company siblings like financials_standardized or company_kpis.

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

Usage Guidelines5/5

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

Explicitly routes the agent: 'Use it to find or rank companies by fundamentals or valuation instead of calling each company in turn,' points to metrics_list for concept ids, and names request_data as the fallback when data is missing. It also gives a concrete selection rule for period_type ('use period_type ltm for trailing multiples').

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