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

Annotations already declare readOnly and openWorld, so the bar is lower; the description still adds real behavior: exact title matches are ordered first, BC acts carry current/repealed status, and federal results omit repeal status. These are non-obvious traits an agent could not infer from the schema or annotations.

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 purpose then return shape, and every clause carries information (field list, citation formats, ordering, repeal caveat). Some sentences are dense and run long, but nothing is wasted.

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 fully carries the return-value burden: it lists act_id, title, citation, source_url and currency status, plus ordering and the federal repeal caveat. An agent has everything needed to call and interpret the result.

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 already documents both parameters including the enum and the 'abbreviations not recognised' caveat. The description only restates 'by title', adding no syntax or format detail beyond the schema, so the 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 specific verb and resource ('Find acts and regulations by title') and enumerates the returned fields, so the agent knows exactly what a call yields. It does not explicitly distinguish itself from the sibling search_law, which is the one remaining ambiguity.

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 downstream routing: 'pass it to get_toc and get_section', and warns that federal titles don't mark repealed acts so those tools should be consulted. It never states when to prefer this over search_law or map_term, so no explicit exclusions or alternatives.

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 indicate read-only and open-world behavior. The description adds that the result includes a full citation, source URL, current_to date, retrieved_at, and answer_rules, which is useful behavioral context beyond annotations. It does not address rate limits or error cases.

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 compact, front-loads what is returned, and avoids repetition. Some clauses could be tightened, but every sentence contributes.

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, single-section retrieval tool with no output schema, the description covers return structure, citation fields, and usage rules. Together with the fully documented input schema and annotations, it is complete enough for correct 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?

Schema coverage is 100%, so all three parameters are already documented in the input schema. The description does not add parameter-specific meaning beyond what is in the schema. 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?

The description clearly identifies a retrieval tool for a single section of legislation, stating what it returns (verbatim text with subsections and citation fields). However, it does not differentiate itself from siblings such as get_toc or search_law beyond the obvious section-level scope.

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 says to quote the text rather than paraphrase and to follow answer_rules, which provides some usage direction. But it does not say when to use this tool versus alternatives, nor does it mention prerequisites like needing an act_id from find_act.

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. The description adds genuine value beyond that: the exact shape of the payload and the instruction to obey the embedded answer_rules when composing an answer. It stops short of describing pagination or size limits for large acts.

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 purpose before routing and the answer_rules note. Each sentence carries distinct information, though the middle clause packing the payload contents is slightly dense.

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, so the description must carry the return-value burden and it does: it lists the structural contents, the citation/source_url/current_to metadata, and the answer_rules field. An agent has everything needed to call it and interpret the result.

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%, with act_id format examples and jurisdiction enum values fully documented in the schema. The description adds no syntax or format detail beyond that, so the 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?

Names a specific resource (table of contents) and enumerates exactly what it returns: Parts, Divisions, Schedules, every section number and heading, plus citation, source_url and current_to. It is unmistakably distinct from sibling get_section, which returns actual text rather than the outline.

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 states the workflow condition: 'Use it to pick the right section number before calling get_section.' It names the alternative sibling and the reason to choose this one first, leaving nothing 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?

Annotations already establish readOnlyHint=true and openWorldHint=false, and the description is consistent with a closed curated glossary. It adds real behavioral context beyond the annotations: the [] sentinel for a miss and the instruction never to present a personal translation as the statutory term. It stops short of describing the hit shape in detail, but the act_id/sections mention covers the essentials.

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 mapping action before the routing advice and the failure mode. Every sentence carries weight, though the final clause is dense enough that it reads as slightly packed rather than crisp.

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 still tells the agent what a hit yields (act_id and sections) and what an empty array means, plus the correct fallback behavior. Nothing an agent needs to invoke or act on this tool's result is missing.

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 single 'term' parameter is fully documented with examples (法定假日, 加班, 餐休, 'statutory holiday'). The description adds only the framing that input may be Chinese or everyday English; the substantive semantics live in the schema, so baseline 3 is correct.

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 precise verb and resource ('Map a ... employment-law concept to the statutory English') and names both the jurisdictional scope (BC and federal) and the payoff (act_id and sections). It is unmistakably distinct from siblings like find_act, get_toc, get_section, and 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?

It explicitly says when to call it ('before search_law when the question is in Chinese or uses everyday words') and names the alternative it precedes, with a caveat to search each jurisdiction with its own terms. The empty-result path is also prescribed: try a more basic term or search with your own wording and disclose that you did.

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?

The annotations already indicate it is a read-only, open-world search, but the description adds valuable behavioral context: results are best-first, carry an answer_rules field that governs how the text should be used, and the query must match statutory English. It does not describe pagination or rate limits, but the annotation coverage lowers the bar and the added context is substantial.

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, well-structured paragraph that front-loads purpose, then query constraints, then usage workflow. It is slightly long but every sentence contributes essential guidance, 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?

For a search tool with no output schema, the description explains the return shape (citation fields, snippet, answer_rules) and the required query style. It omits any mention of result limits or ordering beyond 'best first,' but overall it provides enough for an agent to invoke and interpret results 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%, with the limit and jurisdiction parameters fully described and the query parameter explaining matching is literal with no plurals or stemming. The description reinforces the query requirement for statutory English but adds no new syntax or format details beyond the schema, so the 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 uses a specific verb (Search) and resource (current legislation for English statutory wording) and states what is returned: matching sections with citation fields and a snippet. It clearly distinguishes itself from siblings like map_term and get_section.

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 provides explicit when-to-use and when-to-use-alternatives guidance: call map_term first if the query is Chinese or everyday words, then read full text with get_section before answering. This tells the agent exactly how this tool fits in the workflow and when to choose other tools.

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