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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds a crucial behavioral guarantee: it 'never fills in plausible text' when resolution fails, which is a key trust signal beyond the annotations. This adds meaningful context without contradicting 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?

Two sentences, zero waste. The core action is front-loaded ('Resolve a citation...'), and the critical behavior (no fabrication) is stated immediately after. It is compact and well-structured, with every word earning 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?

The tool is simple (3 optional params, output schema exists), so the description need not explain return format. It covers the main behavior, the failure mode, and a usage context. It does not mention parameter interplay or edge cases, but these are minor given the schema and output schema coverage. Overall, it is sufficiently complete for an agent to call it 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 all parameters are already documented with examples. The description adds no additional parameter-level meaning, which aligns with the baseline of 3 when the schema handles the heavy lifting. It neither enriches nor detracts from 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 tool's function: it resolves a citation against the corpus and returns exact matching text or a 'cannot validate' verdict. It distinguishes itself from sibling search/get/compute tools by focusing on validation rather than discovery or calculation. The verb 'resolve' and resource 'citation against the corpus' make the purpose unambiguous.

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 provides a clear when-to-use directive: 'Use this before relying on any AI-generated citation.' This gives actionable context. However, it does not explicitly mention alternatives or exclusions (e.g., when to use search_statute instead), so it falls short of a 5 but earns a 4 for a strong contextual cue.

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 adds significant behavioral context beyond the annotations: it states the computation is 'deterministic,' describes automatic pro-rating, and discloses that the tool returns coverage/exclusion notes plus the payment deadline. It also warns that the result should be verified, which sets accurate expectations about the tool's reliability. No contradiction with the readOnlyHint, idempotentHint, or destructiveHint 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 front-loaded: the first sentence states the formula and scope, the second covers outputs and deadline, and the third adds necessary legal caveats. Every sentence contributes distinct value, and there is no filler or repetition of schema details.

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 calculator with a full input schema and an output schema, the description is complete: it explains the formula, pro-rating, output contents, deadline, and the need to verify underlying legal texts. The presence of an output schema means return-value details do not need to be restated. The caveat about DOLE advisories also addresses the contextual risk of relying on the computation.

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 schema already provides 100% description coverage for the single parameter, including the definition of totalBasicSalary and the pro-rating behavior. The description reinforces the same meaning by stating the formula and the '÷ 12' operation, but it does not add meaning beyond what the schema already explains. A baseline of 3 is appropriate because the schema carries the parameter documentation burden.

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 names a specific verb ('Computes') and resource ('13th-month-pay calculator under PD 851') and states the formula: total basic salary earned within the calendar year ÷ 12. It clearly differentiates itself from sibling compute tools like compute_deadline and compute_prescription by focusing on a specific statutory calculation.

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 clearly indicates when to use the tool: for deterministic 13th-month-pay calculations under PD 851, including pro-rating for partial-year service. It also provides cautionary usage guidance by saying 'Verify the rule text and current DOLE advisories with the corpus before relying on it' and 'Not legal advice.' It does not explicitly name alternative tools or exclusion conditions, but the context is clear.

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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses deterministic behavior, the exact exclusion/inclusion rule, the handling of weekends and holidays, and the critical dependency on caller-supplied holidays. The warning never to assume the calendar and the 'not legal advice' disclaimer add meaningful behavioral context not present in structured metadata.

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 sentences, each carrying distinct information: definition, computation rule, parameter guidance, and verification advice. The most important purpose statement is front-loaded, and there is no redundant or filler content.

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 legal calculator with a rich output schema and full annotations, the description covers the operative rule, scope, parameter semantics, and reliability caveats. It is sufficient for an agent to select the tool, populate parameters correctly, and interpret the result's authority.

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 all parameters. The description adds value by explaining that holidays must be supplied as ISO dates because national holidays are declared per year by proclamation, and by associating the enum options with specific rules of court. This contextualizes the parameters without repeating schema details.

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 function (filing-deadline calculator), names the legal basis (Rule 22), and enumerates the covered reglementary periods (Rules 37, 41, 45, 65). This clearly distinguishes it from sibling calculators like compute_prescription and compute_13th_month.

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 clear context for when the tool applies (deadline computation under the Rules of Court) and explicitly advises verifying rule text with get_provision or cite_validate. It does not explicitly contrast itself with compute_prescription or compute_13th_month, but the domain framing makes the appropriate use obvious.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses that the tool is deterministic, computes arithmetic over cited articles, may not reflect real-world interruption, and is not legal advice. This meaningfully adds behavioral context the annotations do not provide.

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 three sentences with no wasted words, front-loads the core purpose, and packs the caveats and routing into the remaining sentences. Every sentence 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 tool with two parameters, an output schema, and clear annotations, the description is complete: it explains what the tool returns, how to invoke it, what to verify, and what limitations apply. An agent can select and call it correctly without needing additional clarification.

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 schema already covers all parameters at 100%, but the description adds functional meaning: actionType selects the class of action yielding a codal period in years and the exact article, while causeOfActionDate is used to compute the deadline. This goes beyond mere schema labels and helps the agent understand how parameters drive the computation.

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: it computes a prescriptive period under Civil Code Arts. 1144-1149 (RA 386). It clearly distinguishes itself from sibling tools like compute_deadline and compute_13th_month by naming the exact legal domain and the calculation approach.

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 to pick a class of action, optionally provide a cause-of-action date, and explains what outputs follow. It also names get_provision and cite_validate as verification alternatives and warns that interruption under Art. 1155 can affect the result, giving a clear when-to-use and when-to-caveat context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds that it returns metadata and the first passages of the decision, which is useful contextual behavior. No contradictions or additional behavioral details like pagination, which is handled by the output schema and limit parameter.

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 concise sentence, front-loading the resource and key method (citation). It includes a concrete example and mentions the output format, with no extraneous words.

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

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

