FiatDock

Company financials from SEC XBRL ($0.0045)

company_financials

Read-onlyIdempotent

PAID ($0.0045 USDC via x402). A US-listed company's financials as it filed them with the SEC (XBRL company facts), by ticker (AAPL, BRK-B) or CIK: for its last 1-12 fiscal years (10-K) or three-month quarters — revenue, net income, diluted EPS, total assets, total liabilities, stockholders' equity, cash, operating cash flow, shares outstanding — each with the us-gaap tag it came from, the fiscal year/period and the filing. Restatements win; a value the company did not tag is null, never computed (no derived Q4). US-GAAP filers only (not IFRS). An unknown ticker or an SEC outage answers 404/502 and is not charged. Public-domain data, not investment advice. Without payment this returns the 402 challenge; the fiatdock-mcp npm package pays automatically. Any answer the tool cannot produce is >= 400 and is NOT charged.

Input Schema

Name	Required	Description
`limit`	No	How many periods, newest first, 1-12 (default 4)
`period`	No	annual (fiscal years, from 10-K filings; default) or quarterly (three-month periods)
`ticker`	No	Stock ticker (AAPL, MSFT, BRK-B) or the company's SEC CIK number
`payment`	No	Base64 of a single x402 v2 PaymentPayload (EIP-3009 transferWithAuthorization on Base USDC). OMIT it on the first call: the 402 you get back carries `howToPay.payloadTemplate` — the exact envelope to fill in — plus the price and the EIP-712 domain. Send it on the second call to complete the purchase; it is forwarded as the PAYMENT-SIGNATURE header, never as body data. Nothing is charged for the 402 itself, and a call that fails after payment settles nothing.

Output Schema

Name	Required	Description
`asOf`	Yes	ISO time EDGAR was read (cached reads keep their read time)
`note`	Yes	The selection rules, the limits, and the licence
`period`	Yes	annual (fiscal years) or quarterly (three-month periods)
`source`	Yes	Where the data came from
`company`	Yes	The registrant: name, 10-digit CIK, ticker
`periods`	Yes	The periods, newest first; a value the company did not tag for that period is null
`concepts`	Yes	For each field: the us-gaap tags in fallback order, and the ones this answer used
`currency`	Yes	USD — only US-dollar facts are read (EPS in USD per share, shares as a count)
`defaulted`	No	Present only when the body named no field: which company the answer is for, and why

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, openWorld, idempotent), yet the description adds substantial non-obvious behavior: paid operation, restatements win, untagged values are null and never computed (no derived Q4), unknown ticker/outage returns 404/502 uncharged, and the full 402-then-pay flow. This is far beyond what structured fields convey.

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-loads the price and the resource, and most sentences carry distinct operational facts. It is dense and somewhat long, and the payment flow is restated in both the description and the `payment` schema property, which is mild redundancy.

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?

For a paid, open-world data tool with an output schema already defining return shape, the description covers everything an agent needs: pricing, auth/payment flow, scoping, null/restatement semantics, and error/charging behavior. Nothing material is missing.

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; the description goes further by giving ticker formats (AAPL, BRK-B), the period semantics (annual 10-K vs three-month quarters), and the two-call payment protocol for the `payment` param. It largely mirrors rather than extends the already-detailed schema text, keeping it at 4.

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?

States a specific resource ('A US-listed company's financials as it filed them with the SEC (XBRL company facts)') with the exact line items returned and the two lookup keys (ticker or CIK). It is clearly distinguishable from the sibling sec_filings, which would return raw filings rather than normalized per-line-item facts.

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?

Gives concrete scope conditions: last 1-12 fiscal years (10-K) or three-month quarters, US-GAAP filers only (not IFRS), and the payment prerequisite. It does not name a sibling alternative (e.g. sec_filings) or state when-not-to-use, so it stops short of a 5.

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

All FiatDock 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.