FinancialMD

Facts of one filing

filing_facts

Read-onlyIdempotent

Return every fact one filing tagged that maps to a FinancialMD concept, across all statements in one call: income statement, balance sheet, cash flow and supplemental (share counts, per-share figures), each in display order with the newest period first. Each fact is a value object with the filer's XBRL taxonomy, tag and dimensions, the concept it maps to, its label, and a proof pointing at the page and anchor in the filing. Prior-year comparatives printed in the filing are included (their fiscal labels are null). Tags without a mapping (company extensions) are not included. Use it to read a filing end to end instead of calling financials_as_reported once per statement. Filing-layer read: served with generous limits on every tier. 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": {
      "accession": "0000320193-24-000123"
    },
    "name": "filing_facts"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum number of periods or items to return (default 2000, at most 5000).
`accession`	Yes	SEC accession number in dashed form, for example 0000320193-24-000123.
`statement`	No	Optional: only facts of this statement.

Output Schema

Name	Required	Description
`data`	No	{ filing (summary, company, fact_count), statements: [{ statement, facts: [value object + taxonomy, tag, dims, is_instant, label, concept_id, display_order, is_subtotal] }], returned, truncated }.
`meta`	No	Request metadata: request_id, as_of, company resolution, coverage, pipeline_version, licence, terms, proof_base.
`error`	No	Present only on isError results: the API error code and message plus remedy hints.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the read-only/idempotent annotations it discloses real behavior: results are in display order with the newest period first, prior-year comparatives are included but carry null fiscal labels, and each fact carries a proof pointer to the page and anchor. It even flags the access tier ('generous limits on every tier'), which the annotations do not cover.

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?

It is front-loaded with the core purpose and every clause carries information (ordering, inclusion rules, alternative, fallback). The opening sentence is long and clause-stacked, which slightly hurts scannability, but there is no filler.

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 an output schema exists, the description need not detail return payloads, yet it sketches the value-object shape and the proof pointer anyway. Ordering, coverage boundaries, sibling relationship and the missing-data escape hatch are all present.

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 earns more by explaining what the opaque 'supplemental' enum value contains (share counts, per-share figures) and by clarifying that omission of 'statement' means all statements. The limit parameter is still only explained by the schema, not the prose.

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 opening states a specific verb and resource (return every fact one filing tagged that maps to a FinancialMD concept) plus the scope of coverage (all statements in one call). It enumerates the statements covered and explicitly contrasts with financials_as_reported, so an agent can distinguish it from siblings without opening a schema.

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?

It gives an explicit use case and alternative: 'Use it to read a filing end to end instead of calling financials_as_reported once per statement.' It also states an exclusion rule (unmapped extension tags are not included) and a fallback path (call request_data if something is missing).

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

All FinancialMD 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?