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

No annotations are provided, so the description carries the full disclosure burden. It usefully explains the diff output notation and the date lower bound, but does not state permissions, error behavior, or what happens when no lines change.

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 compact sentences, front-loaded with the comparison purpose, then the output notation and date constraint. Every clause adds useful information without repetition.

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

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

For a read-only diff tool with full schema coverage but no output schema, the description adequately explains the return shape and the date lower bound. It leaves minor behavioral details unstated, such as error handling and when to prefer siblings, but is otherwise 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 baseline is 3. The description adds a meaningful constraint beyond the schema patterns: both 'from' and 'to' time points must be on or after 2017-04-01, and it frames 'from'/'to' as old/new comparison points.

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 a specific verb and resource: compare the same article at two points in time and show changed lines with '-' for old and '+' for new. This distinguishes it from siblings like get_article and law_history without requiring the schema.

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 clearly sets the usage context: same article, two time points, both on or after 2017-04-01. It does not explicitly name alternatives or exclusions, but the comparison purpose is unambiguous.

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 burden. It does disclose the output shape (results grouped per law) and the two citation kinds covered (引用 and 委任), which is useful. It says nothing about the max_laws cap, truncation, ordering, or whether missing references are reported, leaving behavioral gaps for a lookup tool with no annotation coverage.

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 compact sentences: the first is the capability statement with scope front-loaded, the second is the usage cue. No filler, no restatement of the name or title.

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

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

For a 3-parameter read tool with no output schema and no annotations, the description covers what is returned and why you would call it, which is the essential core. It omits the behavior of max_laws and any truncation/limit semantics, so an agent can invoke it but cannot predict result volume.

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 67%: law and article are documented in the schema, and the description's '法令ごとにまとめて' reinforces the law grouping. max_laws is undocumented in both schema and description, and the description never mentions any limit on returned laws, so it does not compensate for the gap. 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?

Specific verb (返します) plus the resource and scope: other articles cited in the body of the given article and delegated cabinet/ministerial ordinances, grouped by law. The outgoing direction of the citation relationship is unambiguous, which implicitly separates it from the mirror sibling find_citing_provisions, but that sibling is never named, so differentiation is left to inference.

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 second sentence gives a concrete use case: follow reference destinations while reading a provision. That is clear context for selection, but there is no explicit 'when not to use' or naming of alternatives such as find_citing_provisions or get_article.

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, so the description carries the full burden. It usefully discloses the depth semantics (depth=2 counts indirect influence) and the per-law grouping of results, which is real behavioral value. However it says nothing about truncation via max_laws, ordering, or error behavior for unresolvable law names — significant gaps for an unannotated 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?

Three sentences, front-loaded with the core action, then use cases, then the depth caveat. No filler text. Dense but appropriate for a Japanese technical description of a multi-parameter lookup.

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 no annotations, the description must carry everything. It covers purpose, use cases, and depth semantics, and notes that results are grouped by law, but omits return shape, the effect of max_laws on completeness, and behavior for ambiguous law identifiers. Adequate but with clear gaps.

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 60%: law, article, and include_same_law are documented in the schema, but depth and max_laws are not. The description compensates well for depth by explaining indirect influence, but max_laws (default 15, max 50) is explained nowhere, leaving a non-obvious result-limiting parameter undocumented. Slightly above baseline 3, not a 4.

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?

States a specific verb and resource in the reverse direction ('指定した条...を引用・委任元として参照している他の条文を...返します') and even specifies output grouping ('法令ごとにまとめて返します'). The direction is clear enough that an agent can tell it apart from find_cited_provisions, but the sibling is never named explicitly, so it falls short of the 5 criterion.

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?

