Skip to main content
Glama
Izyuusya
by Izyuusya

search_statistics

Search Japanese statistical tables by keyword, with optional filters for survey years and statistical field to locate relevant data.

Instructions

キーワードで統計表を検索する.

Args: keyword: 検索キーワード(例: "人口", "国勢調査", "県内総生産") survey_years: 調査年で絞り込み(例: "2020", "2015-2020") stats_field: 統計分野コードで絞り込み(例: "02"=人口・世帯)。 list_available_stats で分野一覧を確認できます。 limit: 取得件数上限(デフォルト10)

Returns: 検索結果の統計表一覧(ID・統計名・タイトルなど)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
keywordYes
stats_fieldNo
survey_yearsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations, the description carries the behavioral burden. It discloses that the tool returns a list of statistical tables with IDs, names, and titles, and the verb '検索' implies a read-only operation. However, it does not explicitly confirm side-effect-free behavior, authorization requirements, or behavior when no results are found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-organized: a one-line purpose, then Args and Returns sections. Every line adds value, including parameter examples and the sibling pointer. No redundant or vague prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter tool with an output schema, the description covers all parameters, return shape, and a related sibling. Minor gaps remain: no explicit guidance about pagination or zero-result behavior, and no comparison against sibling search tools. Still, an agent can call the tool correctly with the provided information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does so thoroughly: every parameter gets an example or format note, including survey_years ranges ('2015-2020'), stats_field codes ('02'=人口・世帯), and limit's default. The pointer to list_available_stats adds actionable cross-tool context.

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?

The description opens with a specific verb and resource ('キーワードで統計表を検索する') and immediately shows example keywords and filters. This clearly distinguishes search_statistics from siblings like search_corporations, get_population, and list_available_stats by scope and intent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for keyword-based statistical table search and points to list_available_stats for stats_field codes. However, it does not explicitly state when to prefer this tool over siblings such as get_population or compare_regions, nor when not to use it.

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