Given an output schema exists (which would detail metadata and passages), the description provides sufficient information to call the tool correctly: it names the required parameter (citation), explains the return content, and the limit parameter is defined in the schema. Annotations cover safety. Nothing essential 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 100%, with both citation and limit already documented in the input schema (including the example and default). The description does not add extra parameter semantics; it merely reinforces the citation format. The high coverage 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?

The description clearly states the tool returns a case by citation, with metadata and decision passages. This distinguishes it from sibling tools like search_jurisprudence (search-based) and get_provision (specific provision), so an agent can accurately select it when a citation is known.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a citation is available, but does not explicitly contrast with search tools or state when not to use it. It lacks guidance on alternatives, though the mention of 'by citation' provides some context. This is functional but not 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 establish that the tool is read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail beyond that: it returns metadata and only the first passages rather than the full document. 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 a single front-loaded sentence with no filler. It states the purpose, the required lookup keys, gives examples, and notes the output scope in one efficient pass.

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 fully documented input schema, a present output schema, and annotations that cover safety semantics, the description is sufficiently complete. The only non-obvious behavioral limitation—that only the first passages are returned—is explicitly stated.

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 input schema already documents all three parameters with examples and the default/max for limit, so the schema carries the full load. The description repeats the same examples but adds no new semantic information about parameter format or constraints.

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 names a specific verb ('Return'), a concrete resource ('issuance'), and the exact lookup key ('agency + reference number'). It also clarifies the result includes metadata and only the first passages, which separates it from sibling tools like search_issuance and get_provision even without naming them.

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 clearly communicates when to use the tool: when you already have an agency code and reference number and want the issuance's metadata and opening passages. It does not explicitly name alternatives or say 'use search_issuance when the reference is unknown,' so it stops short of a 5, but the context 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?

Annotations already establish read-only/idempotent/non-destructive behavior. The description adds a useful behavioral detail beyond those annotations: the tool is version-aware and reports amended/repealed/superseded status when the corpus tracks it, including a caveat about corpus 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 focused sentences with the core action first and the version-aware qualification second. There is no filler or 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?

Given only two required parameters, a complete output schema, and annotations covering safety semantics, the description provides everything needed to invoke and interpret the result. The corpus-tracking caveat is an honest boundary condition.

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% and both parameters are already explained in the input schema. The description's example illustrates how the parameters combine but does not add materially new 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 uses a specific verb and resource ('Return the exact text of a provision') and gives a concrete example. It is clear about returning current status, but it does not explicitly differentiate itself from siblings like show_amendments or show_history.

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?

There is no explicit when-to-use guidance or exclusion of alternatives. The wording implies the tool is for retrieving exact provision text and status, but it does not tell an agent to prefer show_amendments or show_history for historical views.

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, so no contradiction. The description adds value by revealing the taxonomy source (ADR-000 + ADR-004) and the corpus freshness context, which helps an agent understand what data is being returned beyond the raw schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the primary action and resource, then immediately explains the practical purpose. No filler or redundant content; 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?

The tool is simple with no parameters, has a rich output schema, and annotations cover safety. The description fully covers the calling intent and freshness-check use case, making it complete for an agent to invoke 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?

The tool has zero parameters, so there is no parameter semantics to clarify. Baseline for 0 params is 4; the description correctly focuses on output behavior instead of parameter details.

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 ('Enumerate') with a clear resource ('15-domain compliance taxonomy') and adds detail (ADR-000 core + ADR-004 expansion) that distinguishes it from all sibling tools, which perform searches, lookups, computations, or relationship traversal.

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 provides a clear use case: check corpus refresh timestamps before trusting retrieval results. It does not explicitly name alternative tools or when not to use it, but the purpose is specific enough that an agent can infer appropriate usage.

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 covered. The description adds useful behavioral detail about the matching logic ('at least one of the same statutes') and the notion of a citation neighborhood, going beyond the structured fields without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loads the key input ('Given a case citation'), and every clause adds information. There is no redundant repetition of the title or obvious 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 simple two-parameter read-only tool with an output schema present, the description is complete. It explains the input, the matching behavior, and the practical purpose, while annotations cover idempotency and safety. Nothing essential is missing for an agent to invoke it 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 schema already documents caseCitation and limit well. The description does not add much parameter-level detail beyond restating that the input is a case citation, but it does reinforce the core parameter's role. This meets the baseline for fully covered schema parameters.

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 a specific verb ('find') and resource ('other cases in the corpus that cite at least one of the same statutes'), with a concrete scope ('shared citation neighborhoods'). This distinguishes it from likely siblings like related_laws, which would focus on statutes rather than cases.

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 clear context: input is a case citation, and the use case is identifying lines of jurisprudence. It does not explicitly name alternatives or state when not to use the tool, but the context is enough for an agent to recognize the primary scenario.

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 establish read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond annotations by disclosing that only citations resolving to an ingested statute are returned, warning users that unresolved citations are omitted.

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 and front-loaded: the first sentence states the action and input, and the second sentence adds the critical filtering caveat. Every sentence earns its place without redundancy or fluff.

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 simple read-only lookup tool with full annotation coverage, a complete input schema, and an output schema, the description is sufficient. It specifies the expected input, the output scope, and the important corpus-resolution limitation.

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%, and both parameters (caseCitation and limit) are already documented in the schema. The description reinforces the G.R. No. format but does not add significant 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 states a specific verb ('list') and resource ('the statutes that case cites') with a clear input precondition ('Given a case citation (G.R. No.)'). This clearly distinguishes it from sibling tools like related_cases, which deal with cited cases rather than statutes.

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 provides clear context on when the tool applies: when you have a case citation and need the statutes cited by that case. It does not explicitly name alternatives or exclusions, but the usage context 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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable behavioral insight: 'Below confidence threshold it reports insufficient corpus coverage rather than guessing' – this tells the agent how low-confidence results are handled. It also details pagination behavior ('check hasMore/nextOffset'). Both additions go beyond annotations, but there is no mention of rate limits or auth, though those are not necessarily needed for this read-only 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?

The description is concise and well-structured. It front-loads the core purpose, then adds behavioral and pagination notes. The phrase 'BIR first, Phase 3' is a development milestone that is irrelevant to an agent and adds noise, which is a minor inefficiency. Otherwise, every sentence 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 the tool has 5 parameters, an output schema, and safe annotations, the description covers the essential usage points. Pagination is explained, filters are mentioned, and the low-confidence behavior is disclosed. Since the output schema exists, not describing return values is acceptable. The description is sufficiently complete for an agent to call the tool correctly, though it could mention that the query is mandatory, but that is already in 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 description coverage is 100% – all five parameters have descriptive text in the schema. The description adds minimal extra meaning: it restates that you can filter by agency or issuanceType and mentions using offset for pagination, but these are already described in the schema. No new format or nuance is provided for the parameters, so it meets the baseline 3 but does not exceed it.

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 a specific verb and resource: 'Lexical (FTS5/BM25) search over the administrative issuance corpus'. It distinguishes from siblings such as search_statute and search_jurisprudence by specifying the corpus (administrative issuance) rather than a generic search. The added note 'Information retrieval, not legal advice' clarifies the tool's scope. However, it doesn't explicitly reference sibling tools or contrast them, so it's clear but not fully differentiated.

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 'Filter by agency or issuanceType' and explains pagination, giving operational guidance. But it does not explicitly state when to use this tool versus alternatives like search_statute or search_jurisprudence. The context implies it is for administrative issuances, but no direct when-to-use/when-not-to-use guidance is provided. Sibling tools are not named, so the agent must infer the intended context.

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

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

Beyond the readOnly/idempotent annotations, the description discloses meaningful behavior: it uses lexical FTS5/BM25 matching, returns structured citations, and reports insufficient corpus coverage rather than guessing below a confidence threshold. It also details pagination behavior with hasMore/nextOffset.

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-loaded with the core search purpose, and every sentence contributes either scope, caveat, behavioral transparency, or operational guidance. No filler or 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 search tool with rich annotations and a full input schema, the description covers the essential context: corpus scope, safety/behavioral disclaimers, result nature, confidence fallback, and pagination. It is sufficiently complete for an agent to invoke it 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?

Input schema already covers 100% of parameters, but the description adds practical semantics: pagination via offset with hasMore/nextOffset, and using court to narrow results. These additions go beyond simple schema repetition.

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 ('search') over a specific resource ('case corpus' covering SC, CA, SB, CTA decisions), which clearly distinguishes it from statute or issuance search tools. The description also clarifies that it is information retrieval, not legal advice.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool by specifying it searches case law, and gives in-tool guidance like 'Use court to narrow results.' However, it does not explicitly mention alternatives such as search_statute or related_cases, so the when-to-use vs alternatives is left mostly 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 declare readOnly/idempotent/non-destructive, and the description adds substantial behavior: FTS5/BM25 lexical matching, confidence-threshold handling ('reports insufficient corpus coverage rather than guessing'), structured citations, and pagination semantics (hasMore/nextOffset). 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 description is compact and front-loaded, leading with the core purpose, then adding caveats and pagination/domain guidance. Every sentence carries useful information with no 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?

With an output schema present, the description doesn't need to detail return fields. It covers purpose, scope, low-confidence behavior, pagination, and domain narrowing, which is complete for this read-only search tool in its sibling context.

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 covers all 4 parameters with descriptions, so baseline is 3. The description adds actionable semantics beyond the schema: how to use offset ('check hasMore/nextOffset') and domain ('narrow results'), which helps an agent use these parameters correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description states a specific verb ('Lexical ... search') and resource ('statute corpus') with enumerated document types, making it clear this is the statutory search tool. This distinguishes it from sibling tools like search_jurisprudence and search_issuance, even without naming them.

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 context: it searches statutes and is not for legal advice, and it advises using domain to narrow results. However, it does not explicitly state when to prefer search_statute over search_jurisprudence/search_issuance or when not to use it, leaving the alternative selection implied.

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, covering the safety profile. The description adds behavioral context by specifying what the amendment log contains (amending law, affected provision, effective date), which goes beyond the annotations. It does not contradict the annotations. This adds meaningful transparency about the tool's output behavior, though it omits details like ordering or pagination, which are less critical given the output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. The primary purpose is front-loaded in the first sentence, and the complementary usage hint is in the second. It is appropriately sized for a simple tool and does not repeat schema information. Excellent structure and brevity.

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

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

Given the tool's moderate complexity (3 params, 1 required) and the presence of an output schema, the description covers the essential context: what it does, what it returns, and a complementary usage note. It does not explicitly mention the optional parameters (limit, actNumber), but those are documented in the schema with descriptions. No critical information for a correct call is missing, though it could benefit from a note on default behavior or error handling. Overall, it is sufficiently complete for an agent to use it 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%, meaning all parameters (statute, limit, actNumber) are already documented in the input schema with their own descriptions. The tool description does not add any extra meaning about these parameters; it only mentions the output fields. Since the schema fully covers parameter semantics, the baseline of 3 applies, and the description does not enhance it further.

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 ('List') and a resource ('amendment log for a statute') with the fields returned (amending law, affected provision, effective date). It is clear about what the tool does. However, it does not explicitly differentiate from sibling tools like 'show_history' or 'related_laws', which might overlap in purpose. The mention of 'amendment log' is specific, but without naming alternatives, it leaves some 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?

The description gives a clear complementary usage hint: 'Use with get_provision to confirm the current text of an amended provision.' This implies when to use this tool (to see amendment history) and when to use another (to get current text). However, it does not explicitly state when NOT to use this tool or contrast with other siblings like 'show_history' or 'related_laws'. The guidance is helpful but not comprehensive, earning a 3 rather than a 4.

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 read-only, idempotent, and non-destructive behavior. The description adds value by disclosing that unresolved citations are deliberately omitted and that the citation graph is the source, which are useful behavioral traits not visible in 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?

Two sentences with no filler; the first sentence states the core action and scope, and the second adds a key boundary. All content 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 simple read-only list tool with two well-documented parameters and an output schema, the description is complete: it defines what is returned, where the data comes from, and what is excluded. No critical behavior 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 100% for both parameters, so the schema already documents caseCitation and limit. The description does not add parameter-specific meaning beyond reaffirming the domain of citations, which matches the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific action 'List every citation a case makes' and specifies the resource as statutes and other cases recorded in the citation graph. It is clear and unambiguous, though it does not explicitly contrast itself with siblings like related_laws or show_cross_references.

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 implied: an agent can infer the tool is for retrieving citations made by a case. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternative sibling is named, so an agent may need external context to distinguish it from related_cases or show_cross_references.

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 communicate read-only, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds some context by identifying the data sources ('domain registry' and 'corpus graph') and the curated nature of the references, but it does not explain limit behavior, possible empty results, or how the two edge types interact.

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 dense sentence with no filler. It front-loads the core output components and avoids redundant restatement of the title or annotations.

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 that the tool has a rich output schema and annotations covering safety, the description is largely complete for a read-only cross-reference lookup. The main gap is the lack of differentiation from sibling tools, but that is more of a usage-guidance concern than a completeness concern for the tool's core behavior.

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

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

The input schema has 100% description coverage for all three parameters, including examples and constraints. The description does not add parameter-level detail, but the baseline of 3 applies because the schema already carries the semantic weight.

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 what the tool returns: curated cross-domain references from the domain registry plus statute-to-statute citation edges from the corpus graph. It uses a specific resource and adds provenance, going beyond a mere restatement of the tool name/title. It does not explicitly contrast with siblings, but the composition of the output is reasonably clear.

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 no guidance about when to prefer this tool over siblings like show_citations, related_laws, or show_dependencies. There are no explicit use cases, exclusions, or alternative routing hints, so an agent must infer when this tool is appropriate.

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 read-only, idempotent, and non-destructive behavior. The description adds useful context by explaining the two directional results ('dependencies' and 'dependentOn') and the corpus-grounded law-to-law edge source, but it does not disclose additional behaviors like default limits or response shape, which are partially handled by the schema and output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, information-dense sentence that front-loads the core behavior and then clarifies the two directions. No filler or redundant restatement of the title or 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 a rich input schema, output schema, and safety annotations, the description covers the essential semantics: directionality, edge type, and corpus grounding. It lacks explicit sibling routing guidance, but the core information needed to call the tool correctly is present.

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 schema already documents statute, limit, and actNumber. The description does not add new parameter-level meaning beyond confirming that the statute is the source node of the dependency graph.

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 and resource: 'Show which statutes a statute cites' and 'which statutes cite it back (dependentOn)'. It clearly differentiates the tool from siblings like related_laws and show_citations by specifying law-to-law, corpus-grounded dependency edges.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for statute-to-statute dependency graphs, but it never explicitly states when to choose it over similar siblings like related_laws, show_citations, or show_cross_references. Usage context is inferable but not directly stated.

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 covered. The description adds useful behavioral context: it returns every version, orders by valid_from, and can compare current versus earlier text. These are meaningful additions but not extensive behavioral disclosures, so a 3 is appropriate.

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 with no filler. The main action is front-loaded, followed by a concise statement of the tool's purpose. Every sentence 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?

The tool is a read-only lookup with full schema coverage, annotations, and an output schema. The description captures the core behavior and use case. It could be more complete by explicitly noting when not to use it or how it relates to show_amendments, but nothing essential is missing 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 description coverage is 100%, so the parameters are already fully documented (statute, actNumber, provision). The description adds no additional parameter-level meaning beyond what the schema provides, 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?

The description clearly states a specific verb and resource: 'Show every recorded version of a provision', with the additional qualifier of ordering by effective date. It does not explicitly contrast with sibling tools like show_amendments, so it stops just short of full differentiation, but the wording is precise enough that an agent can infer its focus.

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 provides a clear use case: 'Confirms whether the current text differs from an earlier version.' This tells an agent when the tool would be relevant. However, it does not mention when not to use it or name an alternative sibling, so it lacks explicit exclusionary 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 mark the operation as read-only, idempotent, and non-destructive. The description adds meaningful behavior: it resolves citations to the statute and includes citing cases, which tells the agent the returned references are filtered rather than raw mentions. 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?

A single, front-loaded sentence that conveys the core function and key output without filler. 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?

With a full parameter schema, an output schema, and safety annotations, the description provides all essential calling context. The IRR-resolution detail covers the one non-obvious behavior an agent needs to anticipate.

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%: all three parameters (statute, limit, actNumber) have descriptions. The tool description adds no parameter-level detail, so it stays at the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Find'), a specific resource ('Implementing Rules and Regulations (IRR) of a statute'), and the output ('citations... with the citing cases'). This clearly separates it from sibling tools like show_amendments or show_citations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case (retrieving IRR references for a statute) but never explicitly says when to choose it over related siblings such as show_citations or show_cross_references, nor does it state when not to use it.

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