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

With no annotations, the description carries full burden. It discloses that PDF guidelines are text-extracted and that section search is supported, adding behavioral nuance beyond a simple retrieval. It does not explain the return format or error handling, but for a read-only getter, it provides reasonable transparency.

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 front-loaded with the purpose, followed by a structured list. Although lengthy, the bullet-style mapping and search capability note are each useful and directly support correct parameter usage. It is concise for the amount of information conveyed.

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 two-parameter getter with no output schema, the description covers the essential usage: supported resources, input naming conventions, and search behavior. It omits details like return format or queuing, but these are less critical given the tool's simple retrieval nature.

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 value by enumerating all valid guideline names and their formal equivalents, which goes beyond the schema's brief examples. This effectively serves as a dynamic enum for the guideline_name parameter.

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 retrieves FSA guidelines, supervisory guidelines, and Q&A, using a specific verb (取得する) and resource. It also provides a comprehensive mapping of abbreviations to formal names, which distinguishes it from sibling tools like get_law and search_law that target legal texts.

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 lists all supported guideline types and notes that section search works for both HTML and PDF versions, giving clear context on when to use the tool. However, it does not explicitly mention exclusions or alternatives (e.g., when to use get_law instead), though the scope is obvious from the resource 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?

注釈が一切ないため説明文が行動特性の説明を担う。e-Gov API v2の使用と対応法令の範囲は開示されているが、認証要件、レート制限、条文未存在時のエラーハンドリングなどは触れられていない。読み取り操作であることは「取得」から推測できるが、追加の行動情報は限定的。

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?

最初の一文で目的を明確にし、その後の対応法令リストは箇条書きで簡潔に整理されている。無駄な記述は少なく、必要な情報に絞られている。リストは長いが、実際に法令名を扱う上で必須の情報である。

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?

出力スキーマが存在せず、注釈もないため、説明文が返却値やエラー時動作を補足する役割を期待されるが、formatパラメータが出力形式（markdown/toc）を説明しており、ある程度補われている。しかし、search_lawやget_guidelineとの関連性や、特定条文の取得に特化しているという文脈が明示されておらず、兄弟ツールとの関係性の説明が不足している。

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%で、パラメータの構文や例が記載されている。説明文は特にlaw_nameについて、略称（金商法、業府令等）から正式名称への対応マップを提供し、さらにlaw_id形式の例（323AC0000000025）を示すことで、スキーマの記述を大きく補強している。

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?

冒頭で「日本の金融法令から特定の条文を取得する」と明示されており、動詞とリソースが具体的で、e-Gov法令APIの利用も明記されている。兄弟ツールであるsearch_law（検索）、list_laws（一覧取得）、get_guideline（ガイドライン取得）と明確に区別される。

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?

対応法令の略称とlaw_id指定方法が示され、利用時に参考になる。しかし、いつこのツールを使うべきか（例: 条文番号が分かっている場合）や、search_lawやlist_lawsを使うべき状況との使い分けは明示されておらず、暗黙的な使用法に留まる。

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 are provided, so the description carries the full burden of behavioral disclosure. It adds minimal context beyond the schema by noting '対応している' (supported) and that filtering by type is possible, but it does not describe the output structure, pagination, sorting, or whether the list is exhaustive. For a read-only listing tool, the safety profile is obvious, but other behavioral traits remain undisclosed.

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 two short sentences, front-loaded with the core purpose and a brief mention of filtering. Every word contributes; there is no repetition or filler, making it appropriately concise and easy to parse.

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 simplicity and full schema coverage, the description is adequate but not complete. It does not mention the output format or fields of the list, and the optional show_aliases behavior is only in the schema. However, for a basic listing tool, this level of detail may be sufficient, so it earns an average 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 description coverage is 100%, so the baseline is 3. The description repeats the type filtering capability already in the schema but adds no new semantic detail. It does not elaborate on the show_aliases parameter or explain values beyond the enum descriptions, so the description adds minimal value over the 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 clearly states the tool displays a list of supported FSA guidelines and supervisory notices, using specific verb '表示する' (display) and resource '一覧' (list). It also mentions filtering by type, which distinguishes it from sibling tools like get_law or search_law that likely retrieve specific documents or search full text.

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 implies when to use the tool (when you need a list of guidelines), but it does not explicitly distinguish it from list_laws or other alternatives. There is no mention of when not to use it or when to prefer a sibling tool, so the usage context is clear but lacks exclusions or alternative recommendations.

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 are present, so the description carries the burden. It discloses the core behavior (listing laws), filtering capability, and alias display. It does not explicitly state read-only status, but as a list operation that is implied. The description is transparent enough for this simple 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?

The description is two concise sentences in Japanese, front-loading the main purpose and then mentioning optional filtering and alias display. Every sentence earns its place with 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 simple list tool with no required parameters and well-documented schema, the description is sufficient. It doesn't describe the output format, but since it's a list and no output schema exists, this is acceptable. A minor gap is not noting the default all-domain behavior, though that is covered in the schema.

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?

The schema has 100% parameter description coverage, with detailed explanations for 'domain' (including enum values) and 'show_aliases'. The description only restates these capabilities without adding new semantic details, so baseline 3 is appropriate.

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 lists financial laws supported by the server, with domain filtering and optional alias display. This distinguishes it from siblings like 'get_law', 'search_law', and 'list_guidelines', which target specific laws, search operations, or guidelines respectively.

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: use this to view the available laws, filter by domain, or show alias mappings. It does not explicitly name alternatives or exclusions, but the purpose is unambiguous given the sibling tools, so no additional guidance is needed.

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, the description carries the full burden. It discloses the use of e-Gov API v2, indicating external dependency, and states the cross-search scope. It does not mention read-only nature, rate limits, or result behavior, but these are somewhat implied by the search action.

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?

Three concise sentences, front-loaded with the primary action. No redundant information.

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 search tool with 3 parameters and no output schema, the description covers purpose, usage scenario, scope, and API source. It lacks details on return format, but that is not critical given the simplicity. It is reasonably complete.

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 the schema documents all parameters: keyword, limit, law_type. The description adds context that the keyword is used when the law name is unknown, but does not add further parameter-level detail beyond the 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 '法令をキーワードで検索する' (search laws by keyword) with a specific verb and resource. It also clarifies the use case (when law name is unknown) and distinguishes it from siblings like get_law by indicating it is for unknown names, and mentions cross-searching all laws.

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 explicitly says '法令名が分からない場合に使用' (use when law name is unknown), providing a clear condition for use. It also notes it covers all laws, not just financial, which helps select it over potentially narrower tools. However, it does not explicitly mention when not to use or name alternative tools.

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