Gives two concrete when-to-use scenarios ('この条が改正されたら、どの法令のどの条に影響しうるか' / 'この規定を準用・引用している手続はどれか'), which is strong contextual guidance. It does not name an alternative tool or state when-not to use it, so it is not a 5.

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 exist, so the description carries the full behavioral burden. It does disclose the response contents (ID, official name, type, current status), which is valuable with no output schema, and 一部から探し implies partial matching returning multiple hits. However it says nothing about result limits (the schema caps limit at 30), ordering, or the read-only nature of the operation.

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 compact sentences, front-loaded with the search action and returns before the secondary 'use it to get an ID for other tools' note. Every clause earns its place; no filler.

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, the description usefully enumerates returned fields and the ID-chaining purpose, which covers what an agent needs to route results downstream. It stops short of describing paging/limit behavior or whether multiple matches are returned by default.

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 only 50%: title is documented in the schema, limit is not. The description reinforces title's partial-match semantics (法令名・略称の一部) but largely repeats the schema wording and says nothing at all about limit. It therefore does not fully compensate for the uncovered 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?

States a specific verb and resource: search laws from part of a name or abbreviation, and it enumerates the returned fields (法令ID・正式名称・種別・現行かどうか). It does not explicitly contrast itself with siblings like search_law_text or get_article, but the scope is unambiguous enough that an agent can tell what it does.

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 names the downstream use case: look up a law ID to pass to other tools (他のツールに渡す法令IDを調べるときにも使います). This tells the agent when to reach for it as an entry point. There are no exclusions (e.g., when to prefer search_law_text instead), so it stops short of a 5.

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 supplied, so the description carries the burden. It implies a read ('返します'), discloses the 2017-04-01 lower bound on asof, and adds a genuine behavioral trait: for current provisions it warns about scheduled amendments. It stops short of describing return format, article-scope boundaries (e.g., whether 附則/別表 are excluded), or any retrieval 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?

Four short sentences with the return behavior front-loaded, followed by the asof nuance and the use case. Efficient and well ordered, with no filler.

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?

There is no output schema and no annotations, so the description must stand alone; it covers purpose, temporal semantics, the use case, and the amendment-notification behavior. It is largely complete for a 3-parameter read tool, though it omits return-format details and the exact scope of what '本則の条' excludes.

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 the schema already documents law, asof, and article formats and examples. The description reinforces the meaning of asof ('the version in force on that date') but adds little syntax or format detail beyond what the schema states, so the baseline of 3 applies.

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?

States a specific verb and resource ('法令の条文（本則の条）を返します') and scopes it to main-body articles, which helps disambiguate. It is clear what the tool returns, though it does not explicitly name a sibling it replaces (e.g., law_history or compare_article).

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?

Gives a concrete use case: confirming the law that applied at the time of a disposition or application (行為時法). This clearly frames when asof matters, but provides no exclusions or pointers to alternative tools for related tasks like history comparison.

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 does disclose meaningful behavior beyond the schema: newest-first ordering, the 2017-04-01 coverage cutoff, and the categories returned (施行日/改正法令/現行・過去・未施行). It omits pagination/truncation behavior tied to the limit parameter, but the read-only nature is implied by 返します.

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 compact, front-loaded sentences with no padding: purpose first, then ordering/scope and returned categories. Every clause earns its place.

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 read tool with no output schema, the description covers purpose, ordering, time window, and returned field categories, which is enough to invoke it correctly. The remaining gap is the completely undocumented limit parameter, which leaves an agent unable to reason about result-set size.

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 50%: the law parameter is documented in the schema (法令名・略称・法令ID) but limit has no description anywhere. The description text mentions neither parameter, so it adds no semantics beyond the schema and fails to compensate for the undocumented limit/default/paging behavior.

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?

States a specific verb+resource: it returns the amendment history of a law, in newest-first order, with a clear temporal scope (2017-04-01 onward). This is distinguishable from siblings like find_law or get_article, though it never names an alternative explicitly.

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?

Usage is only implied: an agent can infer you call this to see a law's revision history, but the description offers no when-to-use statement, no prerequisites, and no routing against siblings such as find_law or compare_article.

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 behavioral burden. It discloses the output format (excerpts per speech plus links) and the cross-cutting constraint that at least one condition must be specified, which are meaningful behavioral facts. It does not explicitly state read-only nature or discuss pagination/rate limits, leaving minor gaps, but 'search' strongly implies a non-mutating read operation.

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?

