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

No annotations provided, yet description comprehensively discloses: internal GraphQL usage, automatic pagination with nextDataRequestToken, API limit of 1000 per batch, WGS84 coordinate system, response format differences based on include_metadata (lightweight id/title only vs full), and termination condition (stops when data empty).

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?

Excellent structure with clear sections (purpose, usage, examples, cautions). Information is front-loaded with the core purpose, followed by implementation details, concrete examples, and critical constraints. No redundant text; every sentence provides actionable guidance or constraints.

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 complex 15-parameter tool with batch processing and no output schema, the description is comprehensive. It explains the pagination mechanism, response payload variations, coordinate systems, and batch control logic. Minor gap: could explicitly state this is read-only (though implied by '取得'), but behavior is otherwise fully specified.

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 has 100% coverage (baseline 3), but description adds crucial semantic relationships: max_items takes priority over max_batches, size=1000 is the API maximum and tool default, coordinate ordering (NW top-left to SE bottom-right), and that prefecture_code requires prior normalization via sibling tool. Examples demonstrate valid parameter combinations.

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?

Opening sentence '条件に当てはまる大量のデータを取得する' clearly states the specific action (retrieve large batch data) and scope. It distinguishes from siblings like get_data or search by emphasizing batch processing ('バッチで取得'), automatic pagination, and large-scale retrieval capabilities ('大量件数').

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?

Dedicated '使い方' section explains exactly when to use (large batch retrieval) and how to combine filters (term + attributes/rectangle). Three concrete examples cover different scenarios (dataset retrieval, rectangle-based, prefecture scan). '注意' section explicitly states critical when-not constraints: locationFilter cannot be used alone, and nextDataRequestToken ignores other conditions.

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?

アノテーションがないため説明が全ての負担を担う。slice_sizeの上限50、上位値のみ返却（それ以外省略）、locationFilter単独では検索不可といった制約を明記。座標系（WGS84）や矩形の頂点順序などの技術仕様も開示。読み取り専用であることは「件数を取得」という表現から暗示されるが、明示的な安全宣言があれば完璧だった。

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?

19パラメータを持つ複雑なツールのため適切な長さ。用途→使い方（箇条書き）→具体例→注意事項という構造が論理的。具体例4つはパラメータ組み合わせの理解に不可欠。冗長な部分はなく、各文が価値を持っている。

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?

出力スキーマがないにも関わらず、返却値の性質（上位N件のみ、dataCountに含まれる範囲）を説明。空間検索の制約、パフォーマンス上の推奨フロー、属性フィルタの演算子対応など、複雑な集計ツールとして必要な情報が網羅されている。

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?

スキーマ記述カバレッジ100%のためベースライン3。説明はlocation_*引数が内部でlocationFilterに変換されること、catalog_id等がattributeFilterに変換されることを付加。slice_typeの値（dataset/attribute）のセマンティクスと使用パターンを具体例と共に詳説し、パラメータ間の相互作用を明確にしている。

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?

明確に「指定した検索条件に一致するデータの件数を取得する」と述べており、動詞（取得）と対象（データ件数）が具体的。兄弟ツールとの差別化も明確で、「get_all_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?

「まずget_count_dataでボリューム見積り→必要に応じてget_all_dataで実データ取得が推奨」と明確な使い分けを指示。slice_typeの選択基準（dataset vs attribute）や空間条件と属性条件の組み合わせ要件も詳細に説明している。

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?

