C4C: Mortgage Industry Regulations

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

Even with readOnlyHint and idempotentHint already present, the description discloses substantial non-obvious behavior: passages must be quoted verbatim and never paraphrased, tables return the whole table, currency fields may indicate multiple versions, dual-version sections expose version/other_version, and no-match has caveats. This far exceeds what annotations convey.

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 lengthy but every sentence carries operational weight: exact quoting, citation fields, heading path, versioning, tables, and no-match behavior. The most important usage directive is front-loaded, and the density is justified by the complete absence of an output schema.

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 must explain the return shape itself, and it does: verbatim, canonical_citation, heading_path, offset, currency, version, other_version, and table. It also covers edge cases like table matches and dual versions. An agent has enough information to invoke the tool and interpret its 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 description coverage is only 33%, so the description must compensate. It does richly for the key parameter, terms: '1-6 short words or phrases in the regulator's vocabulary' with abbreviations expanded, and clarifies obligation_id as referring to 'one obligation (section).' It does not mention max_passages at all, though the schema's min/max limits make its role partially inferable.

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 opens with a specific verb-plus-resource statement: 'Return ONLY the verbatim paragraphs of one obligation (section) that contain your terms.' It also distinguishes itself from get_obligation by positioning this as the fast route to specific requirements, so an agent can clearly tell this search tool apart from the full-section reading tool.

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 states when to use this tool ('fast way to get specific requirements out of a long section, instead of paging through it with get_obligation') and gives the negative case under which the tool is not conclusive: 'No match does not mean the rule is silent -- try other terms or read the section.' This is explicit 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?

While annotations already declare readOnly, idempotent, and non-destructive hints, the description goes far beyond them by disclosing paging behavior, truncation semantics, version handling, canonical citation fields, and the instruction not to assert a rule is absent until all pages are read. This adds rich behavioral context that annotations cannot convey. There is no contradiction with the 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?

The description is long but every sentence carries operational value, covering quoting rules, pagination mechanics, truncation warnings, version ambiguity, and citation output. The core purpose is front-loaded, and the detailed instructions are organized in a logical progression from answer behavior to pagination to version handling. Despite its density, there is 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 must carry the full burden of explaining return values and edge cases. It does so comprehensively: provenance, canonical citation, versions, same-text copies, figures, truncation, and pagination. For a tool of this complexity, nothing an agent needs to call it correctly or interpret its 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 description coverage is only 50%, but the description compensates thoroughly: it explains `limit` as requesting fewer characters, `offset` via next_offset paging instructions, `obligation_id` through the version/other_version discussion, and `compare_versions` as returning version_changes. It also explains derived response fields such as `paging`, `truncated`, `canonical_citation`, and `figures`, adding substantial meaning 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 opens with a specific verb and resource: 'Return one obligation's verbatim regulator text with full provenance.' It then gives explicit answer-format instructions (quote exactly, include section citation, never paraphrase) and differentiates itself from find_in_section by scope. This makes the tool's purpose unmistakable and distinct from its siblings.

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 explicitly tells the agent when find_in_section is the better alternative: 'For specific requirements in a long section, find_in_section is faster: it returns only the paragraphs containing your terms.' It also provides detailed paging and multi-version handling guidance so the agent knows exactly how to use this tool correctly across paginated results. This is explicit, actionable usage 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 cover safety (readOnly, idempotent, non-destructive). The description adds valuable behavioral details: pagination ('follow next_offset until null'), a currency check ('fingerprint and dates'), and a privacy rule ('never send their text to this server'). These go beyond annotations and clarify how the tool behaves.

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 dense but every sentence carries information: purpose, content specifics, pagination, related tools, currency check, privacy, and id-only rule. It's front-loaded with the core purpose. Slightly long but not bloated; it earns its length by covering multiple distinct behaviors.

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 tool with no output schema and moderate complexity (different playbook types, pagination, privacy), the description covers all essential aspects: what the kit is, how to use related tools, pagination behavior, currency check, and privacy constraints. It doesn't enumerate response fields, but that's not required given the 'rule kit' concept and the mention of fingerprint/dates.

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% (both id and offset have descriptions). The description reinforces id's allowed values implicitly via 'Playbook tools take only ids' and clarifies offset's role with 'follow next_offset until null', which adds meaning beyond the schema's bare description. The added pagination semantics justify a score above the baseline 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 opens with a clear verb+resource ('Get a playbook's rule kit') and immediately specifies what the kit contains for different playbook types (FNMA AI lender letter vs FHA/VA/USDA QC). It also names sibling tools (get_reg, get_obligation) as alternatives, making it easy to distinguish this tool's 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?

It states that for FHA/VA/USDA QC, one should 'read with get_reg / get_obligation', which implies when this tool alone is insufficient. The rule 'Playbook tools take only ids' sets a constraint. However, it doesn't explicitly say when NOT to use this tool or provide a decision tree, so a small gap remains.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context beyond annotations: user P&Ps and loan files are never sent to this server, and playbook tools take only ids. No contradiction with 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?

