Red-necked longhorn beetle (Aromia bungii) in Japan: damage status, new detections, rewards by city.
Scored across 5 tools
The status and dossier tools both take a municipality name and return damage status plus subsidies, while subsidy information also appears in changes_since and list_rewards_and_subsidies. Descriptions clarify scope (quick status vs. full profile vs. temporal feed vs. list), but the boundaries are still easy to confuse.
All names use consistent snake_case and a predictable get_/list_ verb pattern. The nouns clearly indicate the resource or query, with no mixed conventions.
Five tools is well-scoped for this focused information domain. Each tool maps to a distinct access pattern: single-municipality lookup, richer profile, change feed, new-detection list, and subsidy list.
Core workflows are covered: checking a municipality, seeing recent changes, finding new detections, and reviewing subsidies. Minor gaps remain, such as browsing by prefecture or listing all affected municipalities without a known name.
クビアカのいま 変化の便り: since=YYYY-MM-DD から今日までに変わったものだけ（新たな被害・区分の変化・補助と奨励金の追加と状態の変化・窓口の追加・締切が30日以内のもの）。x402 で $0.01（試験中・Base Sepolia の USDC）
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | YYYY-MM-DD。この日から今日までの変化。省くと7日前 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavioral context: the call is paid via x402 at $0.01, currently experimental, settled in USDC on Base Sepolia (testnet) — exactly the kind of cost/payment precondition an agent must know before calling. It stops short of describing the response shape or ordering.
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?
One dense sentence: the operation and its window come first, the change categories are parenthesized, and the payment note is appended last. Every clause carries information an agent needs.
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 read-only, one-optional-parameter delta tool with no output schema, the definition covers what is returned, the time window and default, and the payment requirement. What remains uncovered (payment handshake steps, result ordering/pagination) is secondary, hence 4 rather than 5.
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 coverage is 100% and the single 'since' parameter is fully documented in-schema, including the 7-day default. The description only restates the YYYY-MM-DD format and the 'up to today' window, so it adds little beyond the schema — baseline 3.
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 names a clear delta/changelog operation: only what changed between since=YYYY-MM-DD and today, and it enumerates the change classes (new damage, classification changes, subsidy additions/status changes, new contact points, deadlines within 30 days). It is distinguishable from siblings because it is the aggregate 'what's new' feed rather than a single-resource lookup, though it does not explicitly contrast itself with list_new_detections or list_rewards_and_subsidies.
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?
Usage is only implied: an agent can infer 'call this when you want only changes since a date' and the schema notes the 7-day default. There is no explicit statement of when to prefer this over list_new_detections or get_municipality_status, and no stated exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
クビアカのいま 市町村のカルテ: 1つの市町村の区分・窓口・通報先・使える補助と奨励金（市町村と県）・近い被害地域5つと距離（中心どうしの目安）・県の最近の報道。x402 で $0.005（試験中・Base Sepolia の USDC）
| Name | Required | Description | Default |
|---|---|---|---|
| lg_code | No | 全国地方公共団体コード6桁（例 242080 = 三重県名張市） | |
| prefecture | No | 同じ名前の市町村を絞る都道府県名（任意） | |
| municipality | No | lg_code の代わりに市町村名でもよい（日本語かローマ字） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely non-structured behavior: this is a paid call costing $0.005 via x402 in USDC on Base Sepolia (testnet), which is critical for an agent to know before invoking. It does not cover failure behavior (invalid lg_code, ambiguous municipality name) or latency.
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?
It is one dense sentence that front-loads the tool identity and payload list with no filler. The enumeration is long but every item is a substantive return field; the price note is placed at the end, which is reasonable.
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 must convey return content — and it does, field by field, plus the payment model. Missing only error/ambiguity handling and how municipality-name resolution interacts with prefecture, which the schema partly covers.
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 100%, so lg_code (6-digit national code with example), prefecture, and municipality are fully documented in the schema. The description adds nothing beyond that, merely implying a single-municipality lookup; baseline 3 applies.
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 names a specific resource (one municipality's dossier) and enumerates its payload precisely: 区分・窓口・通報先・補助/奨励金・近い被害地域5件と距離・県の報道. An agent knows exactly what it gets. However, it never distinguishes itself from the sibling get_municipality_status, which sounds like it returns overlapping information.
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?
There is no explicit when-to-use or when-not-to-use statement, and no sibling is named as an alternative. The content enumeration implies 'use when you need a full municipality profile,' but that is inference only, and with a near-duplicate sibling (get_municipality_status) the absence of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
日本の市町村名（例: 菰野町、さいたま市、Kuwana）から、クビアカツヤカミキリの被害の状態、その市町村で新たに見つかった被害、使える奨励金・補助を返す
| Name | Required | Description | Default |
|---|---|---|---|
| prefecture | No | 都道府県名（同じ名前の市町村を絞るとき。任意） | |
| municipality | Yes | 市町村名。日本語かローマ字。市・町・村は付けても付けなくてもよい |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful fact that this is an aggregating lookup returning three distinct data categories. It says nothing about behavior when a municipality is unknown, ambiguous, or has no recorded detections, which matters for a name-based lookup.
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?
A single sentence that front-loads the input and then enumerates outputs; nothing is redundant. It is slightly dense, packing input examples and three output categories into one clause, but every element earns its place.
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 correctly compensates by naming what comes back, which is the key missing structured information. For a two-parameter read-only lookup this is nearly sufficient; ambiguity handling and the relationship to sibling tools are the remaining gaps.
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 coverage is 100% and both parameters are described there, including that municipality accepts Japanese or romaji with or without the 市/町/村 suffix and that prefecture is optional for disambiguation. The description's examples reinforce but add no new semantic information. Baseline 3 applies when the schema does the heavy lifting.
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 names a specific verb (returns) and resource (municipality status) and enumerates the three payload categories: damage status, newly found detections, and available subsidies. That is far clearer than the title alone. It does not, however, distinguish itself from siblings like list_new_detections or list_rewards_and_subsidies, which appear to cover the same data globally.
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?
Usage is only implied: give a Japanese municipality name and get its aggregated status. The examples (菰野町, さいたま市, Kuwana) clarify accepted input forms, but there is no explicit statement of when to pick this tool over get_municipality_dossier or the two list_* siblings, nor any precondition or failure guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
国の一覧（2026年9月11日）のあとに新たに被害が見つかった市町村の一覧。日付・内容・出典つき
| Name | Required | Description | Default |
|---|---|---|---|
| prefecture | No | 都道府県名で絞る（任意） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and openWorldHint=false annotations already establish that this is a safe, closed-domain read. The description adds value by saying each entry carries a date, content, and source, which tells the agent what the records contain. However, it does not say whether the list is cumulative from 2026-09-11 onward or how complete it is.
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, with the defining scope constraint, the 2026-09-11 baseline, front-loaded. Nothing is redundant, though the phrasing is slightly compressed and could state the list's nature more explicitly.
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 list tool with read-only annotations and no output schema, the description covers what is returned at a high level (date, content, source). But it leaves the relationship to nearby siblings ambiguous and does not clarify the temporal boundary, which matters for a 'newly found' dataset.
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 coverage is 100%, so the optional prefecture filter is already fully documented in the schema. The description does not mention filtering at all, adding no semantics beyond the schema. Baseline 3 applies when the schema does the work.
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?
It clearly states the resource: municipalities where damage was newly discovered after the national list of 2026-09-11. The baseline date makes the scope concrete. However, it never distinguishes this list from the similarly named sibling get_changes_since, so an agent must infer the boundary.
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?
There is no guidance on when to call this rather than get_changes_since, get_municipality_status, or get_municipality_dossier. The agent must guess based on the name alone, which is risky given the overlapping 'changes since' concept.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
成虫を捕まえた人への奨励金・報奨金と、木の持ち主が使える防除・伐採の補助。受付の状態と確かめた日つき
| Name | Required | Description | Default |
|---|---|---|---|
| only_open | No | 受付中だけにする（既定 true） | |
| prefecture | No | 都道府県名で絞る（任意） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful return-content context — records carry an acceptance status and a confirmed date — which matters because there is no output schema. It does not discuss ordering, completeness, or the effect of the default filter.
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 compact clauses with no filler, front-loading the resource type and then the record contents. Slightly compressed to the point of omitting an action verb.
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 simple two-parameter read tool with full schema coverage and annotations, this is nearly adequate, and the mention of status and confirmation date substitutes for the missing output schema. It still leaves the agent guessing about the listing action and whether results are aggregated per municipality.
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 100%: only_open (default true) and prefecture are fully documented in the schema itself. The description adds no parameter-level detail such as accepted prefecture name formats, so baseline 3 applies.
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 names the specific resource precisely: incentives/rewards for people who capture adult beetles, plus control/felling subsidies available to tree owners. This clearly separates it from siblings like list_new_detections and get_municipality_dossier. It lacks an explicit verb (the 'list' action is only implied by the tool name and the enumeration of record types).
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?
No statement of when to use this versus alternatives such as list_new_detections or get_municipality_dossier, and no prerequisites or exclusion conditions. The agent must infer usage from the resource noun alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_changes_sinceget_municipality_dossierget_municipality_statuslist_new_detectionslist_rewards_and_subsidiesFacility-level industrial pollutant releases across 33 European countries (official E-PRTR data).
Purpose-aware accessibility scoring for every coordinate in Japan.
UK pest, disease, and weed management — symptom diagnosis, IPM, approved products
Disaster risk for any Japanese address from official government data. 6 hazards, sources cited.
Add one secure layer between your agents and this server.
