Skip to main content
Glama

comtrade_get_world_share

Read-onlyIdempotent

Retrieve each reporter's share of world trade by period with release dates, filtered by goods or services, annual/monthly frequency, period, and reporter code.

Instructions

List each reporter's share of world trade per period, with its release dates.

Upstream's public getWorldShare, "Get the World Share (including estimates)"; the spec calls a row "A reporter's share of world trade for one period". The spec states neither whether world_share (a Decimal) is a fraction or a percentage nor of which trade; when recorded, the 214 values for 2023 (annual goods, every reporter) sum to 1.0 and Switzerland's is 0.0165. A row with is_available false (47 of those 214) still carries a world_share, but first_released and last_released read 0001-01-01T00:00:00, upstream's placeholder on unavailable datasets, kept as sent, not a release; upstream states no meaning for is_available or data_count. The four times (first_released, last_released, created, updated) are naive datetimes: upstream prints them without a UTC offset and states no zone, so none is attached. Keyless: no key is sent and no daily quota is spent, but the call shares the client's pace (the Public tier allows 1 call per second) and its quota policy, so once upstream has said the key's daily quota is spent it is held back too. Upstream's subscription page limits the Public tier's preview API to 500 records a call; whether that binds this operation is not stated, and the recorded answers (214 rows at most) did not reach it. One call, rows in upstream's order; a period nobody reported returns an empty list. The MCP tool returns up to 400 rows or 100 KB, so the whole 214-row answer for one period reaches an agent; beyond that its note says to narrow by reporter_code or period. Arguments are checked before the call; an unknown reporter code raises UnknownCode, an InvalidRequestError naming the packaged list and the closest area, another mistake InvalidRequestError.

Args: type_code: "C" goods or "S" services. freq_code: "A" annual or "M" monthly. period: Years "2023" (annual) or months "202301" (monthly), comma-separated, e.g. "2022,2023". The spec also lists "recent", which is accepted, but upstream answered it with HTTP 500 on all three tries on 2026-10-28, with and without a reporter (ch_recent.json, all_reporters_recent.json): the client makes 4 attempts (3 retries) on a 5xx and then raises UpstreamError, and what "recent" selects is unknown, so name the periods. Omit for every period (64 annual rows for Switzerland, 1962 to 2025). reporter_code: Reporters, comma-separated, as list_reporters lists them: "757" Switzerland, "842" USA, "156" China, "757,842". Omit for every reporter (214 rows for 2023, annual goods).

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": {
      "type_code": "<type_code>",
      "freq_code": "<freq_code>"
    },
    "name": "comtrade_get_world_share"
  }
}

Input Schema

NameRequiredDescriptionDefault
periodNo
freq_codeYes
type_codeYes
reporter_codeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (read-only, idempotent, open-world, non-destructive), it discloses that the call is keyless and spends no quota but shares the client's 1/sec pace, the 500-record preview limit, retry behavior on 5xx, and that rows are returned in upstream order. It also explains the 0001-01-01 placeholder on unavailable datasets and the absence of a timezone on naive datetimes, all genuinely useful behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is mostly substantive, but the opening is a dense prose block mixing data caveats, quota policy and error behavior without headers, making it hard to scan. Some detail (Switzerland's 0.0165, '47 of those 214') is illustrative but adds bulk to a single paragraph.

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?

There is no output schema, yet the description explains row shape, the empty-list case, the 400-row/100 KB truncation and its note, error types, and the fraction-vs-percentage ambiguity. For a tool with quirky upstream semantics this is essentially complete.

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?

With 0% schema description coverage the description must carry the full load, and it does: type_code 'C' goods vs 'S' services, freq_code 'A' annual vs 'M' monthly, period formats '2023'/'202301'/comma-separated with the 'recent' caveat, and reporter_code examples tied to list_reporters. It also documents the validation errors (UnknownCode, InvalidRequestError) raised on bad codes.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource ('List each reporter's share of world trade per period, with its release dates') and grounds it in upstream's getWorldShare. It never distinguishes this from the closely named sibling comtrade_get_world_trade, so an agent must infer the difference between 'world share' and 'world trade'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete operational guidance: omit period for every period, omit reporter_code for all reporters, narrow by reporter_code or period when output exceeds 400 rows, and avoid 'recent' because it returned HTTP 500. It does not name alternative tools or state when a sibling should be chosen instead.

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