品目ごとの月ごとの値段（68か月）。item_code は suii の一覧にある（米コシヒカリ5kg は 1001）
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": {
"item_code": "<item_code>"
},
"name": "suii_item"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| item_code | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It conveys the data scope (68 months of monthly price readings) and implies a read-only lookup. It does not disclose the return format, the specific month range, units, or behavior for invalid codes, leaving moderate gaps for a data-retrieval tool.
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?
Two short sentences, each earning its place: the first states the tool's purpose, the second explains code sourcing with a concrete example. The essential 'what' is front-loaded with zero filler.
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?
For a one-parameter lookup with no output schema and no annotations, the purpose and input sourcing are adequately covered. The missing piece is the return shape (what fields come back, such as month and price) and the exact date range, which would help an agent interpret results but are not critical to invoking it correctly.
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?
Schema description coverage is 0% and the schema merely declares item_code as a required string. The description compensates well by explaining that valid codes live in the suii list and giving a concrete example (米コシヒカリ5kg is 1001), adding meaning beyond the bare schema.
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?
The description states a specific resource and action: monthly prices per item over 68 months. It points to the suii master list for valid item codes, which distinguishes it from sibling 'item' tools (cost_item, lens_item, super_item) only partially — it doesn't explicitly name what differentiates it from them, but the '68 months' scope and suii-list reference give enough specificity.
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?
It provides one piece of usage direction: the item_code must come from the suii list, which tells the agent where to source valid inputs. However, it gives no explicit when-to-use vs. alternatives (e.g., when to prefer suii_item over cost_item or lens_item) and no exclusions. Guidance is present but minimal.
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.