With no annotations provided, the description carries the full burden and discloses several behavioral traits: GraphQL API correspondence (data(dataSetID:, dataID:)), error handling for non-existent IDs (totalNumber=0), and schema dependency (MLIT DPF). Deducting one point because it doesn't explicitly confirm read-only/safety status or mention rate limits, though 'get' implies safe read semantics.

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 structured with four distinct, front-loaded sections: purpose statement, usage guidelines, concrete examples, and technical notes. Every sentence earns its place without redundancy. The length is appropriate for the tool's complexity and the lack of output schema annotations.

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 2 simple parameters with full schema coverage and no output schema, the description is comprehensive. It explains what is returned (title以外の各種メタ情報), error conditions, schema dependencies, and client-side recommendations (フィールド選択推奨). No critical gaps remain for an AI agent to invoke this tool 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 coverage is 100% (both parameters have descriptions), establishing a baseline of 3. The description adds value by specifying data_id provenance (must come from search results DataClass.id), providing concrete examples (dataset_id='cals_construction', data_id UUID format), and mapping to GraphQL parameter names.

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?

Description opens with a specific verb+resource combination (データの詳細情報を取得する/retrieve detailed data information) and explicitly defines the required inputs (dataset_id and data_id). It clearly distinguishes this from siblings by contrasting with the search API (検索APIで拾ったidを使って), establishing this as a direct retrieval tool versus a discovery tool.

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?

Contains an explicit '使い方' (Usage) section stating exactly when to use this tool versus alternatives: 'すでに対象が確定している場合、検索よりも効率的' (When the target is already determined, more efficient than search). It explicitly names the sibling tool 'search' as the prerequisite source for IDs, creating a clear workflow distinction.

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?

With no annotations provided, the description effectively discloses performance characteristics (labels operations as '重い'/heavy or '軽量'/lightweight), warns about large data volumes ('大量になる'), and specifies the return structure conforms to DataCatalogClass with enumerated fields.

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?

Well-structured with clear section headers (使い方/例/注意) that front-load critical information. Slightly verbose with some repetition between usage patterns and examples, but every section serves a distinct purpose (theory vs concrete examples vs technical spec details).

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 no output schema exists, the description adequately compensates by specifying the return type (DataCatalogClass) and listing representative fields (title, description, publisher, modified, datasets). Also covers performance implications and parameter interactions comprehensively.

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?

While schema has 100% description coverage (baseline 3), the description adds significant practical context beyond the schema: explains that omitting ids is equivalent to null internally, clarifies the trade-offs between minimal=true/false, and details what include_datasets actually retrieves (metadata definitions, record counts).

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 it retrieves '詳細情報' (detailed information) of data catalogs/datasets, distinguishing it from the sibling tool 'get_data_catalog_summary'. The specific verb+resource combination is unambiguous.

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?

Excellent explicit guidance with dedicated sections: '使い方' explains when to use specific parameter combinations (heavy vs recommended vs lightweight), '例' provides concrete parameter sets, and '注意' clarifies the official API spec behavior regarding null IDs.

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?

With no annotations provided, the description carries the full burden. It discloses that returns are 'ID/タイトル中心の軽量情報' (lightweight ID/title-focused info), explains the internal API behavior matching 'IDs=null', and clarifies what is NOT returned (detailed metadata/dataset lists). Minor gap: lacks pagination or exact return structure details.

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 uses clear structural sections (使い方/Usage, 例/Examples, 注意/Notes) that front-load the purpose statement. While the Japanese formatting with indentation consumes space, every sentence provides actionable guidance or behavioral context without redundancy.

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?

Despite having no output schema and no annotations, the description adequately describes the return content qualitatively ('ID/タイトル中心の軽量情報'). It thoroughly covers sibling relationships and usage contexts. Minor gap: lacks exact return value structure specification.

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?

Input schema has 0 parameters, establishing a baseline of 4. The description adds value by explaining the implicit behavior: '引数なし（内部的に IDs=null 相当）' clarifies what happens when called with no arguments, effectively documenting the parameter-less invocation pattern.

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 opening sentence 'データカタログ・データセットの基本情報（ID、タイトル）を取得する' provides a specific verb (取得する/get) and resource (データカタログ・データセット). It clearly distinguishes itself from sibling 'get_data_catalog' by stating that detailed metadata requires that alternative instead.

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 '使い方' section explicitly outlines when to use no arguments (for all catalogs) versus when to use 'get_data_catalog' with minimal=True. The '注意' section explicitly names 'get_data_catalog' as the alternative for detailed metadata needs, providing clear when/when-not guidance.

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?

