xippios-mcp

by xippios

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

comtrade_get_comtrade_releases

Read-onlyIdempotent

List UN Comtrade's recent dataset releases by reporter and release date to see which dataset came out when.

Instructions

List UN Comtrade's recent data releases: which reporter's dataset came out when.

Upstream's public getComtradeReleases, "the list of the recent releases, the same with the UI live update page" (https://comtradeplus.un.org/RecentReleases); the spec calls each row "A recent or upcoming dataset release". Keyless: no key is sent and no daily quota is spent, but the call shares the client's pace (the Public tier allows 1 call per second) and its quota policy, so once upstream has said the key's daily quota is spent it is held back too; the Public tier's preview API's 500 records a call is far above the rows recorded. One row per release: reporter_code (UN Comtrade's code, e.g. 757 Switzerland), dataset_desc (e.g. "Switzerland CM 202601"), flag_code and nr, whose meanings upstream does not state (recorded: two letters, "CH" for 757; "N" or "R"), and date_release, a naive datetime: upstream prints it without a UTC offset and states no zone, so none is attached. When recorded on 2026-10-28 it listed 38 releases from 2026-10-22 to 2026-10-28, newest first, every one at midnight, none in the future; the spec states no order. UN Comtrade keeps one version of each dataset, so a revised release replaces the earlier data, which is not archived. meta.total is upstream's count; meta.published_at stays None, since each row has its own date. No arguments, one call; get_data_availability gives a dataset's first and latest release.

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_get_comtrade_releases"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (which already mark it read-only, idempotent, non-destructive, open-world), it discloses rate/pace behavior (1 call per second Public tier), quota-carryover semantics, the 500-record page limit relative to expected row counts, the fact that upstream keeps only one version of each dataset so revisions replace rather than archive prior data, and the timezone-naive nature of date_release. This is exactly the kind of context annotations cannot carry.

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 core purpose is front-loaded in the first sentence and the remaining blocks each carry real information. A few passages are tangled or low-yield, e.g. the phrasing about the Public tier preview API's 500 records and the extended meta.total/meta.published_at discussion, which add words without changing how an agent would call the tool.

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 no output schema and no parameters, the description carries the full burden and discharges it: it enumerates every row field, explains the meta fields, describes observed ordering and count, and warns that unknowns (flag_code, nr meanings, no stated timezone/order) are genuinely undocumented upstream. Nothing needed to call 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?

There are zero parameters, which is the baseline-4 case. The description compensates by documenting the returned row fields (reporter_code, dataset_desc, flag_code, nr, date_release) even though that is technically output rather than parameter semantics.

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?

Opens with a specific verb and resource: "List UN Comtrade's recent data releases: which reporter's dataset came out when." It also scopes the distinction from the related sibling by noting that get_data_availability covers a dataset's first and latest release, so an agent can route between them without reading the schemas.

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 definition makes clear this is a zero-argument, single-call listing for recent releases, notes it is keyless and that no quota is spent, and points to get_data_availability for per-dataset first/latest release questions. It stops short of explicit exclusions (e.g. when to prefer another recent-activity view), so it is strong but not a full when/when-not statement.

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

Deploy Server