Skip to main content
Glama
Sign In
xippios-mcp

xippios-mcp

by xippios
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

comtrade_list_classifications

Read-onlyIdempotent

List UN Comtrade reference files and product classifications by category, optionally filtering to one category such as cmd:H6.

Instructions

List UN Comtrade's reference files, the product classifications among them, by category.

Answered from upstream's index of the files, ListofReferences.json, as packaged with this version (reference/ListofReferences.json), without an upstream call; meta.retrieved_at is when the package fetched it, meta.vintage is None. 28 rows when packaged, one per file: its category ("flow", "reporter", "cmd:HS"), the variable it lists ("Product [HS 2022]"), upstream's description and where the file is served, fileuri. A category cmd:<clCode> is a product classification, 19 of them: the cl_code that get_data and list_commodities take ("cmd:H6" is "H6", HS 2022).

Args: category: Keep the row of this category, as upstream writes it, e.g. "cmd:HS", "cmd:H6", "cmd:EB10", "flow", "reporter", "qtyunit". Omit for every row.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "comtrade_list_classifications"
  }
}

Input Schema

NameRequiredDescriptionDefault
categoryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Goes well past the annotations: it discloses the data source (packaged reference/ListofReferences.json), that no upstream call is made, that 28 rows are returned, the exact row fields (category, variable, description, fileuri), and that meta.vintage is None while meta.retrieved_at reflects packaging time. This is substantive behavioral context an agent could not get from readOnlyHint/openWorldHint alone, and the local-snapshot claim is a meaningful nuance even against openWorldHint=true.

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?

Front-loaded with the one-line purpose, then provenance, then row shape, then the argument — a sensible order with no filler sentences. Minor redundancy in restating the packaged file path twice and a slightly discursive aside about meta.vintage being None keeps it off a 5.

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 one optional parameter and no output schema, the description must describe the return shape itself, and it does: row count, per-row fields, and the meaning of meta keys. Nothing an agent needs to call this correctly or interpret the result is missing.

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 0% and the schema only offers an untyped string|null, so the description carries the parameter meaning: it explains the category vocabulary format (cmd:<clCode>, flow, reporter, qtyunit), the mapping from cmd:H6 to the cl_code "H6", and that omitting returns all rows. It stops short of enumerating the full valid value set, leaving some guesswork for less common categories.

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?

Opens with a specific verb and resource ("List UN Comtrade's reference files") and narrows scope to the product classifications among them, filterable by category. It also names the consuming tools (get_data, list_commodities), which helps place it in the ecosystem, but it never explicitly contrasts itself with comtrade_list_codes or comtrade_list_commodities.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the reader can infer this is the discovery step that yields the cl_code for get_data, and the "Omit for every row" note gives clear default behavior. However, there is no explicit when-to-use / when-not guidance or pointer to a sibling for the non-classification categories.

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

Deploy Server

Other Tools