With no annotations provided, description carries full burden. It discloses the 'totalNumber=0' behavior when IDs don't match, clarifies this returns only basic info vs full details, and explains the lightweight nature of the operation. Lacks explicit read-only/safety declaration but implies it through context.

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?

Excellent structure with clearly delineated sections (purpose, usage, examples, notes). Japanese formatting uses line breaks effectively. Every sentence provides distinct value - no redundancy.

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 2-parameter lookup tool with no output schema, description is complete. It explains return content (basic info), error cases, prerequisites (search API), and sibling alternatives. No gaps given the tool's simplicity.

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?

Despite 100% schema coverage (baseline 3), description adds concrete value through usage examples showing actual ID formats (e.g., 'cals_construction', 'mlit-001', UUID pattern) and reinforces that IDs come from search tool results.

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?

Description explicitly states it retrieves basic information (data ID, title) using dataset and data IDs. It clearly distinguishes from sibling tool get_data by stating this is for summary/basic info while get_data is for detailed 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?

Contains explicit '使い方' (usage) section describing when to use (when IDs are already known, for lightweight retrieval, for preview). Explicitly names search API as prerequisite for obtaining IDs and get_data as alternative for detailed information.

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?

No annotations provided, so description carries full burden. Discloses critical behavioral trait: URLs starting with specific domain have 60-second expiration ('60秒以内にダウンロード開始が必要'). Explains default behavior when original_path is omitted. Missing: error handling details, auth requirements, and exact return structure (though no output schema exists).

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?

Well-structured with clear visual hierarchy: purpose statement → usage patterns → examples → warnings. Front-loaded with core function. Lengthy but justified by complexity (two usage modes, time constraints, prerequisites). Minor deduction for slightly verbose Japanese prose style, but every sentence provides actionable guidance.

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?

Comprehensive coverage of prerequisites, temporal constraints (60s expiration), and parameter interactions for a 3-parameter tool with complex conditional logic. Lacks description of return value structure (expected since no output schema provided) and error scenarios. Sufficient for safe invocation but could note rate limiting or failure modes.

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 has 100% coverage (baseline 3). Description adds substantial value: concrete JSON syntax examples for files parameter, explanation of the XOR relationship between files vs dataset_id/data_id, and data lineage guidance ('search / data のレスポンスに含まれる DataClass.files から取得'). Compensates for schema's lack of conditional validation.

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?

Opens with specific verb-resource pair 'ファイルのダウンロード用URLを取得する' (Get file download URLs). The description clearly distinguishes this from sibling get_zipfile_download_url through its focus on individual file arrays versus zip archives, and explains the dual input patterns (direct files array vs dataset/data_id lookup).

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?

Contains explicit '使い方' (Usage) section stating prerequisites ('事前に search / data API で...取得してから'), describes two mutually exclusive usage patterns (A) and (B), and notes alternatives ('連携元サイトで直接ダウンロードできる場合は...DPF:downloadURLs...を併用'). Clearly defines when to use each parameter combination.

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?

With no annotations provided, the description carries the full burden. It discloses critical behavioral traits: requires MLIT DPF GraphQL endpoint and API key, returns `null` when mesh not found (empty result behavior), and returns a JSON object containing mesh codes and indicators. Minor gap: no rate limit or error handling details mentioned.

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?

Well-structured with clear sections (Usage, Examples, Notes). Information is front-loaded with the prerequisite workflow. Minor deductions for `:contentReference` artifacts (likely documentation import noise) and slight repetition regarding null return behavior, but overall efficiently organized.

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?

