get_catalogCall this first. Returns periods and latest months for exports and imports, levels, which tool answers which question, keyless limits and known source-data gaps. / まず最初に呼ぶ道具。輸出・輸入それぞれの期間と最新月、区切り、どの問いにどの道具を使うか、キーなしの範囲、元データの欠けを返します。
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | 答えの言葉（ja＝日本語・既定、en＝英語） / Response language (ja default, en) |
Changes observed during successful MCP inspections.
Input schema / properties / lang / descriptionAdded value: +"答えの言葉（ja＝日本語・既定、en＝英語） / Response language (ja default, en)"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, idempotent, closed-world tool. The description adds useful operational context beyond annotations: it is a bootstrap/catalog call, reveals keyless limits, and discloses known source-data gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the key 'call first' instruction and then lists return contents efficiently. The bilingual duplication is useful for a multilingual tool but does roughly double the surface length without adding new information per language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description properly describes what the catalog returns: periods, latest months, levels, routing, limits, and data gaps. It is complete enough to call correctly, though it does not describe the shape or structure of the returned catalog data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single `lang` parameter, including default behavior and enum meanings. The description adds no parameter-level details, so the schema fully carries this burden and a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb and enumerates the catalog contents it returns: periods, latest months, levels, tool routing, keyless limits, and source-data gaps. It is clear what the tool does, but it does not explicitly differentiate itself from the sibling `get_meta` tool, which is a likely overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Call this first' gives a clear ordering cue for when to use the tool before others. It does not name alternatives or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.