The core purpose is front-loaded in the first sentence, and the examples are useful. The extra sentences about privacy and id-only semantics each add meaningful guidance, though the description is slightly denser than strictly necessary.

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 no output schema and rich annotations, the description covers the trigger, where to find valid names, and a critical privacy constraint, which is enough for a correct call. It does not describe the return value shape, but for a simple read-only reference-loading tool this is a minor gap.

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 practical semantics by saying valid `name` values are listed by start_playbook's `references`, and clarifying that both parameters are id-style values, not content. This goes beyond the schema's field descriptions.

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 ('Load') and resource ('one stage reference of a playbook'), and gives concrete example stages. It also differentiates from the sibling start_playbook by noting that start_playbook lists valid names, so the agent can tell which tool to use.

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 gives a clear trigger: use it 'when the workflow reaches that stage.' It also points the agent to start_playbook for valid reference names. It does not systematically contrast with all sibling tools like get_playbook_kit or list_playbooks, but the workflow-stage context is sufficient for 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?

Annotations already mark it read-only and idempotent, and the description adds meaningful behavioral detail: it returns a manifest rather than full text, surfaces currency warnings, and explains how dual-version sections are represented. This goes beyond the structured hints and helps the agent interpret results correctly.

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 dense but well-organized: the core behavior is front-loaded, followed by the key distinction from siblings, the intended use, and a special-case explanation. Every sentence adds information 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?

For a single-parameter, read-only tool with no output schema, the description is complete enough: it states what is returned, what is not returned, how to interpret currency and dual-version sections, and how to follow up for actual text. An agent has what it needs to call and use the tool 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?

With schema description coverage at 0%, the description carries the burden for parameter meaning. It mentions 'a register' as the object being listed, which gives some context for register_id, but it does not explicitly explain what register_id values look like or where they come from. The single parameter is fairly self-evident, so this is adequate but not richly documented.

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 opens with a specific verb and resource: 'List the obligations in a register' and enumerates the returned fields (sections, sizes, provenance, currency). It also explicitly distinguishes itself from siblings by stating it returns a manifest, NOT the regulator text, and directs quoting to get_obligation or find_in_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 gives concrete when-to-use guidance: 'Use this to decide which sections are worth reading.' It also names the alternatives for quoting regulator text, making the boundary between this tool and its siblings explicit.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds genuinely useful behavioral context beyond annotations: the privacy guarantee that 'the user's P&Ps and loan files stay in their own chat: never send their text to this server.' This is valuable operational transparency that the annotations do not convey.

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?

A single dense paragraph with no filler. The purpose is front-loaded, followed by playbook enumeration, return-value description, and privacy note. Every sentence contributes information; it is slightly long but each 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?

Given zero parameters and no output schema, the description carries the full burden of explaining return values, which it does thoroughly. It covers what playbooks exist, what the tool returns, the privacy constraint, and the id-based workflow—nothing an agent needs to call it correctly 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?

With zero parameters, there is nothing for the schema to document, so the baseline is 4. The description compensates by explaining the return payload (id, purpose, when-to-use, user requirements), which is meaningful context that helps the agent understand what the tool delivers.

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 ('Lists the guided compliance playbooks this server runs in your chat') and enumerates exactly which playbooks are included (Fannie Mae LL-2026-04 P&P review, FHA/VA/USDA loan-file QC). It distinguishes itself from siblings like get_playbook_kit and start_playbook by clarifying it returns summaries and ids rather than executing anything.

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 explains that the tool returns 'each playbook's id, what it does, when to use it and what the user must provide', which serves as discovery guidance for choosing among siblings. It also states 'Playbook tools take only ids', implying this tool is the entry point for obtaining those ids. However, it does not explicitly name alternatives or state when NOT to use this tool.

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 description goes well beyond the readOnly/idempotent annotations by disclosing exact edge-case behavior: not_found with parsed, refusal on ambiguity, no near-match suggestions, handbook sections resolving to their own register, related documents kept separate, and identical copies surfaced in also_at. This is rich, non-obvious behavioral detail that an agent needs to interpret results correctly.

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 longer than average, but nearly every sentence covers a distinct behavioral nuance needed for correct use. The core purpose and examples are front-loaded, and the edge cases are grouped logically, though the examples list is somewhat long and could be trimmed without losing the core message.

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 a single parameter, no output schema, and meaningful edge-case complexity, the description covers the essential outcomes: resolved register, not_found with parsed, ambiguous error, related documents, and also_at copies. It does not fully describe the shape of a successful register result, but it provides enough guidance for an agent to invoke the tool and handle the documented error cases.

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?

