Skip to main content
Glama

MetricDuck — Financial Analysis

8-K Earnings Release Financials

get_earnings
Read-only

Use this when the user asks what a company just reported in its earnings release: the 8-K's headline income statement (revenue, operating income, net income, diluted EPS) and as-released cash flow (OCF, capex, FCF, with growth), typically weeks before the 10-Q/10-K that get_financials reads; get_earnings_reports lists the documents, not the figures. Often the only MetricDuck source for the fresh quarter's capex/OCF/FCF (the 8-K carries no XBRL, so get_financials/get_metric_history still show the prior quarter until the 10-Q lands).

Distinct from get_financials (10-K/10-Q XBRL — filed later, GAAP-consistent) and get_company_overview (its earnings section is prose, no figures). Each figure carries a deep-link + verbatim quote when the release has an attested receipt.

Use Cases:

  • "What did NVDA report for its latest quarter's revenue?" -> get_earnings("NVDA")

  • "TSLA's last 8 quarters of earnings releases" -> get_earnings("TSLA", quarters=8)

Release figures are management's own characterization and may be non-GAAP-adjacent — verify against the quote when precision matters. A figure without a receipt is still shown (often filled from a prior extraction pass or awaiting validation) but without a deep-link — absence of a receipt is not evidence the value is wrong.

Point-in-time: vantage_date (YYYY-MM-DD) serves the releases known on/before that date, and quarters walks back from it. A revised release is a new accession, so there is no restatement look-ahead here.

Exactness: the table ABBREVIATES ($118.70B) — quote exact figures from <raw_data> instead.

Input Schema

NameRequiredDescriptionDefault
tickerYesCompany ticker symbol (e.g., 'NVDA'). Must be exact.
quartersNoNumber of most recent quarters to return (1-8, default 4).
vantage_dateNoAs-of vantage (YYYY-MM-DD): serve releases KNOWN on/before this date — the quarters walk back from the vantage instead of today. For backtests / point-in-time questions. Omit for the latest. Scope: this bounds which RELEASES are visible, not which EXTRACTION of them — a figure MetricDuck later re-extracted is served at its current (corrected) reading. That is deliberate: the corrected reading is the better answer to what the filing said at that date. Such corrections are rare — 0.60% of release/signal pairs ever changed value across extractions, all within the same accession — and a genuine issuer revision arrives as a NEW accession, which this bound catches.

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): serve releases KNOWN on/before this date — the quarters walk back from the vantage instead of today. For backtests / point-in-time questions. Omit for the latest. Scope: this bounds which RELEASES are visible, not which EXTRACTION of them — a figure MetricDuck later re-extracted is served at its current (corrected) reading. That is deliberate: the corrected reading is the better answer to what the filing said at that date. Measured 2026-08-25: 0.60% of release/signal pairs ever change value across extractions, all same-accession corrections, zero issuer revisions — a genuine issuer revision arrives as a NEW accession, which this bound catches."New value: +"As-of vantage (YYYY-MM-DD): serve releases KNOWN on/before this date — the quarters walk back from the vantage instead of today. For backtests / point-in-time questions. Omit for the latest. Scope: this bounds which RELEASES are visible, not which EXTRACTION of them — a figure MetricDuck later re-extracted is served at its current (corrected) reading. That is deliberate: the corrected reading is the better answer to what the filing said at that date. Such corrections are rare — 0.60% of release/signal pairs ever changed value across extractions, all within the same accession — and a genuine issuer revision arrives as a NEW accession, which this bound catches."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly, openWorld, non-destructive); the description goes well beyond them by disclosing the receipt/deep-link mechanism, that unreceipted figures still appear and are not evidence of error, the non-GAAP-adjacent nature of management figures, and the abbreviation discrepancy in the rendered table versus <raw_data>.

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 core purpose and then layers distinctions, use cases, and caveats in clearly headed blocks; nothing is filler. It is on the long side and restates the point-in-time/vantage semantics and the sibling distinctions more than once, which keeps it just short of a 5.

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 carries the burden of describing returns and does so: the exact income-statement and cash-flow lines, growth figures, and the per-figure deep-link plus verbatim quote. The non-GAAP precision caveat and the exactness warning close the remaining gaps for this tool's complexity.

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, but the description adds real semantics: it specifies that vantage_date bounds which releases are visible, that quarters walks back from the vantage rather than from today, and that a revised release is a new accession with no restatement look-ahead. That meaning is not derivable from the schema alone.

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 and resource ('the 8-K's headline income statement ... as-released cash flow') and enumerates the exact fields returned (revenue, operating income, net income, diluted EPS, OCF, capex, FCF). It explicitly separates itself from get_financials, get_company_overview and get_earnings_reports, so an agent can route without opening any schema.

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 an explicit trigger ('when the user asks what a company just reported in its earnings release'), names the three nearest alternatives with the condition that selects each, and supplies two worked Use Cases with parameter values. When-to-use and when-not-to-use are both covered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources