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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: results are ordered, each entry carries an elm handle usable by read_law_text, paging is via offset, and the include_amendment_supplements flag must match on the follow-up read. It omits mention of result volume or the limit cap, which keeps it from a 5.

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-loaded with the return contents, then the workflow rule, then the coupling constraint. Sentences are dense but each carries distinct information. The trailing 'Paged with offset' is clipped and slightly out of place after the parameter-coupling 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?

An output schema exists, so return structure needn't be spelled out, and the description covers the essential agent-facing concerns: what the outline contains, why to call it first, how elm values link to read_law_text, the flag-consistency requirement, and offset paging. Minor gaps around asof and limit behavior are acceptable given 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?

Schema coverage is 60%, so the description must add meaning, and it does for the two most consequential parameters: it explains that include_amendment_supplements changes which supplementary provisions each elm names (beyond the schema's terse 'List the amending laws' supplementary provisions too') and that paging is offset-based. asof and limit remain undocumented in the description, so it does not fully compensate for the coverage gap.

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 ('Get one law's table of contents') and enumerates exactly what is returned: parts, chapters, sections, articles with captions, supplementary provisions, appendices, in order, each with an elm value. This clearly distinguishes it from sibling read_law_text (which reads actual text) and the 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?

Gives an explicit when-to-use rule ('Read this before reading a long law'), an explicit alternative-avoidance rule ('pass the elm it gives rather than building one yourself'), and a coordination constraint with a sibling ('Call read_law_text with the same include_amendment_supplements'). Nothing is left to inference.

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?

readOnlyHint and openWorldHint already establish this as a safe read against external data, so the description only needs to add context. It does disclose the status vocabulary (in force / not yet in force / repealed) and that results are per-revision, but says nothing about ordering, pagination (despite limit/offset), or what happens when the law id is unknown or the law has no amendments.

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, no filler. The resource and row contents come first, the intended use second, which matches how an agent would scan for a routing decision.

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 an output schema present, the description is not obliged to explain return shapes, and read-only behavior is covered by annotations; what remains needed is the calling decision, which it provides. Minor gaps are ordering and result-set size limits for a potentially long revision list.

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?

Coverage is 50%: law_id_or_num has an explicit "exact match" note and current_revision_status says "Revision states, any of". The description never mentions the status filter or how to use limit/offset, though its phrasing about revisions being "in force now, not yet in force or repealed" loosely hints at what the status filter accepts. Adequate but not compensatory.

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?

"List one law's amendment history" gives a specific verb (list), resource (revisions of a single law) and scope (one law only), and then enumerates exactly what each row contains (enforcement date, amending law, revision id, status). That is enough to separate it from search_laws, read_law_text and get_law_outline, which operate on text rather than revision chains.

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?

"Use it to choose the asof date or revision id to read" states a concrete decision the tool feeds into, and "or to see when a change takes effect" covers the second use case. It stops short of naming the sibling tools it precedes (read_law_text) or excluding cases where another tool is better, so no explicit 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context about what the guideline covers and when to read it, but it does not describe the return format or invocation behavior beyond the output schema already provided.

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 a single sentence with a clear list of covered topics followed by the call to action 'Read it before your first search.' It is front-loaded and appropriately sized, though the dense topic list could be slightly easier to scan.

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 no-parameter documentation-loading tool with an output schema and clear read-only annotations, the description supplies enough to decide when and why to call it. It names the covered domains and explicitly directs the agent to read it before its first search.

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 tool has zero parameters, so there are no parameter meanings for the description to clarify. The schema also reports 100% description coverage, making the baseline for a no-parameter tool 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 identifies this as a usage guideline for the Japanese law tools and enumerates the topics it covers, such as finding laws, reading articles by elm, searching law text, pinning a point in time, e-Gov coverage, and conditions of use. It is distinguishable from the sibling search/read tools as a meta-documentation resource, though it does not use an explicit verb like 'load' or 'returns'.

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 gives explicit timing guidance: 'Read it before your first search.' This tells the agent when to use it relative to the sibling search and read tools. It lacks explicit when-not guidance or named alternatives, but the first-search condition is clear enough for correct selection.

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?

Adds real behavior beyond the readOnlyHint/openWorldHint annotations: output is paginated into max_chars chunks resumed via next_offset, the 目次 is deliberately omitted, and amendment supplementary provisions are excluded by default. It does not cover failure behavior (invalid elm, unknown law id) or how asof interacts with missing revisions.

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 dense sentences, front-loaded with the capability and followed by exclusions, with no filler. The parenthetical list of elm examples is long but earns its place; the Japanese term 目次 is the only mild readability cost.

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 annotations and an output schema supplied, the description covers the parts an agent most needs: element addressing, pagination continuation, and default exclusions. Remaining gaps are minor (error cases, asof edge behavior) and partly absorbed by schema descriptions.

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 already 83%, so the baseline is 3; the description goes further by giving concrete elm path shapes (MainProvision-Article_17, MainProvision-Chapter_4-Section_2, SupplProvision[1]-Article_1, AppdxTable[1]) and by explaining how max_chars and offset compose into a continuation loop. asof is left entirely to 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?

States a specific verb and resource ('Read a law's text as plain text') and clarifies the two modes: the whole law or a single element. It explicitly separates itself from get_law_outline for the 目次, but says nothing to distinguish it from search_law_text, so sibling differentiation is only partial.

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 routing guidance: use get_law_outline to obtain the 目次, and set include_amendment_supplements=true when amending-law supplementary provisions are wanted. It does not state when to prefer this over search_law_text or load_guideline, so the when-not side is incomplete.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds genuine behavioral context by explaining pagination ('one page', 'total_count and next_offset tell whether more pages exist'), but the enumerated return fields largely restate what the output schema already declares.

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, front-loaded with the core capability, followed by return/pagination and chaining guidance in that order of importance. No filler or redundant phrasing.

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 15-parameter read-only search tool with an output schema and annotations, the description covers purpose, pagination continuation, and how to hand off law_id. The only real gap is guidance on narrowing an overly broad query or combining filters, which is left implicit.

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 87%, so most parameters (asof, law_id, law_num, order, repeal_status, dates) are already documented in the schema. The description only maps facets at a high level and adds no format, matching, or combination semantics beyond that baseline.

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 a specific verb+resource ('Find Japanese laws') and enumerates the facets searchable (title, law number, type, subject category, promulgation date), which is more precise than the bare tool name. It does not explicitly distinguish itself from the sibling search_law_text (full-text search), leaving that inference to the agent.

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 final sentence ('Use the law_id with the other tools') gives a clear chaining instruction for downstream tools such as get_law_outline or read_law_text. It stops short of stating when to prefer this over search_law_text or list_law_revisions, so no explicit exclusions 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?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely non-obvious behavior: scan_limit counts hit positions scanned rather than laws, wildcards cannot be combined with operators, and the hits_per_law/scan_limit tradeoff. It stops short of describing result truncation signaling or pagination behavior via offset.

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 with no filler; the core action and hit markup are front-loaded, then query syntax, then the scan_limit caveat that would otherwise cause the most misuse. Nothing is redundant with the schema prose.

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?

An output schema exists, so return format needn't be spelled out, and the description still sketches it helpfully. For a 10-parameter full-text search on open-world data, the main pitfalls (query grammar, scan_limit counting, paging via offset) are mostly addressed, though offset/pagination behavior is left unexplained.

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 80%, so most parameters are self-documenting, but the description adds real meaning where the schema is silent: the full expression grammar for 'keyword' and the precise semantics of 'scan_limit' with its relationship to 'hits_per_law'. It says nothing extra about asof, category, law_type, offset, or promulgation date filters, relying entirely on the schema there.

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 gives a specific verb and resource ('search the text of every Japanese law') plus the return shape (laws containing the keyword with matching sentences, hits marked with 【】). It implicitly distinguishes itself from read_law_text and search_laws by scoping to full-text keyword search, but it never names those siblings, 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?

It covers how to construct the query (AND/OR/not/grouping/wildcards) and gives concrete tuning advice for scan_limit versus hits_per_law isolated from other concerns. However, there is no explicit guidance on when to reach for this tool instead of search_laws (metadata search) or read_law_text, so the agent must infer the division of labor.

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