With 0% schema description coverage and only the word 'citation' in the schema, the description carries the full burden. It compensates with a wide variety of concrete citation formats ('4000.1 II.A.8.d', '38 U.S.C. 3737', 'SOP 50 10 8 B.Ch1.A.2'), giving the agent a strong sense of acceptable input shape beyond 'string'.

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 action — 'Resolve a regulatory citation ... to a register' — with a rich set of concrete examples that make the tool's scope unmistakable. It also clarifies what the tool is not (it refuses ambiguity and does not suggest near matches), which differentiates it from search-like siblings such as search_regs.

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 gives behavioral context — when a citation parses but is missing, when it is ambiguous, and how to respond to an 'ambiguous' error — but it never explicitly names sibling tools or states when to prefer lookup_citation over search_regs, get_reg, or find_in_section. The guidance is implied rather than stated as direct selection criteria.

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 the tool read-only and idempotent, and the description goes well beyond that by disclosing sorting logic, abbreviation expansion, partial-match semantics, currency warnings, version states, and the exact empty-result protocol. There is no contradiction with the 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?

The description is information-dense and every sentence adds value, but it is a single long run-on block with complex formula-like ordering details that are hard to parse quickly. It could benefit from structured bullets or shorter sentences for better scannability, though it is not bloated with 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, so the description must carry the full burden of explaining result fields and interpretation, and it does so thoroughly: rank_score, missing_terms, canonical_citation, currency, version, other_version, special_program, and guidance are all explained or referenced. An agent has enough context to invoke, interpret, and follow up 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 only 25%, but the description compensates strongly for the crucial query parameter by explaining vocabulary preference and abbreviation expansion, and for currency_kind by explaining the filter and examples. The family and limit parameters are not explicitly described, but their enum values and schema constraints are self-explanatory.

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 US mortgage regulator text') and clearly differentiates itself from siblings by positioning find_in_section as returning just paragraphs and get_obligation as returning the whole section. The description makes it obvious that search_regs is the corpus-wide search entry point and not a retrieval tool for 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?

Provides explicit guidance on when and how to search: prefer regulator vocabulary, search again if titles don't fit, and what to do on empty results ('search once more... say so; do not supply the answer from your own knowledge'). It also names the alternative tools and when to use them, so an agent can route correctly without guessing.

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, idempotentHint, and destructiveHint false. The description adds valuable behavioral context: it states what the tool returns (workflow, stages, references, rule-kit version) and the critical privacy constraint ('never send their text to this server') and that playbook tools take only ids. This goes beyond the annotations and helps the agent understand side effects and data handling.

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 bit long but front-loaded with purpose and use cases. Each sentence serves a function: what it does, when to use, what it returns, follow instructions, privacy note, and id-only note. No redundancy; it's efficient despite length.

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 tool with one parameter and no output schema, the description is thorough. It covers the return value, instructions to follow, privacy, and parameter type. It doesn't need more detail given its simplicity, though it could mention if there are any side effects (none expected given idempotent hint). Overall, complete for its purpose.

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 the id parameter with allowed values. The description adds meaning by clarifying that the id is a playbook identifier, not content, and reinforces that the user's text should never be sent. This helps the agent correctly construct the parameter and avoid misuse, adding value 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 clearly states the verb ('start') and resource ('guided compliance playbook'), and it explicitly names the use cases (FNMA AI lender letter, FHA/VA/USDA loan QC) that distinguish it from sibling tools like get_playbook_reference or list_playbooks. The purpose is unambiguous and specific.

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 gives explicit when-to-use conditions ('use this when the user asks to run...') and instructs to follow the returned instructions exactly. It does not explicitly list when not to use it, but the named scenarios and the note that playbook tools take only ids provide clear context. It could be improved by contrasting with get_playbook_kit or list_playbooks, but it's still strong.

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 idempotentHint=true, but the description adds substantial behavioral context: exact outcome categories, the 5,000-word refusal limit, the meaning of 'normalized' matches, the requirement to check omissions, and version semantics including superseded and update-18-optional states. This goes well beyond the annotations and is highly transparent.

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 long but every section earns its place: purpose, outcome taxonomy, operational constraints, and version nuances. It is front-loaded with the core purpose. A slight reduction could improve scannability, but the density is justified for a tool with complex result semantics and no output schema.

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 absence of an output schema and the tool's nuanced outcomes, the description is remarkably complete. It covers exact, normalized, composed, not_found, and not_checked outcomes, explains the omitted-span risk, names the response fields an agent should check, and addresses versioning and update-18 status. An agent has enough context to invoke and interpret the tool 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 0%, so the description must compensate for the bare parameter definitions. It does clarify that the tool checks a passage of text and that register_id can be passed when known, adding meaning to both parameters. However, it never explicitly names the parameters as 'text' or 'register_id' nor specifies register_id format, leaving some minor ambiguity.

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 opens with a specific verb and resource: 'Check whether a passage of text actually appears in the regulator's source document.' It clearly distinguishes this from sibling tools by emphasizing verification against source documents and even notes it works on text from any source, not just text the server returned.

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 explicitly says to use this tool to check your own draft answer before presenting it, which is direct usage guidance. It also explains when to pass register_id versus letting up to 3 candidate sources be located by search. It does not explicitly name sibling alternatives or exclusion conditions, 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.