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

No annotations exist, so description carries full burden. It accurately describes the tool as an educational/knowledge tool with no side effects. It does not mention read-only status explicitly, but the explanatory nature makes it non-destructive.

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?

Single sentence packs all necessary information (what, aspects, audience) without redundancy. Slightly dense but efficient; no wasted words.

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 (single param, no output schema), the description fully covers its purpose, input, and expected output (explanations). No gaps remain.

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 with a single parameter 'name' and its description. The tool description adds significant value by listing concrete examples (法律, 政令), explaining alias resolution (施行令 → 政令), and confirming the parameter's purpose.

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 verb 'explain' and resource 'law type' (法令種別). It lists specific types (憲法・法律・政令 etc.) and aspects covered (制定主体, 階層上の位置, etc.), clearly distinguishing from siblings that retrieve actual law 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?

Target audience (non-legal experts) is specified, and the purpose (confirming differences) is clear. While no explicit when-not-to-use or alternatives are stated, the sibling tools (search_law, get_law, etc.) imply this is for conceptual explanations, not text retrieval.

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, and the description does not disclose behavioral traits like read-only nature, authentication needs, or any side effects. It does not mention the e-Gov v2 dependency from the parameter description.

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 short and to the point, with no unnecessary words. It is concise but could be better structured with clear separation of key features.

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 and multiple parameters, the description lacks completeness. It does not explain return formats, date specification, or how the 'toc' format works, leaving critical gaps for effective use.

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 adds minimal value beyond what the schema already provides, only briefly mentioning abbreviation support and level specification.

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 articles from Japanese laws and supports abbreviations and level specification. However, it does not distinguish itself from sibling tools like get_toc or search_law.

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 guidance is provided on when to use this tool compared to alternatives such as search_law or get_toc. The description lacks explicit usage context.

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?

アノテーションがないため、動作特性の説明は記述に委ねられている。外部API使用と返却フィールドの列挙はあるが、読み取り専用であることやレート制限、副作用については触れられていない。最低限の情報は提供しているが、完全ではない。

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?

2文で目的と返却内容を効率的に伝えており、冗長な表現がない。フロントローディングも良好。

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?

パラメータ数2、必須1、出力スキーマなしという状況で、返却フィールドや外部API使用を明記しており、ツールを利用するのに十分な文脈を提供している。ページネーションやエラーハンドリングの欠如はあるが、スコープ内では良くできている。

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が適切。

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 v2 APIを使用すること、返却データの内容（公布日・施行日等）を列挙している。sibling tools（get_law, get_toc）との違いが明確で、特定の動詞+リソースを備えている。

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?

改正履歴を取得するという使用場面は明示されているが、代替ツール(search_law等)との使い分けや、使用すべきでない状況は明記されていない。代替案への明示的な言及がないため、最高点ではない。

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 burden. It explains that depth truncates hierarchy and that the tool is for token saving, but does not disclose error handling, authentication needs, or rate limits. Acceptable for a simple retrieval tool but incomplete.

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 sentences, each with clear purpose: first defines core function, second adds depth parameter context and use case. No wasted words, highly efficient.

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, so description should clarify return format. It mentions 'structure of parts, chapters, sections, articles' but not whether output is nested or flat. Missing details on behavior for invalid law names or depth values. Adequate for a simple tool, but could be more 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 already provides 100% coverage with good descriptions. Tool description adds extra context by explaining depth's purpose for overview and token saving, enhancing understanding beyond 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?

Description clearly states it retrieves only the table of contents structure, explicitly distinguishing from full law retrieval with 'のみ' (only) and token-saving purpose, and mentions depth for overview of large laws, setting it apart from siblings like get_law.

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?

Description implies usage for token-saving and large law overview via depth, but does not explicitly state when to avoid this tool or list alternative tools for full content or search, leaving guidance implicit.

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 explains the core behavior (resolving abbreviation to law name and ID) but lacks details on error handling, multiple results, or the exact response format. It does not contradict any facts.

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 sentences, front-loaded with purpose and usage context. Every sentence is meaningful, with no wasted words.

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 (1 required param, no output schema), the description sufficiently covers functionality. It could mention the output format, but the lack is not critical for this diagnostic tool.

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 parameter description provides examples. The tool description adds no additional semantic information beyond what the schema already provides, resulting in a baseline score of 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 clearly states the tool resolves official law names and law_ids from abbreviations, and identifies it as a diagnostic tool. This distinguishes it from siblings like search_law or get_law, which serve different purposes.

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 does not explicitly guide when to use this tool vs alternatives. Calling it a 'diagnostic tool' implies it's for checking abbreviation coverage, but no direct 'when-not-to-use' or alternative references are provided.

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 the cache-dependent behavior (SQLite FTS5 vs API fallback), adding valuable context beyond the 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?

Two concise sentences, front-loading the main purpose and adding a crucial behavioral note. No unnecessary words.

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?

Moderate complexity with 4 parameters; description lacks output format or return value details, but covers core function and a key environmental behavior.

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%; description does not add new meaning to parameters beyond what schema already provides (keyword, limit, domain, law_type).

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 performs full-text search across legal texts by keyword, which distinguishes it from sibling tools like search_law that likely search by law identifier.

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?

Implied usage for broad keyword search, but no explicit guidance on when to use versus competitors like search_law, or mention of prerequisites or limitations.

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 adds useful context such as using the e-Gov API v2 and auto-completion of abbreviations, but it does not disclose safety traits (e.g., read-only nature, auth requirements, rate limits, or side effects). The description partially compensates but lacks full behavioral disclosure.

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 concise: three short sentences that are front-loaded with the main purpose, then API source, then auto-completion feature. Every sentence adds unique value 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?

Given the four parameters (two with enums) and no output schema, the description is fairly complete. It covers search scope, API source, and auto-completion. However, it does not describe the return format (e.g., list of law objects with titles, dates), which would be helpful for an 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?

All four parameters are described in the schema (100% coverage), so the baseline is 3. The description adds value beyond the schema by mentioning auto-completion of abbreviations and the use of the e-Gov API v2, helping agents understand the underlying mechanism and data enrichment.

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: '日本の法令をキーワード・略称・分野で検索する。' (search Japanese laws by keyword, abbreviation, or field). It also specifies the use of the e-Gov law API v2 and auto-completion of abbreviations, making it distinct from siblings like get_law, search_fulltext, and resolve_abbreviation.

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 usage for keyword, abbreviation, or field searches, but it does not explicitly state when to use this tool versus alternatives like search_fulltext or resolve_abbreviation. No usage exclusions or contextual cues are provided, leaving room for ambiguity.

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