Skip to main content
Glama
Sign In

MetricDuck — Financial Analysis

by com.metricduck
OverviewDiscussionsAdmin

Financial Statements

get_financials
Read-only

Use this when the user asks for a company's income statement, balance sheet or cash flow over several quarters or years: all three statements in one call, up to 10 years, each period cited to its filing; get_metric_history follows one metric, and get_company_overview is the latest snapshot.

Returns quantitative historical data with key metrics and trends. Default: all 3 statements, quarterly, 2 years. For qualitative analysis (risks, accounting quality, management tone), use get_filing_index (signal map) then get_filing_section to read the text.

Use Cases:

  • "Show me AAPL's financials" -> all statements

  • "MSFT revenue trend 5 years" -> period="annual", years=5

  • "Is Tesla's debt increasing?" -> statements=["balance"]

  • "As of a past date / point-in-time" -> get_financials("MSFT", vantage_date="2024-04-30")

Periods cite the SEC filing that reported them (accession + filed date in a footnote; resolvable EDGAR index handles in the <raw_data> block); under vantage_date, a later recast can sit under the vantage-era citation.

Exactness: the markdown table ABBREVIATES ($68.14M) — it quantises to $10K above $1M and $10M above $1B, so it is not a tie-out surface. The <raw_data> block carries the exact stored value (68135000). Quote figures from <raw_data>, not the table, whenever the precise number matters.

Responses capped at ~20K chars. If too large, the OLDEST periods are trimmed first (the same count for every statement, with a note); a whole statement is dropped only if one period of each still does not fit. Nothing is sliced, and <raw_data> carries exactly the periods shown — request fewer statements for more periods each.

Company-reported Adjusted EBITDA (issuer-specific add-backs) is NOT a computed metric here — read the issuer's own reconciliation via get_filing_section (earnings release / MD&A).

Input Schema

NameRequiredDescriptionDefault
yearsNoYears of history (default 2, max 10)
periodNoTime period granularityquarterly
tickerYesCompany ticker symbol (e.g., 'AAPL'). Must be exact.
statementsNoWhich statements to include (default: all three)
vantage_dateNoAs-of vantage (YYYY-MM-DD): restrict to filings PUBLISHED on or before this date, and cite the filing that was current then. Omit for the latest. IMPORTANT — this bounds which FILINGS are visible and which SOURCE is cited; it does NOT reconstruct the value as it stood on that date. Values are the LATEST FILED: if a later filing restated or recast a period (including a later 10-K's comparative columns), THAT LATER VALUE IS SERVED under the vantage-era citation. A LOOK-AHEAD warning appears only when the period's own filing was later amended; other recasts are NOT flagged. For the value as known at your vantage, call get_xbrl_facts with the accession_number of the latest filing on or before it that reports the period (list_filings takes vantage_date); period_history=true gives each period's value as originally filed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / vantage_date / description
      Previous value: -"As-of vantage (YYYY-MM-DD): restrict to filings PUBLISHED on or before this date, and cite the filing that was current then. Omit for the latest. IMPORTANT — this bounds which FILINGS are visible and which SOURCE is cited; it does NOT reconstruct the value as it stood on that date. If a later filing restated a period, THE RESTATED VALUE IS WHAT IS SERVED under a pre-vantage citation — and the response carries an explicit LOOK-AHEAD warning naming the affected periods, so the exposure is disclosed rather than silent. For a true as-originally-filed series use get_xbrl_facts with period_history=true."New value: +"As-of vantage (YYYY-MM-DD): restrict to filings PUBLISHED on or before this date, and cite the filing that was current then. Omit for the latest. IMPORTANT — this bounds which FILINGS are visible and which SOURCE is cited; it does NOT reconstruct the value as it stood on that date. Values are the LATEST FILED: if a later filing restated or recast a period (including a later 10-K's comparative columns), THAT LATER VALUE IS SERVED under the vantage-era citation. A LOOK-AHEAD warning appears only when the period's own filing was later amended; other recasts are NOT flagged. For the value as known at your vantage, call get_xbrl_facts with the accession_number of the latest filing on or before it that reports the period (list_filings takes vantage_date); period_history=true gives each period's value as originally filed."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Far beyond the annotations' readOnly/openWorld profile: it discloses the ~20K char response cap and the exact truncation rule (oldest periods trimmed first, same count per statement, whole statement dropped only if nothing fits), that citations resolve to EDGAR index handles, and that vantage_date bounds visible FILINGS rather than reconstructing historical values.

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-loaded with the when-to-use line, then use cases, then output caveats — a sensible hierarchy. It is long and repeats some vantage_date/look-ahead material already present in the schema description, which costs a point, but nearly every sentence carries operational information.

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?

With no output schema, the description still explains the return surface (markdown table vs. <raw_data>, footnote citations, defaults), the precision trap (table abbreviates to $10K/$10M quantisation; quote <raw_data> for tie-outs), and the truncation escape hatch (request fewer statements for more periods).

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 would be 3; the description earns above baseline by mapping natural-language intents to parameter combinations ('MSFT revenue trend 5 years' -> period="annual", years=5; 'Is Tesla's debt increasing?' -> statements=["balance"]) and restating the default of all three statements quarterly for two years.

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?

Opens with a specific verb+resource framing ('income statement, balance sheet or cash flow over several quarters or years: all three statements in one call, up to 10 years, each period cited to its filing') and explicitly distinguishes itself from the two closest siblings, get_metric_history and get_company_overview, in the same sentence.

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 explicit when-to-use routing (quantitative history here vs. get_filing_index/get_filing_section for qualitative risks, accounting quality, management tone), plus excluded cases (Adjusted EBITDA must be read from the issuer's filing) and four concrete user-query-to-parameter mappings.

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

All MetricDuck — Financial Analysis toolsInspect
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