Yahoo Finance MCP Server

get_financial_statements

Read-onlyIdempotent

Retrieve a company's annual income statement, balance sheet, and cash flow statement with multi-year data for revenue, earnings, assets, liabilities, and fundamental analysis.

Instructions

Annual financial statements for one company: income statement, balance sheet, and cash flow statement, each with multiple years of data.

Use for revenue, earnings, assets/liabilities, cash flow, or fundamental analysis. For headline ratios only use get_company_info; for forward projections use get_analyst_estimates. Quarterly data is not returned; request JSON for the complete machine-readable export.

Returns Markdown by default, or JSON when response_format='json'. Companies without filed statements (for example some ETFs or ADRs) return empty sections or a short message.

Input Schema

Name	Required	Description	Default
`ticker`	Yes	Stock ticker symbol (e.g., 'AAPL', 'MSFT', 'TSLA')
`response_format`	No	Output format: 'markdown' for human-readable or 'json' for machine-readable	markdown

Output Schema

Name	Required	Description
`ticker`	No
`message`	No	Set instead of data when there is nothing to return for this request (for example, no dividends on record).
`cashFlow`	No
`balanceSheet`	No
`lineItemCounts`	No
`incomeStatement`	No	Period end date -> line item -> value.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.6.0Nov 7, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly/idempotent/non-destructive), and the description adds behavior the annotations cannot: default Markdown vs JSON export completeness, and the empty-result edge case for companies without filed statements such as some ETFs or ADRs. That empty-response disclosure is the kind of surprise behavior an agent needs to anticipate.

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?

Three short blocks with the primary purpose front-loaded, then routing guidance, then output/edge-case behavior. No filler sentences and no repetition of the schema or annotations.

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, so return-value explanation is not required, yet the description still covers output format switching and the no-data case. For a two-parameter read tool this leaves nothing an agent needs unresolved before calling it.

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 both parameters are already documented and the baseline would be 3. The description still adds meaning by flagging JSON as the 'complete machine-readable export', implying Markdown may be a reduced rendering — a nuance not present in the enum description.

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 verb+resource (annual financial statements for one company) and enumerates the exact contents: income statement, balance sheet, cash flow statement, each multi-year. It explicitly contrasts itself with get_company_info (headline ratios) and get_analyst_estimates (forward projections), so an agent can route without opening sibling schemas.

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?

Gives positive conditions (revenue, earnings, assets/liabilities, cash flow, fundamental analysis), names two concrete alternatives with the condition that selects each, and adds an explicit exclusion (quarterly data is not returned). This is the full when/when-not/alternative triad.

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

Deploy Server