Four well-structured sentences: purpose, when to use, return shape, and invocation constraint. No sentence is wasted, and the most important scoping and constraint details are front-loaded appropriately.

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 8-parameter search tool with no output schema, the description explains the return shape and the minimum-filter requirement, which are critical for correct use. The schema handles parameter details including pagination via start, though the description does not mention pagination explicitly; overall it is complete enough to call 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 description coverage is 100%, so the baseline is 3. The description adds a valuable cross-parameter constraint not enforced by the schema: at least one filter condition must be supplied. This helps an agent avoid a zero-parameter invocation that the schema would technically allow.

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?

States a specific verb and resource: searching speeches in Diet proceedings (both houses, plenary and committee). This is clearly distinct from the law-text-oriented sibling tools such as find_law or get_article. An agent can tell what this tool does without opening the schema.

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?

Gives clear context for use: checking legislative intent, government answers, and constitutional/provision interpretation in the Diet. It does not name alternatives or exclusions, but the domain is narrow enough that implicit contrast with law-text search is clear. The requirement to specify at least one filter is a useful usage constraint.

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 burden and does add real behavioral context: the e-Gov API source, space-delimited AND semantics, that results include both the law and the matching sentence, and that top-ranked laws additionally report the article number. It is silent on rate limits, result ordering, or what happens when nothing matches, which are secondary gaps for a read-only search 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?

Three tight sentences, front-loaded with what the tool does, then mechanics, then the usage cue. The only mild redundancy is restating the space-delimited AND and article-locating behavior that the schema already covers.

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?

There is no output schema, and the description compensates by stating what is returned (matching laws and sentences, plus article numbers for the top laws). Combined with 100% schema coverage of the five parameters, an agent has everything needed to call this 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%, so all five parameters including asof, limit, locate and law_type are already documented in the schema. The description's mentions of AND tokenization and article-number lookup duplicate the keyword and locate field descriptions rather than adding new meaning, making the baseline 3 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?

States a specific verb and resource: full-text keyword search over law body text ('法令の本文をキーワードで検索'), returning matching laws and sentences. This implicitly separates it from siblings like find_law (law lookup) and get_article (single article retrieval), but it never names an alternative explicitly, so the differentiation is left partly to inference.

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?

Gives a clear positive usage condition: use it to search cross-cutting provisions that share a phrasing such as '理由を示さなければならない'. It does not name when NOT to use it or point to a specific sibling for other cases, so it stops short of full routing 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, the description carries the full load and does well: it discloses what the response contains (error classes plus matched article excerpts for cross-checking) and draws a clear boundary that claim correctness is out of scope. It stops short of stating whether verification requires network/auth, rate limits, or how large result sets behave.

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?

Front-loads purpose and examples, then moves to output contents, then to when to call it and the pre-answer workflow rule, ending with the scope limit. Every sentence adds a distinct fact with no repetition.

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 and no annotations, so the description must cover behavior, which it largely does via the enumerated error classes and excerpt attachment. The only mild gap is lack of detail on response shape or handling of very large citation sets.

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

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

Schema coverage is 100%, so asof, text, detail, and default_law are already fully documented in the schema; the description adds no parameter-level detail beyond what structured data provides. Baseline 3 applies.

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?

States a concrete verb pair (extract citations, verify existence) with concrete examples of citation forms (行政手続法第八条第一項, 所得税法（昭和四十年法律第三十三号）第五十七条の二). It also enumerates the specific failure classes it detects (wrong law name, nonexistent article, law-number/name mismatch, repealed law), which clearly differentiates it from siblings like find_cited_provisions or search_law_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?

Gives explicit usage contexts ('AI が書いた回答や文書の引用を確認するときに使います') and a concrete workflow instruction (pass all cited provisions to this tool before returning an answer). It also states an explicit exclusion ('主張の内容が正しいかは判断しません'), defining what the tool will not do, though it never names a sibling as an alternative.

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