Skip to main content
Glama
filing-agent

filing-agent

by chensirui3

xbrl_get_facts

Read-only

Retrieve reported XBRL values for a company concept from 10-K and 10-Q filings, with exact periods, fiscal-year labels, restatement flags, and filters for period type and fiscal year.

Instructions

Reported values of one XBRL concept from the company's 10-K and 10-Q filings (SEC API). Each value has its exact period (start, end), period type (annual, quarter, ytd, instant), the company's own fiscal-year label, the filing it came from, and a restated flag. Values are in whole units ('display' shows the scale: 1577000000 USD is 1,577 million USD). Filter by fiscal_year and period. Returns values as first reported unless policy is 'latest'.

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": {
      "company": "<company>",
      "concept": "<concept>"
    },
    "name": "xbrl_get_facts"
  }
}

Input Schema

NameRequiredDescriptionDefault
periodNoannual, quarter, ytd (year to date), instant (balance sheet) or any.
policyNoValue as first reported (default) or the latest restatement.
companyYesCompany name, ticker or CIK.
conceptYesConcept from xbrl_find_concepts, e.g. us-gaap:Revenues.
fiscal_yearNoThe company's own fiscal-year label.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare this a safe read (readOnlyHint=true, destructiveHint=false), so the description's real contribution is the return-shape disclosure: per-value period start/end, period type, fiscal-year label, source filing, and restated flag. It also discloses the unit convention ('whole units') and the default first-reported policy, which materially affects interpretation. It stops short of anything on result volume, ordering, or rate/error behavior for the SEC API.

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?

Four dense sentences, front-loaded with what the tool returns, then the per-value fields, then the unit convention, then the filtering and policy defaults. Every sentence carries information an agent needs; there is no filler or redundancy.

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

Completeness4/5

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

With no output schema, the description carries the burden of describing return values and does so well, enumerating the per-value fields and unit scale. The remaining gap is operational: nothing about how many values come back, whether they are ordered by period, or what an empty result means.

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 baseline is 3; the description earns above baseline by explaining the practical effect of 'policy' (first reported by default, 'latest' picks the restatement) and by framing fiscal_year/period as filters over the returned values. It adds interpretive context rather than merely restating enum labels.

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 sentence names a specific verb and resource ('Reported values of one XBRL concept') and scopes the source corpus to the company's 10-K and 10-Q filings. It also distinguishes itself from the concept-discovery sibling by tying the 'concept' input to xbrl_find_concepts, so an agent knows this tool retrieves values rather than finding concepts.

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

Usage Guidelines3/5

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

The description states the filtering axes ('Filter by fiscal_year and period') and the restatement policy switch, which implies how to narrow results. However, it never says when to use this tool versus siblings like calculate or list_filings, nor does it state prerequisites such as resolving a company first.

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