Skip to main content
Glama
Sign In
xippios-mcp

xippios-mcp

by xippios
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

comtrade_list_partners

Read-onlyIdempotent

Lists UN Comtrade partner areas and their codes, then searches by name, ISO alpha-3, or numeric code to find the correct partner_code or partner2_code for trade queries.

Instructions

List the partner areas UN Comtrade records trade with, for partner_code and partner2_code.

Answered from upstream's partnerAreas.json as packaged with this version (reference/partnerAreas.json), without an upstream call; meta.retrieved_at is when the package fetched it, meta.vintage is None. 310 rows when packaged: 0 World (the total over all partners), countries in the reporters' code space (757 Switzerland, 842 USA, 276 Germany, 156 China) and areas that only occur as partners, such as 899 "Areas, nes" or 756 Switzerland under its ISO code. search finds a code without reading the whole list.

Args: search: Keep the rows where this text occurs, ignoring case, in the code (partner_code), the ISO alpha-3 code or the names (text, partner_desc, partner_note), e.g. "world", "W00", "USA" (840 United States of America, 841, 842 USA), "nes". 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_partners"
  }
}

Input Schema

NameRequiredDescriptionDefault
searchNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Goes well beyond the annotations: states the data is served from a packaged reference/partnerAreas.json with no upstream call, gives the row count (310), explains meta.retrieved_at and meta.vintage semantics, and warns about code-space quirks such as 0=World and areas that occur only as partners. That is exactly the operational context an agent cannot get from readOnlyHint/idempotentHint.

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?

Purpose is front-loaded, followed by provenance, row-level caveats, then an explicit Args block for the single parameter. The code-space digressions (757 Switzerland, 842 USA, redundant ISO examples) are informative but add bulk; a sentence or two could be trimmed without loss.

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?

With no output schema, the description takes on the job of describing returns and does so by naming the row fields (partner_code, text, partner_desc, partner_note) and the meta fields. A short statement of the actual response envelope (list vs paginated) is the only notable omission.

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 coverage is 0%, so the description carries the full burden, and it does: case-insensitive substring matching across partner_code, ISO alpha-3, text, partner_desc and partner_note, with worked examples ('world', 'W00', 'USA', 'nes') and the null/omit behavior. This meaningfully exceeds the bare 'search: string|null' schema.

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 the partner areas UN Comtrade records trade with, for partner_code and partner2_code', which tells an agent exactly what dimension of reference data this is. It does not explicitly contrast itself with comtrade_list_reporters or comtrade_list_codes, so sibling differentiation is implied by the concept rather than stated.

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?

Gives concrete guidance for the one parameter ('Omit for every row', 'search finds a code without reading the whole list') plus realistic query examples. It never says when to reach for this tool instead of the reporters or codes listing tools, which are the obvious alternatives.

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