Skip to main content
Glama

get_customs_country_trade

Read-onlyIdempotent

Query China merchandise trade by partner country/region, including all-partner totals using country TOTAL. Inputs: period, country and optional flow. IMPORT and EXPORT are China imports and exports; BOTH is recorded combined trade. Returns recorded trade values and units (currently 1000USD), scope, source_class, provenance, snapshot, pagination and limits. No commodity filter or currency conversion. No match returns an empty data array. Required: period, country. Missing required or invalid input produces an argument error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
flowNoChina trade direction: IMPORT or EXPORT or BOTH (recorded combined total). Optional; omission includes collected directions.
limitNoMaximum number of records returned. Integer 1–100; default 20. A page may contain fewer records.
offsetNoZero-based pagination offset. Integer 0–999; default 0. Offsets of 1000 or greater are rejected. Use the returned next_offset when present.
periodYesRecorded statistical period: YYYY-MM for a single month, or YYYY-01/YYYY-MM for January-to-month cumulative observations. Exact collected period; these periods are not interchangeable. A snapshot identifies the dataset version, not a selectable statistical period. Required.
countryYesChina trade partner country/region, or TOTAL for all partners. TOTAL is an aggregate, not an alias for China. Exact recorded name or selected one-to-one alias; original labels remain in output. Required.
snapshotNoOptional expected snapshot.version, not a historical-version selector. If omitted, the current dataset snapshot is used. For continued pagination reuse the previous response snapshot.version; a mismatch is rejected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / country / description
      Previous value: -"Country or region label exactly as recorded; no country-code or alias conversion. Exact match. Non-empty string, at most 256 characters; control characters are not accepted. Required. Supplied filters are combined with AND."New value: +"China trade partner country/region, or TOTAL for all partners. TOTAL is an aggregate, not an alias for China. Exact recorded name or selected one-to-one alias; original labels remain in output. Required."
    • changedInput schema / properties / flow / description
      Previous value: -"Recorded trade-flow label. Exact match. Allowed values: IMPORT, EXPORT, BOTH. BOTH matches a recorded BOTH row; it does not combine IMPORT and EXPORT. Non-empty string, at most 256 characters; control characters are not accepted. Optional; omitted means no filter on this field. Supplied filters are combined with AND."New value: +"China trade direction: IMPORT or EXPORT or BOTH (recorded combined total). Optional; omission includes collected directions."
    • changedInput schema / properties / period / description
      Previous value: -"Statistical period label exactly as recorded; no date-range parsing or automatic period conversion. Exact match. Non-empty string, at most 256 characters; control characters are not accepted. Required. Supplied filters are combined with AND."New value: +"Recorded statistical period: YYYY-MM for a single month, or YYYY-01/YYYY-MM for January-to-month cumulative observations. Exact collected period; these periods are not interchangeable. A snapshot identifies the dataset version, not a selectable statistical period. Required."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark it read-only/idempotent, and the description adds useful behavioral detail beyond that: the returned fields (units, scope, source_class, provenance, snapshot, pagination, limits), empty data array on no match, and argument errors on invalid input. This gives an agent a clear model of what happens when the tool is called.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: purpose, input orientation, semantics, return contents, exclusions, edge cases, and error behavior. The main action and scope are front-loaded before the parameter details.

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 tool with six parameters, annotations, and no output schema, the description covers the essential operational contract: required inputs, optional flow, return fields, no-match behavior, invalid-input behavior, and limitations. Combined with the schema's detailed parameter documentation, nothing critical is missing for correct invocation.

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 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the flow enum in plain terms (IMPORT/EXPORT/BOTH), clarifying that TOTAL means all partners, and noting that units are currently 1000USD. This is modest but real added value.

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 description states a specific verb and resource: 'Query China merchandise trade by partner country/region', and immediately clarifies the special 'TOTAL' aggregate. It also draws a clear boundary from the commodity-level sibling by saying 'No commodity filter', so an agent can tell this tool apart from get_customs_commodity_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?

The description gives clear context for use (period + country + optional flow), names the required inputs, and states exclusions ('No commodity filter or currency conversion'). However, it does not explicitly name an alternative tool for commodity-level queries or otherwise say 'use X instead', so it stops just short of full when/when-not/alternative guidance.

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