Skip to main content
Glama

EdgarStack

Get segment, geographic and product breakdowns from a 10-K or 10-Q

get_segment_breakdown
Read-onlyIdempotent

Segment breakdown of a US company's revenue, costs, operating income, assets and other metrics, read from the XBRL of one filing (the latest 10-K by default, or a 10-Q). get_financials only returns company-wide totals; use this tool for figures by business segment, by geography (e.g. United States vs other countries) or by product/service line. Returns, per breakdown: the members (segments, regions or product lines) with the filer's own labels, and per metric the values for each member over the filing's periods (3 fiscal years from a 10-K by default, up to 5 with years=5; quarter and year-to-date in a 10-Q), reconciling items such as corporate and eliminations where tagged, the consolidated total, and a check per period: members_sum_to_total, sums_with_reconciling_items, partial_or_overlapping (members don't add up, e.g. product groupings that overlap) or no_consolidated_figure. Metrics are ordered revenue, costs, operating income, D&A, capex, assets, then others; moreMetrics lists any left out. breakdowns: business, geography, product (default all three). Each value is as reported in that filing (later filings may recast segments). Every result cites the filing and its XBRL instance. Single-segment companies often tag no segments; then read the segment note with get_filing_section (10-K Item 8). Not financial advice.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ticker": "<ticker>"
    },
    "name": "get_segment_breakdown"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearsNo10-K only: fiscal years to return (1-5). Years 4-5 come from the 10-K filed three years earlier, as reported then
tickerYesUS ticker, e.g. MSFT
formTypeNo10-K
breakdownsNoWhich breakdowns to return; default all three
accessionNumberNoA specific filing from list_recent_filings; omit for the latest
maxMetricsPerBreakdownNo

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/5.0
Behavior5/5

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

Beyond readOnly/idempotent annotations, it discloses defaults (latest 10-K, 3 fiscal years), that values are 'as reported in that filing' and later filings may recast segments, that each result cites the filing and XBRL instance, and the possible reconciliation outcomes (sums_with_reconciling_items, partial_or_overlapping, no_consolidated_figure). These are behavioral traits an agent cannot infer from the annotations or schema.

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?

Content is front-loaded with purpose and the sibling contrast placed at the very start, and nearly every sentence carries decision-relevant information. It is a single dense paragraph of run-on sentences with heavy parenthetical nesting, and 'Not financial advice' is pure boilerplate, so structure could be improved without losing content.

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 the return shape and does so thoroughly: members with filer labels, per-metric values across periods, reconciliation items, consolidated total, and per-period sum checks. It also covers the single-segment edge case and period granularity differences between 10-K and 10-Q.

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 67%, and the description adds useful context around defaults (all three breakdowns unless specified, 3 years by default, up to 5 with years=5) plus the metric ordering and moreMetrics spillover behavior. However, maxMetricsPerBreakdown is never explained in either the schema or the description, and years/accessionNumber are largely restated rather than clarified.

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?

The first sentence names a specific resource (segment breakdowns of revenue, costs, operating income, assets) and its source (XBRL of one filing, latest 10-K by default). It explicitly contrasts with the sibling get_financials ('only returns company-wide totals'), so an agent can select between them without opening either 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?

It states the exact selection condition: use this for figures by business segment, geography or product line, and names get_financials as the wrong tool for that need. It also handles the failure case — single-segment filers often tag no segments, so read the segment note with get_filing_section (10-K Item 8) — which is a genuine when-not/alternative path.

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