Clarifo

get_revenue_geography

Read-onlyIdempotent

Get a company's revenue split by country and region for one fiscal year: where revenue comes from, market exposure, geographic concentration. For totals, margins or trends use get_company_financials. US (10-K XBRL) and Nordic (HEL, STO; annual reports) companies; values in millions of the reporting currency.

Args: company: Name, ticker or CIK, e.g. "Apple", "AAPL"; fuzzy matching. year: Fiscal year; default the most recent annual filing. Interim rows are returned only when no annual disclosure exists, flagged by period_basis="interim_fallback" and period_warning.

Returns: countries[] (with ISO alpha-2 codes), regions[] (own labels such as "EMEA", not expanded into countries) and other[] (the filer's "other countries" bucket, never broken down), each row with revenue and page_id; plus currency, unit, total_revenue, additive_layer and total_revenue_reconciliation. Layers overlap (a "Europe" row and a "Germany" row describe the same revenue), so never sum all rows: total_revenue is the one layer named in additive_layer, and total_revenue_reconciliation compares it with consolidated revenue for the same period (difference = unallocated revenue). Prefer country rows for analysis; period_label names the period the rows cover; relay period_warning, reconciliation_warning and overlap_warning when present. {"error": ...} when the company is unknown or has no geography data.

Chart: per the server "Charts" guidance (horizontal bars of shares when the split is the point); in ChatGPT call render_chart(source_tool="get_revenue_geography", source_args=, output="python").

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": {
      "company": "<company>"
    },
    "name": "get_revenue_geography"
  }
}

Input Schema

Name	Required	Description	Default
`year`	No
`company`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/closed-world, but the description adds substantive behavior the annotations cannot: interim rows only appear when no annual disclosure exists and are flagged via period_basis/period_warning, and layers overlap so rows must never be summed. It also names the reconciliation field, the warnings to relay, and the error shape — well beyond structured metadata.

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 purpose and the sibling handoff, then Args, then Returns, then chart guidance — a clean scannable structure. It is long, and the enumerated return fields partly restate an existing output schema, which is the main redundancy; the overlap-warning and additive_layer explanation, however, is necessary behavioral content rather than padding.

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?

For a two-parameter analytical tool with a rich output schema, nothing an agent needs is missing: source coverage, defaulting behavior, overlap hazards, warning relay instructions, and error semantics are all present. The chart-routing note even resolves the follow-up call to render_chart with the correct arguments.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden and does: company accepts name, ticker or CIK with fuzzy matching; year is the fiscal year and defaults to the most recent annual filing, with documented interim fallback semantics. That is meaning the schema does not supply.

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 and resource ('revenue split by country and region for one fiscal year') and immediately frames the analytical questions it answers. It also explicitly names the sibling to use for adjacent needs (get_company_financials for totals/margins/trends), so the agent can distinguish them without opening 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 explicit when-to-use ('where revenue comes from, market exposure, geographic concentration'), an explicit when-not with the named alternative ('For totals, margins or trends use get_company_financials'), and the coverage boundary (US 10-K XBRL and Nordic HEL/STO annual reports). This is routing-level guidance, not inference.

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

All Clarifo tools Inspect

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.