canli-mcp

Financial statements as filed

financial_statements

Read-onlyIdempotent

Extract a company's income statement, balance sheet, cash flow and equity lines as filed in 10-K/10-Q filings, join periods, and show restated or split-adjusted figures beside first-reported values.

Instructions

A company's financial statements exactly as filed: income statement, balance sheet, cash flow and equity statement from its 10-K (or 10-Q), with its own line labels, each line's XBRL concept and the values as the filing shows them (units say the scale). Joins several filings by period; a line a later filing restated, or that a stock split changed, is shown beside its first-reported figure, never mixed in. Use it for every line in the company's own words; history for one measure over many years.

Input Schema

Name	Required	Description
`period`	No	annual (10-K, default) or quarterly (10-Q: each quarter and the year to date; the fourth quarter is only in the 10-K's year).
`company`	Yes	Ticker (AAPL), CIK (320193) or name (Apple).
`filings`	No	How many 10-Ks (or 10-Qs) to read and join by period, newest first; default 1. One 10-K holds three years of income and cash flows and two balance sheets, so 2 covers four years and 3 covers five.
`accession`	No	Start from this filing.
`statement`	No	Which statement: income, balance_sheet, cash_flow, comprehensive_income, equity; core (default) is the first three, all is every one.
`fiscal_year`	No	Start from the 10-K for the fiscal year ending in this calendar year (or the latest 10-Q of it).
`filed_before`	No	Start from the latest filing on or before this date: what was known then.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 30, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations (which only say read-only, idempotent, open-world) by disclosing the hard parts: filings are joined by period, restated lines and split-adjusted figures appear beside their first-reported value and are never mixed in, and units carry the scale. This is exactly the context that prevents misreading the output.

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 what the tool returns, then the joining/restatement behavior, then the routing sentence. Dense but nearly every clause earns its place; the parenthetical '(units say the scale)' is slightly cryptic phrasing but still informative.

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 7 parameters, an output schema, and strong annotations, the description covers the tool's distinctive data-fidelity behavior and its main alternative. Defaults and enum detail are left to the schema, which is appropriate; nothing critical is missing for correct invocation.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter is already documented in the schema (period, filings, statement, fiscal_year, filed_before). The description only gestures at 'joins several filings by period' and '10-K (or 10-Q)' without adding syntax or semantics beyond the schema. Baseline 3 applies.

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 concrete resource (income statement, balance sheet, cash flow, equity from a 10-K/10-Q) with the exact fidelity it returns (own line labels, XBRL concepts, filed values). It also contrasts itself with the `history` sibling ('history for one measure over many years'), so an agent can pick the right tool 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 Guidelines4/5

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

Explicitly routes: 'Use it for every line in the company's own words' vs `history` for a single measure over many years. It implies the when-not case without spelling out exclusions (e.g., no ratio/computed metrics, no cross-company comparison).

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

Deploy Server