TradeStats - customs trade statistics

get_indicator

Call by name, no HS code needed: returns one named indicator as a series (monthly or quarterly, newest first) with its latest value, year-on-year changes, a partner-country breakdown where the indicator has one, the definition, the caveats and a fixed notice that the value is our own calculation and not an official figure. Give an id or an English or Japanese alias (a few distinctive words also work when they match one indicator); list_indicators shows what exists. Use it to read an indicator by name; use get_series instead for one HS code. An indicator that cannot be computed yet is answered with status not_computable or not_built and the reason, never with zeros. Naphtha prices state their quantity basis: kL read directly from the source, or (only as a fallback) an estimate under a stated density assumption.

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": {
      "indicator": "<indicator>"
    },
    "name": "get_indicator"
  }
}

Input Schema

Name	Required	Description
`to`	No	Optional. Last month, formatted YYYY-MM, or a year YYYY (the whole year to December).
`from`	No	Optional. First month, formatted YYYY-MM, or a year YYYY (the whole year from January).
`limit`	No	Optional. Number of newest rows (months, or quarters for a quarterly indicator) to return; default 36, at most 200.
`country`	No	Optional, only for indicators with a partner-country breakdown. Partner country as an ISO 3166 alpha-2 code (e.g. "CN") or the name as published; the answer then holds the monthly series of that partner.
`indicator`	Yes	Required. The indicator id (for example "jp.naphtha.domestic_base_price"), an alias in English or Japanese, or a few distinctive words. See list_indicators.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

No annotations exist, so the description carries the full burden and does it well: it discloses ordering (newest first), granularity (monthly or quarterly), the full return payload (latest value, YoY changes, partner breakdown, definition, caveats, fixed non-official calculation notice), and error semantics (not_computable / not_built with a reason, never zeros). The naphtha quantity-basis caveat and the kL-vs-density-estimate fallback add uniquely useful behavioral context that no structured field encodes.

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 first sentence front-loads the core action and the returned content; routing to siblings follows, then exception behavior. It is dense and largely waste-free, though the opening sentence is a long enumerated chain and the closing naphtha sentence serves a narrow slice of indicators.

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?

With five parameters, no output schema and no annotations, the description supplies what is otherwise missing: the shape and ordering of the returned series, the failure statuses, and the independence disclaimer. Nothing an agent needs in order to call this correctly is absent.

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 nevertheless adds meaning beyond the schema by explaining that the indicator parameter accepts an id, an English or Japanese alias, or a few distinctive words that must match exactly one indicator, plus the note that country only applies to indicators with a partner breakdown. Date-range and limit semantics are left entirely to the schema, which is acceptable given its completeness.

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?

States a specific verb and resource ('returns one named indicator as a series') and immediately differentiates it from siblings: get_series is for an HS code, list_indicators enumerates what exists. An agent can pick this tool without opening any 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?

Gives explicit routing rules in both directions ('Use it to read an indicator by name; use get_series instead for one HS code') and names list_indicators as the discovery path for valid names. Acceptance of id, English/Japanese alias, or distinctive words is stated as an inclusion rule rather than left to inference.

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

All TradeStats - customs trade statistics 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.

Resources

Need Help?