e-Stat MCP

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, establishing this as a safe, non-destructive read operation with potentially large result sets. The description adds valuable context about the tool's purpose being for 'overview and listing' rather than detailed data retrieval, which helps the agent understand appropriate use cases beyond what annotations provide. No contradictions with annotations exist.

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 perfectly concise with two sentences that each serve distinct purposes: the first defines what the tool retrieves, the second specifies its intended use cases. There's no wasted language, repetition, or unnecessary elaboration, making it highly efficient for agent comprehension.

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?

Given the tool's complexity (14 parameters, no output schema) and rich annotations, the description provides adequate context about the tool's purpose and usage. However, without an output schema, some additional guidance about return format or result structure would be helpful, though the annotations (openWorldHint) suggest potentially large result sets.

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?

With 100% schema description coverage, the input schema already provides comprehensive documentation for all 14 parameters including detailed enum descriptions. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline for high schema coverage without compensating value.

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 clearly states the specific action ('取得する' - retrieve/get) and resource ('統計データベースのカタログ情報' - statistical database catalog information), including what information is retrieved (statistical names, descriptions, availability, related links). It explicitly distinguishes the purpose from data retrieval by stating this is for 'overview understanding and listing purposes' rather than actual data access.

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 description provides clear context about when to use this tool ('統計データの全体像把握や一覧表示用途に使用する' - for understanding the overall picture of statistical data and listing purposes). However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools (e-stat-get-meta-info, e-stat-get-stats-list), though the purpose differentiation implies usage scenarios.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe read operation with potentially incomplete information. The description adds valuable context about what kind of meta information is retrieved ('分類項目、地域区分、時間軸、表章事項などの構造情報' - structural information like classification items, regional divisions, time axis, presentation items), which helps the agent understand the nature of the returned data beyond just knowing it's read-only.

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?

Perfectly concise with two sentences: the first states what the tool does and its input dependency, the second explains its purpose. Every word earns its place with zero redundancy. The description is front-loaded with the core functionality.

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 tool with good annotations and full schema coverage, the description provides excellent context about when to use it and what information it returns. The main gap is the lack of output schema, but the description gives a good sense of what meta information to expect. It could be slightly more specific about the format/structure of the returned meta information.

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?

With 100% schema description coverage, the schema already fully documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 is appropriate since the schema does all the parameter documentation 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?

The description clearly states the specific action ('取得する' - retrieve/acquire) and resource ('メタ情報' - meta information) with explicit scope ('統計表IDに基づいて' - based on statistics table ID). It distinguishes from sibling tools by specifying it's for meta information after using e-stat-get-stats-list, unlike e-stat-get-data-catalog which presumably gets catalog data.

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?

Explicitly states when to use ('e-stat-get-stats-list ツールで取得した統計表IDに基づいて' - based on statistics table ID obtained from e-stat-get-stats-list tool) and the purpose ('統計データの項目構成や取得可能な条件値を把握するために使用する' - used to understand item structure and available condition values of statistical data). It clearly positions this as a follow-up to e-stat-get-stats-list.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering safety and data scope. The description adds useful context: it clarifies that the output contains metadata (not actual statistical values) and is for search/identification purposes. However, it does not disclose additional behavioral traits like rate limits, authentication needs, pagination behavior (implied by 'startPosition' but not explained), or error handling.

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 a single, dense sentence that efficiently conveys purpose, scope, inclusions/exclusions, and usage context. It is front-loaded with the core action ('取得する') and avoids redundancy. Every part earns its place by adding value beyond the tool name/title.

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?

Given the tool's complexity (12 parameters, no output schema) and rich annotations, the description is mostly complete. It clarifies the tool's role in a workflow (search/identification) and output nature (metadata only). However, without an output schema, the description could better hint at the response structure or pagination behavior, leaving a minor gap for a fully informed agent.

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%, with detailed descriptions for all 12 parameters including enums and formats. The description does not add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't explain how parameters interact or provide usage examples). Baseline is 3 when schema coverage is high, as the schema carries the full burden.

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 clearly states the tool's purpose: '取得する' (retrieve) a list of statistical tables and basic information from e-Stat. It specifies what is included (statistical table ID, statistical name, survey date, publication date) and explicitly excludes actual statistical values, distinguishing it from potential data-fetching siblings like 'e-stat-get-data-catalog'.

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 description provides clear context for usage: '統計データの検索・特定用途に使用する' (used for searching/identifying statistical data). It implies this is for discovery/metadata purposes, not for retrieving actual data values. However, it does not explicitly state when to use this tool versus its siblings (e-stat-get-data-catalog, e-stat-get-meta-info), which would be needed for a score of 5.

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