Skip to main content
Glama

comtrade_get_counts

Read-onlyIdempotent

Count UN Comtrade trade records a query would return without fetching data, so you can check result size and split queries exceeding 100,000 records.

Instructions

Count the UN Comtrade trade records a query would return, without fetching them.

The same request as get_data with upstream's countOnly. One call returns at most 100,000 records, so count first and split a larger query. A count of 0 means no data matches: an unreported period, a code that is not a reporter, a flow the reporter does not record. Every count costs one call of the key's daily quota (500 on a free key). Arguments are checked before the call, reporter, partner, customs and transport codes against the packaged lists: an unknown one raises UnknownCode, an InvalidRequestError naming the packaged list, its fetch date and the closest code (756 names 757, Switzerland); another mistake raises InvalidRequestError naming the closest valid value.

Args: type_code: "C" goods or "S" services. freq_code: "A" annual or "M" monthly. cl_code: Product classification: "HS" (all HS editions as reported; prefer it), an edition "H0" to "H5", SITC "SS", "S1" to "S4", BEC "B4", "B5", for services EBOPS "EB", "EB02", "EB10", "EB10S"; also "BE" and "TM", which the spec lists and upstream accepts. "H6" is valid but upstream answered HTTP 500 to all five tries on 2026-10-23 (two reporters, two product codes); "HS" rows carry the edition the reporter used, e.g. classification_code "H6" for Switzerland 2023. reporter_code: Reporting areas as UN Comtrade's numeric codes, comma-separated, e.g. "757" Switzerland, "842" USA, "276" Germany, "156" China, "757,842", as list_reporters lists them. Some differ from ISO numeric codes: Switzerland is 757, not 756. Omit for every reporter. partner_code: Partner areas, comma-separated, as list_partners lists them: "0" World (the total over all partners), "276" Germany. Omit for every partner, one row each. partner2_code: Second partner (consignment) areas, comma-separated, codes of list_partners; "0" is the total. period: Years "2023" (annual) or months "202305" (monthly), at most 12 comma-separated, e.g. "2021,2022,2023". cmd_code: Product codes of cl_code, comma-separated, as list_commodities(cl_code) lists them: "TOTAL" for all goods, "AG2", "AG4", "AG6" for every code at that level, codes such as "0901" or "090111", wildcards such as "27??" (every four-digit code under 27) or "27*". For services the classification files name "200" (EB, EB02, EB10) or "S" (EB10S) as the total; recorded counts confirm "200" on EB10 and EB02, where "TOTAL" counted 0 (EB10). A code upstream does not have counts 0 too, so a 0 does not prove that a code exists. flow_code: Trade flows, comma-separated: "X" exports, "M" imports, "RX" re-exports, "RM" re-imports, also "DX", "FM", "MIP", "MOP", "XIP", "XOP", "MIF", "XIF"; e.g. "M,X". mot_code: Modes of transport, comma-separated: "0" the total, "1000" air, "2100" sea, "3100" railway, "3200" road, "9100" pipelines and cables. Omit for every mode, one row each. customs_code: Customs procedures, comma-separated: "C00" the total, "C01" clearance for home use, "C03" outright exportation. Omit for every procedure, one row each. aggregate_by: Upstream parameters to aggregate the results over, comma-separated from cmdCode, period, partnerCode, partner2Code, reporterCode, customsCode, motCode; e.g. "cmdCode" sums the products of "AG2" into one row per remaining breakdown. The aggregated parameters come back as -2 (cmd_code "-2", partner_code -2) with classification_code "GG"; the count matches the rows. breakdown_mode: "plus", upstream's default (omitting it gives the same rows): every customs procedure, mode of transport and second partner; "classic": only the total row (partner2_code 0, customs_code "C00", mot_code 0). include_desc: Upstream's includeDesc, "Include descriptions of data variables": fills the *_iso and *_desc fields of get_data rows; sent on as given.

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>",
      "cl_code": "<cl_code>"
    },
    "name": "comtrade_get_counts"
  }
}

Input Schema

NameRequiredDescriptionDefault
periodNo
cl_codeYes
cmd_codeNo
mot_codeNo
flow_codeNo
freq_codeYes
type_codeYes
aggregate_byNo
customs_codeNo
include_descNo
partner_codeNo
partner2_codeNo
reporter_codeNo
breakdown_modeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses quota consumption (one call of the key's daily 500), the result cap, pre-call validation behavior with specific error types (UnknownCode, InvalidRequestError naming the list, fetch date and nearest code), and a known upstream failure mode for cl_code "H6". It also explains that aggregated parameters return as -2 with classification_code "GG" and that breakdown_mode default equals "plus".

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?

The critical scoping and cap information is front-loaded and the per-argument blocks are consistently structured. It is long, and a few passages are incidental — the H6 HTTP 500 incident log and the repeated "Omit for every … one row each" phrasing — but most of the length is earned given 14 undocumented parameters.

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 14-parameter, high-complexity counting tool with no schema descriptions and no output schema, the description covers code systems, quota economics, validation failures, aggregation semantics and return-value markers. Nothing an agent needs in order to call it correctly appears to be missing.

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% across 14 parameters, so the description carries the full burden and does: every parameter is documented with accepted values, comma-separated syntax, omission semantics (e.g. omitting partner_code yields every partner), and examples. It adds non-obvious caveats the schema cannot express, such as Switzerland being 757 rather than ISO 756, "200" being the services total on EB/EBOPS, and wildcard forms like "27??" and "27*".

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 states a specific verb and resource — "Count the UN Comtrade trade records a query would return, without fetching them" — and immediately distinguishes the tool from its closest sibling by noting it is "the same request as get_data with upstream's countOnly." An agent can identify the tool's role without opening the 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 gives explicit operational guidance: count first and split queries larger than the 100,000-record cap, interpret a count of 0 as no matching data, and account for the daily quota cost. It also names the sibling it mirrors (get_data) and the helper lists (list_reporters, list_partners, list_commodities) that supply valid codes.

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