Skip to main content
Glama

comtrade_get_commodity_series

Read-onlyIdempotent

Fetches one reporter's trade in a single commodity with the World across multiple periods, returning joined, period-sorted rows for exports, imports, re-exports, or re-imports.

Instructions

A reporter's trade in one product with the World over many periods, oldest first.

data/v1/get for goods (typeCode C) with partner 0, World (the total over all partners), pinned to the total of every breakdown (partner2Code 0, customsCode C00, motCode 0, breakdownMode classic), with descriptions (includeDesc). Upstream takes at most 12 periods per call, so the periods are sent in chunks of 12, one call after the other in the order given (14 periods: two calls, 1.5 s apart), and the rows are joined and sorted by period; a period upstream holds nothing for has no row. A period the reporter has not released yet has no row either, which cannot be told from a period without trade; get_data_availability names the periods a reporter has released. One row per period at most, so there is no count call. Every chunk is a keyed call and a free key allows 500 calls a day, so one series takes at most 120 periods (ten calls); more raise InvalidRequestError before any call: split the series. Arguments are resolved and checked before any call; an unknown reporter raises UnknownCode, an InvalidRequestError naming the packaged list and the closest area, another mistake InvalidRequestError naming the closest valid value. meta.request holds the get_data arguments with every period; they were sent 12 at a time.

Args: reporter: The reporting area, as UN Comtrade's code or its ISO alpha-3 code: "757" or "CHE" Switzerland, "842" or "USA", "276" or "DEU" Germany, "156" or "CHN" China; list_reporters(search=...) finds them. Codes are UN Comtrade's, not ISO numeric (Switzerland is 757, not 756). An alpha-3 code that several codes share resolves to the one still in use ("DEU" is 276, not 280 Fed. Rep. of Germany until 1990). commodity: One product code of cl_code: "TOTAL" all goods, an HS chapter "27", heading "0901" or subheading "090111". list_commodities("HS", search="coffee") finds codes. flow: One trade flow: "X" exports, "M" imports, "RX" re-exports, "RM" re-imports. periods: Years (annual data) or months (monthly data), comma-separated, one format, each once, at most 120: "2018,2019,2020,2021,2022,2023", "202201,202202,202203"; every year from 2010 to 2023 is 14 periods, two calls. cl_code: Product classification, "HS" by default: all HS editions as each reporter reported them (rows name the edition in classification_code, e.g. "H6"); an edition "H0" to "H5", SITC "SS" or "S1" to "S4", BEC "B4", "B5" also work. "H6" is valid but upstream answered HTTP 500 to every try on 2026-10-23, so "HS" stays the default. EBOPS "EB", "EB02", "EB10", "EB10S" (services), "BE" and "TM" are accepted but untested with the pinned typeCode C.

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": {
      "reporter": "<reporter>",
      "commodity": "<commodity>",
      "flow": "<flow>",
      "periods": "<periods>"
    },
    "name": "comtrade_get_commodity_series"
  }
}

Input Schema

NameRequiredDescriptionDefault
flowYes
cl_codeNoHS
periodsYes
reporterYes
commodityYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare a safe, idempotent, open-world read, and the description adds substantial context beyond them: chunking at 12 periods per call 1.5 s apart, a 120-period ceiling enforced before any call, the 500-calls/day free-key limit, and the exact exception types (InvalidRequestError, UnknownCode) with their messages. It also discloses the ambiguity that an unreleased period is indistinguishable from a period with no trade.

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?

It is front-loaded with a one-sentence summary followed by mechanics and then a per-argument block, so an agent can stop early. It is dense and occasionally run-on (the chunking, error, and key-limit rules are packed into one paragraph), but essentially every sentence carries operational information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter, no-output-schema tool this covers call mechanics, limits, error surfaces, and missing-row semantics thoroughly. The only thin area is the shape of returned rows beyond the note that classification_code names the HS edition and meta.request carries the original 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: reporter accepts UN Comtrade numeric or ISO alpha-3 with disambiguation rules (757 not 756; DEU resolves to 276), commodity accepts TOTAL/chapter/heading/subheading, flow enumerates X/M/RX/RM, periods specifies comma-separated single-format unique values with a 120 cap, and cl_code enumerates HS editions and alternatives plus a known-bad case.

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 opening sentence names the specific verb and resource ('A reporter's trade in one product with the World over many periods, oldest first') and immediately pins the scope to partner 0 / World totals, which distinguishes it from the bilateral siblings without depending on their names. It also spells out the exact upstream endpoint and parameter pinning (typeCode C, partner2Code 0, customsCode C00, motCode 0, breakdownMode classic).

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 when to reach for this vs alternatives: for partner breakdowns the pinned World-total scope signals it is not the bilateral call, 'there is no count call' since one row per period, and it explicitly routes the agent to get_data_availability to learn which periods a reporter has released. It also routes code lookup to list_reporters(search=...) and list_commodities("HS", search=...).

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