No output schema exists, and the description adequately compensates by specifying the return type (JSON object with mesh codes/indicators) and null handling. Complex prerequisite workflow is fully documented. Minor gap: could elaborate on the specific structure of the returned JSON object.

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%, establishing baseline 3. The description adds significant value by explaining where each ID originates (`dataset_id` from search response's `dataset_id`, `data_id` from `id`, etc.) and noting that `mesh_code` accepts arbitrary dimensions (e.g., 250m). This semantic context exceeds the schema's basic type definitions.

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 opens with a clear, specific verb phrase 'メッシュに含まれるデータを取得する' (Retrieve data contained in the mesh). It effectively distinguishes from siblings like `get_data` or `get_all_data` by emphasizing the mesh-specific retrieval workflow and prerequisite `search` call required to obtain the specific IDs.

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?

Explicit '使い方' (Usage) section provides clear prerequisites: must call `search` API first to obtain `dataset_id`, `data_id`, and `mesh_id` before invoking this tool. It also specifies the exact source of each parameter in the search response, creating an unambiguous workflow.

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?

No annotations provided, but description carries full burden effectively. Warns about large result sets (大量件数) when unfiltered, specifies GraphQL specification details, explains that wards (区) are independent entries, and documents return class structure (MunicipalityClass fields) despite absence of output schema.

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?

Well-structured with clear visual hierarchy: purpose → usage patterns → concrete examples → important notes. Despite length, every section serves distinct purpose. Front-loaded with core function, followed by progressively specific implementation details. No redundant repetition of schema types.

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 4-parameter query tool with 0 required parameters, description adequately warns about unfiltered usage returning massive datasets. Documents return structure (MunicipalityClass fields including validity periods) compensating for missing output schema. Would benefit from pagination or rate limit notes for perfect score.

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% (baseline 3), but description adds significant semantic value: explains pref_codes accepts multiple prefecture codes, recommends 6-digit string format for muni_codes, documents fields parameter for client-side optimization, and clarifies via examples that empty arrays return all data.

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?

Opening line '市区町村名・市区町村コード一覧を取得する' provides specific verb (取得する/get) and resource (市区町村名・コード一覧). Clearly distinguishes from sibling get_prefecture_data by specifying municipality-level (市区町村) rather than prefecture-level (都道府県) 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?

Extensive '使い方' section explains exactly when to use each parameter pattern (no filter for national data, pref_codes for prefecture filtering, muni_codes for specific municipalities). Provides concrete examples for each scenario. Lacks explicit comparison to sibling tools like get_prefecture_data, but parameter-level guidance is exemplary.

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?

No annotations provided, so description carries full burden. It discloses that the tool always returns all prefectures (常に全都道府県を返します), explains the GraphQL return structure, details available fields (code_as_string, hiragana, romaji, etc.), and notes data format specifics (2-digit codes with leading zeros).

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?

Well-structured with clear sections (使い方, 例, 注意). Information is front-loaded with the core purpose first. Slightly verbose in the GraphQL field examples, but remains readable and purposeful.

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 zero-parameter tool, the description comprehensively compensates for the missing output schema by detailing all return fields, their data types (string vs number), and semantic meaning (official codes vs short names), providing sufficient context for invocation.

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?

Input schema has 0 parameters with 100% coverage (baseline 4). The description explicitly confirms there are no parameters (パラメータはありません) and explains the implication (always returns all prefectures), which validates the empty schema design.

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?

Description clearly states it retrieves the list of prefecture names and codes (都道府県名・都道府県コード一覧を取得する). It specifically mentions the 47 prefectures (47都道府県), distinguishing it from generic sibling tools like get_data or search.

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?

Provides clear usage instructions (使い方) explaining no arguments returns all 47 prefectures and mentions client-side field selection. However, it lacks explicit guidance on when to use this versus generic alternatives like get_data or search.

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?

With no annotations provided, the description carries the full burden. It discloses the return format (array containing name and cnt fields), explains the internal GraphQL implementation ('GraphQL suggest(term, phraseMatch, attributeFilter?) を使用'), and notes critical constraints (term is required, empty strings invalid).

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?

Excellent structure with clear section headers (使い方, 例, 注意). Information is front-loaded with the core purpose, followed by usage patterns, concrete examples, and caveats. No redundant text; every sentence provides actionable guidance.

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 an 11-parameter tool without an output schema, the description is comprehensive. It explains the return data structure (name/cnt array), provides multiple usage scenarios covering different parameter combinations, and documents the internal API mechanism. Missing only minor details like rate limits or auth requirements.

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?

While the schema has 100% description coverage (baseline 3), the description adds significant semantic value by explaining that phrase_match adjusts matching toward exact matches, and clarifying that filtering parameters are internally mapped to an attributeFilter structure. This context aids proper parameter combination.

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 'キーワード検索の候補を表示する' (displays keyword search candidates/suggestions). It effectively distinguishes this from sibling search tools (search, search_by_attribute, etc.) by emphasizing autocomplete/suggestion functionality versus full record retrieval.

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 '使い方' section provides clear guidance on when to use phrase_match for exact-match preferences and how to apply filters (catalog_id, dataset_id). It references the relationship to search operations ('search と同様に'), though it could more explicitly state when to choose this over the main search tools.

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?

No annotations provided, so description carries full burden. Discloses critical 60-second URL expiration for download domain URLs, empty array behavior when thumbnails don't exist, and response structure (array with fileName/URL). Does not mention rate limits or caching behavior, but covers the essential operational constraints.

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?

Well-structured with clear sections: purpose → usage patterns → examples → warnings. Despite length, every section provides distinct value (examples show concrete syntax, notes contain critical 60-second expiration warning). Front-loaded purpose statement followed by progressive detail.

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?

No output schema provided, but description compensates fully by detailing response format ('配列で、各要素は fileName / URL を含みます'), edge case behavior (empty array return), and temporal constraints (60s expiration). Complete coverage for a tool with dual invocation modes and no annotations.

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 has 100% coverage (baseline 3). Description adds crucial semantic context: explains the mutually exclusive usage modes (direct thumbnails array for 'fast' path vs dataset lookup), clarifies that 'id' corresponds to GraphQL fileID from search results, and documents the relationship between dataset_id and data_id parameters.

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?

Opening sentence 'データのサムネイル画像URLを取得する' provides specific verb (取得する) + resource (サムネイル画像URL). Clearly distinguishes from sibling get_file_download_urls by focusing specifically on thumbnail images rather than file downloads.

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?

Explicit '使い方' section documents two distinct invocation patterns (A: direct thumbnails array vs B: dataset_id/data_id lookup). Explains when to use file-level filtering ('ファイル個別のサムネイルが欲しい場合') and references integration with search/data results. Lacks explicit comparison to sibling alternatives like get_file_download_urls.

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?

With no annotations provided, the description carries full behavioral disclosure burden. It explicitly warns that download URLs are valid for only 60 seconds (critical operational constraint), notes client-side timeout risks for large ZIPs, and reveals the underlying GraphQL implementation structure.

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 well-structured with clear sections (purpose, usage, examples, warnings) and front-loaded critical information. It is slightly verbose with the GraphQL implementation detail at the end, which is unnecessary for tool selection, but overall efficiently organized.

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 no output schema and no annotations, the description adequately explains the return value (URL string) and operational constraints (60s expiry, large file timeouts). It could be improved by mentioning error conditions (e.g., invalid file IDs) or whether the ZIP resource persists after URL expiry.

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?

Despite 100% schema coverage (baseline 3), the description adds substantial semantic value: it explains that files and dataset_id/data_id represent mutually exclusive usage modes, clarifies that original_path determines the storage path inside the ZIP, and provides concrete IFC file examples showing valid input structures.

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 opening sentence clearly states the tool compresses multiple attachments into ZIP format and retrieves a download URL, with the critical detail that the URL expires in 60 seconds. This clearly distinguishes it from sibling get_file_download_urls which handles individual files.

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 '使い方' section explicitly documents two distinct invocation patterns: (A) passing a files array directly with id/original_path, or (B) using dataset_id/data_id for simplified retrieval. It specifies that parameters should come from search/data results, providing clear guidance on when to use each pattern.

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?

Without annotations, the description carries the full burden. It effectively discloses normalization behavior (handling Tokyo/Tokyo/13/full-width numbers) and ambiguous input handling (候補一覧取得). Minor gap: no output structure details provided despite lacking output schema.

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?

Well-structured with clear sections: one-sentence purpose, numbered use cases (1-3), and integration guidance. No redundant text; every sentence conveys critical information about functionality or usage context.

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 2-parameter normalization tool, the description adequately covers intent and usage patterns. While it lacks explicit output schema documentation, the use cases imply return values (codes + names), making it sufficient for agent selection given the tool's limited complexity.

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% with comprehensive parameter descriptions (codes, Japanese, romaji formats, full-width normalization). The main description adds use case context but does not supplement parameter semantics beyond what the schema already provides, warranting the baseline score.

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 normalizes prefecture/municipality names and retrieves official codes/names (都道府県名・市区町村名を正規化し、正式なコードと名称を取得する). It specifically distinguishes itself from data retrieval siblings by positioning as an input normalization utility.

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 instructs to use this tool before other search tools (このツールを他の検索ツールの前に実行することで), clearly establishing its role as a preprocessing step for the sibling data retrieval tools (get_data, search, etc.).

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?

With no annotations provided, the description carries the full burden and discloses key behavioral traits: the 10,000-item API limit, that phrase_match controls synonym vs exact matching, and that minimal=True returns only main fields. It could be improved by explicitly stating the read-only nature or error handling patterns.

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?

Excellent structure with clearly delineated sections (使い方, 例, 注意). Every sentence serves a purpose—examples demonstrate parameter interactions, notes clarify boundaries, and formatting makes the 7-parameter configuration scannable. No redundancy despite the length.

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 7 parameters, zero annotations, and no output schema, the description is remarkably complete. It covers all parameter interactions, API limits, and sibling tool references. A brief mention of the return value structure (implied only through minimal parameter description) would achieve a 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?

While the schema has 100% coverage (baseline 3), the description adds significant value through concrete usage examples (e.g., term='橋梁', sort_attribute_name='DPF:updated_at'), explains the practical difference between phrase_match=true/false (synonyms vs exact), and clarifies the lightweight response behavior of the minimal flag.

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 opens with a clear action statement (キーワードを使って検索する) and immediately distinguishes this tool from its siblings by explicitly stating it does NOT handle spatial conditions or metadata filtering, directing users to search_by_location_rectangle, search_by_location_point_distance, and search_by_attribute instead.

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?

Provides explicit when-to-use and when-not-to-use guidance: it notes that empty string searches are possible but spatial/metadata filtering requires other tools. It also names specific alternatives and explains pagination requirements for large datasets ('APIの上限は一度に最大10,000件').

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?

No annotations provided, so description carries full burden. Discloses that operator is always 'is' (fixed), term can be empty for attribute-only search, and minimal=True produces lightweight responses. However, missing safety profile (read-only nature), rate limits, error conditions, or return value structure details expected for a search tool without annotation hints.

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?

Well-organized with clear sections: overview, GraphQL syntax note, usage guidelines, examples, and cautions. Japanese text is appropriately detailed for the complexity of DPF namespace requirements. Minor verbosity in example formatting is acceptable for clarity. No redundant sentences.

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 7 parameters and no output schema, the description comprehensively covers input requirements and usage patterns but omits description of return values, result structure, or pagination behavior (beyond schema definitions of first/size). For a search tool lacking both annotations and output schema, it should describe what gets returned to achieve higher completeness.

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?

While schema has 100% coverage with detailed descriptions, the description adds valuable semantic context including concrete examples ('mlit-001', '13' for Tokyo, '13101' for Chiyoda) and explicit usage patterns for attribute_name/value pairs. This helps agents understand valid value formats beyond schema syntax.

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?

Description clearly states the tool searches using metadata items (catalog names, dataset names, prefectures, municipalities) with specific examples. It effectively distinguishes from siblings like generic 'search' and location-based tools by emphasizing structured attribute filtering (DPF: prefixes) rather than keywords or coordinates.

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?

Contains explicit '使い方' (Usage) section explaining to specify attribute_name/value pairs and that term keyword can be combined for finer conditions. Provides three concrete use-case examples (dataset-specific, prefecture-specific, catalog-specific). Lacks explicit 'when not to use' comparisons to sibling tools, but positive guidance is comprehensive.

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?

No annotations provided, so description carries full burden. Discloses WGS84 coordinate system, phrase_match exact-match behavior, and performance warning about large radii increasing result count. However, lacks disclosure of result sorting (distance vs relevance), error behavior for invalid coordinates, or rate limiting concerns.

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?

Excellent structure with clear visual separation: Purpose → Usage → Examples → Notes. Each section is dense with actionable information. Examples use consistent formatting (parameter=value) that mirrors actual API calls. No filler text; even the '注意' section provides specific constraints (3 required params, max results control).

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?

Comprehensive for input handling with 8 parameters fully contextualized. Covers coordinate system, pagination hints (size control), and search modes. However, given no output schema exists, the description should ideally characterize return values (e.g., 'returns list of spatial data records') rather than just stating 'search 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?

Despite 100% schema coverage (baseline 3), description adds substantial value through concrete examples with real coordinates (Tokyo Station 35.681236, 139.767125), clarifies empty string usage for term, and emphasizes the meter unit for distance. The examples effectively demonstrate parameter interaction patterns beyond individual field descriptions.

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?

Description opens with a precise statement: '指定した地点と半径によって作成される円形範囲と交差するデータを検索する' (Search for data intersecting with the circular range created by specified point and radius). This provides specific verb (検索/search), resource (データ/data), and geometric scope (circular range) that clearly differentiates it from sibling rectangle-based and attribute-based search tools.

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?

Provides excellent practical guidance through '使い方' (How to use) and three concrete examples showing spatial-only vs spatial+text search patterns. Explicitly notes that term can be empty for location-only searches. However, lacks explicit comparison to siblings (e.g., when to use search_by_location_rectangle vs this tool).

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?

With no annotations provided, the description carries full behavioral disclosure burden effectively. It specifies the coordinate system (WGS84), clarifies intersection logic (交差/intersecting vs containing), notes rate limits (10,000 items), and explains coordinate ordering constraints (NW must have higher latitude than SE).

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?

Well-structured with clear visual hierarchy: purpose statement → usage guide → concrete examples → notes/cautions. The examples, while lengthy, provide essential concrete values. The warning about coordinate ordering is appropriately prominent. Slightly verbose but justified by the 9-parameter complexity.

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 9 parameters, no annotations, and no output schema, the description provides comprehensive coverage of input requirements, constraints, and usage patterns. It lacks description of return values, but without an output schema provided in the system, this is acceptable. The cross-reference to normalize_codes demonstrates awareness of the broader tool ecosystem.

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 baseline is 3. The description adds concrete example values (35.80, 139.55) and coordinate ordering constraints not in the schema. However, it contradicts the schema regarding the 'size' parameter limit (description states max 10,000; schema states max 500), creating potential confusion for the agent.

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 searches for data intersecting with a rectangular range ('矩形範囲と交差するデータを検索する'). It uses a specific verb (検索/search) and resource (data by rectangle), and distinguishes itself from siblings like search_by_location_point_distance (radius) and search_by_attribute through its focus on bounding box coordinates.

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?

Provides explicit usage patterns under '使い方' with concrete examples showing both spatial+keyword and spatial-only searches. Notably references sibling tool normalize_codes for prefecture_code normalization ('normalize_codesツールで正規化できます'), giving clear cross-tool guidance. Would score 5 if it explicitly contrasted when to use radius search (search_by_location_point_distance) versus this rectangle search.

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