Vaquill

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

With no annotations, the description carries the full disclosure burden and does so strongly. It states delivery mechanism (webhook with HMAC-SHA256 signing or email), trigger semantics (only on existing refresh, no crawling, no real-time trigger), and immutability of channel. These are non-obvious behaviors that materially affect an agent's expectations and follow-up actions.

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

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

Three sentences with no filler: the first states the action, the second explains the notification mechanics, and the third captures the key lifecycle constraint. It is front-loaded with purpose and each 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?

While the behavioral aspects are well covered, the input side is incomplete for a 6-parameter tool with zero schema description coverage and no annotations. An agent would not know what corpus_type values are valid, what act_ids or state mean, or how webhook_url/email_address relate to channel. The output schema reduces the need to document return values, but not the need to document input semantics.

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, but it only adds semantic value for channel by explaining webhook/email delivery and immutability. The required corpus_type is never explained, and state, act_ids, webhook_url, and email_address are left entirely unexplained. Most of the six parameters remain opaque.

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

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

Opens with a specific verb and object: 'Subscribe to a board' and clarifies that the result is a notification subscription. It is immediately distinguishable from update_watch, delete_watch, test_watch, and list_watches even without consulting the schema. The delivery-method mention further anchors what the tool actually creates.

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

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

Gives clear context about when the tool is appropriate by explaining the trigger model: notifications fire only when the source's existing refresh finds real changes, so an agent can rule it out if real-time delivery or crawling is expected. It also gives an explicit alternative for changing channel: delete and recreate. It stops short of naming sibling update_watch as the general mutation path, so it is not a full when/when-not guide.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states destructive side effects: deletion is immediate, permanent, and removes delivery history. This is exactly the kind of irreversible behavior an agent must know before invoking.

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 core action is front-loaded, side effects are stated immediately, and the alternative is given as a short, useful second sentence. Every word 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 single-parameter destructive tool with an output schema, this description covers purpose, authorization scope, irreversible side effects, and the relevant alternative. Nothing essential is missing for an agent to decide whether to call it and what to expect.

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 0% and the description does not explicitly define watch_id. However, the parameter name is self-explanatory and the description's 'a watch you own' implies the watch_id identifies the specific watch to delete. This is adequate but thin; no format or provenance guidance is provided.

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?

Begins with a specific verb and resource ('Delete a watch you own') and immediately distinguishes itself from update_watch. The phrase 'you own' adds a scope constraint not present in the name, making 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?

Explicitly names the alternative tool (update_watch) and the exact condition for choosing it ('to stop notifications without losing the config or history'). This gives an agent a clear decision rule for delete_watch vs. update_watch.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses depth semantics, cost differences between depth 1 and 2, graph direction coverage, and node-level information. It does not mention pagination, errors, or rate limits, but the output schema covers return structure.

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 concept, and every sentence adds value. It covers purpose, graph semantics, depth/cost trade-off, and recommended usage 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 5-parameter tool with no schema-level field descriptions, the description is incomplete: limit and country_code are never addressed, and direction is only vaguely implied. However, it does cover purpose, depth behavior, and output expectations, and the presence of an output schema reduces the need to explain return values.

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 0% description coverage, so the description must compensate. It explains depth meaning well and hints at direction via 'who cites it and what it relies on', but limit and country_code are completely unexplained, and direction's enum values are only implicit.

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 specifies a concrete output: a citation graph around a US case, covering both inbound and outbound citations, with per-node citation counts and treatment hints. It clearly distinguishes this graph-focused case tool from the statute/section siblings by emphasizing the case-law context and influence judgment.

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 to use the tool: to judge whether a case is still good law and how influential it has been. It does not explicitly name exclusions or alternative siblings, but the intended use case is specific enough to guide 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It discloses that the tool is free and requires no authentication, which are important operational traits. It does not describe response format or potential limitations, but the output schema is present, so that burden is reduced.

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: two sentences with the core subject front-loaded. It states the purpose, gives the conversion rate example, notes the operational traits, and provides practical usage guidance without any 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, parameterless pricing lookup tool, the description covers its purpose, the pricing details, the no-auth/free behavior, and when to call it. The presence of an output schema means return values do not need to be described. No significant contextual gap remains.

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 zero parameters, so there are no parameter semantics to explain. The description appropriately avoids inventing parameter details. The baseline of 4 applies for a no-parameter tool.

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 provides current API credit pricing, per-endpoint credit costs, and the credit-to-currency conversion rate. It identifies the resource and what the agent can learn. It also distinguishes itself from the legal-research sibling tools by focusing on pricing rather than statutes, cases, or watches.

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 use this tool to check what a call will cost before making it, which provides clear usage context. It does not mention when not to use it or name alternatives, but no sibling tool appears to serve a pricing function, so exclusion guidance is less critical.

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

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

With no annotations, the description carries the full behavioral burden, and it does so well: it states that this is capture history rather than publisher history, specifies ordering, and defines the empty-list semantics to prevent a critical misinterpretation. This goes well beyond a typical tool description.

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, using two sentences to convey scope, ordering, provenance, a critical empty-list caveat, and an alternative. 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 output schema handles return structure, and the description provides strong semantic context about what the data means. However, the unexplained act_id parameter is a real gap for correct invocation, especially since the description refers to 'one section' but the only parameter is act_id.

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 sole required parameter act_id has 0% schema description coverage and is never mentioned in the tool description. The agent must guess its meaning from the parameter name alone, and the relationship between 'one section' and 'act_id' is not explained.

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

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

The description clearly identifies the resource (one section's observed changes) and the action (retrieve added/amended/removed events, newest first). It draws a meaningful distinction from the publisher's amendmentHistory, but it does not explicitly contrast with sibling tools that might appear similar, such as get_watch_change_diff.

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

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

It explicitly says when to use this tool — when you want the capture history — and when not to use it: for the publisher's history, read amendmentHistory. It also clarifies the meaning of an empty list, which is essential for correct interpretation.

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

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

With no annotations, the description must carry behavioral context. It usefully explains that the result is the inverse of crossReferences and suggests what the data means. But it does not disclose side effects, auth requirements, rate limits, pagination behavior, or error cases, leaving gaps.

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 tight sentences: the first defines the precise behavior, the second gives two concrete use cases. 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?

The output schema exists, so return format need not be described. Still, parameter semantics are thin and the description does not compare itself with related sibling tools such as get_citation_network. The core idea is clear, but an agent lacks enough contextual detail to handle edge cases or choose confidently between similar tools.

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. It only implies via 'a given section' that the act_id identifies the section, and says nothing about the limit parameter or expected id format. The schema's name and type give minimal clues, but this is insufficient for reliable invocation.

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

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

The description clearly identifies the resource ('USC and CFR sections whose text cross-references a given section') and the action ('cited by' / inverse of crossReferences). It also distinguishes the tool by explaining it is the inverse of the crossReferences already returned on a section lookup, which separates it from forward-reference tools.

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

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

The description provides explicit use cases: find where a definition or requirement is invoked, or gauge how load-bearing a provision is. However, it does not mention alternative sibling tools or conditions that would make another tool more 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add useful behavioral context, such as ranking by similarity and restricting to state statutes, but it leaves ranking criteria, coverage limitations, and read-only/no-side-effect status implicit. This is adequate but not deeply 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 two concise sentences with the core resource and scope front-loaded. Every clause contributes information: cross-state scope, subject-match semantics, ranking, state-statute restriction, and recommended use cases. 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?

Given that an output schema exists and the tool is fairly simple, the description covers purpose and use scenarios well. However, parameter semantics are under-specified and behavioral caveats are missing, so an agent still has to guess at act_id format and limit behavior. Completeness is only partial.

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 missing parameter documentation. It only vaguely maps act_id to 'a given state statute section' and does not mention the limit parameter, its default, or how to construct a valid act_id. This is a significant gap for an agent trying to call the tool 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?

The description clearly states what is returned: provisions in other states addressing the same subject as a given state statute section, ranked by similarity. The phrases 'OTHER states' and 'State statutes only' sharply differentiate this from within-state, federal, or case-law tools, including siblings like get_section_neighbors and get_section_cited_by.

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 names appropriate use cases: fifty-state surveys, multi-jurisdiction compliance, and checking whether a home-state rule is typical or an outlier. It also provides a hard scope constraint, 'State statutes only.' However, it stops short of naming alternative tools or explicit when-not-to-use conditions, so it does not earn a 5.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explains that definitions are parsed from the chapter's definitions section and reflect statutory rather than ordinary meaning. However, it does not mention read-only behavior, empty-result cases, or any limitations.

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 short, front-loaded, and every sentence contributes. The first sentence is a grammatical fragment rather than a direct verb statement, but there is no wasted 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?

The output schema presumably covers return values, so no return description is needed. But the sole input parameter is unexplained and disconnected from the stated purpose, so an agent cannot reliably know how to call the tool. The useful usage guidance does not compensate for this 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 0%, and the description adds no meaning for the required act_id parameter. The tool is about section definitions, but the description never explains how act_id identifies a section or what format it should take, leaving a critical invocation gap.

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

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

The description clearly identifies the resource—term definitions governing a section—and the source: the chapter's definitions section. It distinguishes this from search or text-retrieval siblings, though it is phrased as a noun phrase rather than an explicit verb-first statement.

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 a concrete trigger condition: use when a provision depends on a term of art and the statute's own definition is needed, not the ordinary meaning. It does not name alternative tools or spell out when not to use it, but the usage 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?

With no annotations provided, the description carries the burden of explaining behavior. It states what the tool returns, the scope (same chapter or code), and the ordering (statutory order). It does not mention limit behavior or pagination, but the output schema exists and the core behavior is disclosed without contradiction.

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 filler. The first sentence defines the tool precisely, and the second provides actionable use cases. Information is front-loaded and 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?

Despite a clear purpose statement, the description is incomplete for an agent to call the tool safely: the meaning of act_id is unexplained, the limit parameter is unmentioned, and the number of neighbors returned is ambiguous given the default limit of 5. The output schema helps with return shape but cannot compensate for missing parameter semantics.

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, but it says nothing about act_id or limit. The description refers to 'a given section' yet the schema only exposes act_id, leaving it unclear how the target section is identified. This is a critical gap for correct invocation.

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

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

The description clearly identifies the resource ('sections immediately before and after a given section') and the ordering principle ('within its own chapter or code, in statutory order'). It distinguishes this from sibling tools like get_section_changes or get_section_definitions by focusing on positional neighbors.

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 names concrete use cases: reading a provision in context, finding a definitions or penalties sibling, and checking whether operative language continues into the next section. It does not explicitly state when not to use it or compare to alternatives, but the use-case framing gives an agent reliable selection guidance.

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

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

With no annotations, the description carries the full burden and does useful work: it discloses the 50-section cap, that not-found sections are skipped, and that skipped sections are not charged. It also references the output shape indirectly via 'Same fields as get_us_statute_section.' It could add error behavior for oversized inputs, but the key non-obvious behaviors are covered.

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

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

Three sentences, each earning its place: what it does, when to prefer it, and the skipped/not-charged behavior. The main purpose is front-loaded and 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 an output schema present and one required parameter, the description covers the important invocation context: batch cap, skip behavior, charging, and the relationship to get_us_statute_section. The only minor gap is what happens when the input list exceeds 50 IDs, which is not specified.

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 0%, so the description is the only semantic source for the single parameter. It clarifies that act_ids is a list of section identifiers, implies they come from search results, and states the 50-item ceiling. It doesn't provide an ID format example, but for a simple array-of-strings parameter the description compensates well.

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 begins with a specific verb and resource: 'Metadata for up to 50 sections in one call, by a list of act_ids.' It also distinguishes itself from get_us_statute_section by noting it returns the same fields and is the batch alternative. An agent can tell what it does and how it differs from the closest sibling.

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

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

'Use instead of looping that tool when you already hold several act_ids, for example every result of one search' gives an explicit use case and alternative. It does not explicitly state the inverse condition ('use the single-section tool when you have only one ID'), but that exclusion is strongly 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?

With no annotations provided, the description carries the full behavioral burden. It discloses that only metadata is returned, not the full text, and hints at cost implications ('before paying for its full body'). It also enumerates the output categories, which clarifies the tool's non-destructive, retrieval-oriented nature.

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 tight and front-loaded: the first sentence establishes the core purpose and content, the second handles the critical exclusion, and the third gives the use case. Every sentence earns its place 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?

For a simple one-parameter lookup with an output schema present, the description is complete. It covers what is returned, what is not returned, when to use it, and how it relates to the most relevant sibling. The output schema can handle further structural details.

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. It does state that the tool selects a section 'by act_id', which clarifies that act_id is the lookup key. However, it provides no format, source, or example for act_id, leaving the agent with minimal additional guidance beyond the schema's bare string type.

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: metadata for one US statute section, listing the specific data included (citation, hierarchy, breadcrumb, amendment history, links). It explicitly distinguishes itself from the sibling get_us_statute_section_text by stating it does NOT include section text, making the tool's 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 both a positive use case ('Good for confirming you have the right section before paying for its full body') and a direct alternative ('use get_us_statute_section_text for that'). This gives the agent explicit routing logic between this tool and its sibling.

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

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

With no annotations, the description carries the disclosure burden and it does meaningfully disclose behavior: it returns both styled HTML (with cross-references and paragraph numbering as officially published) and plain text. It does not mention error behavior or access requirements, but for a read-only text retrieval tool this is a solid disclosure.

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

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

Two sentences, front-loaded with the core function and output format, followed by the use case. There is no filler, repetition, or unnecessary detail.

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 and has an output schema, so return values need no further description. However, the crucial act_id parameter semantics are left vague, and the description does not point to a sibling like resolve_statute_citation for obtaining a valid ID, leaving a meaningful gap for agents.

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 no description for act_id and schema description coverage is 0%, so the description must compensate. The phrase 'by act_id' mostly restates the parameter name and role; it does not explain the expected format, how to obtain the ID, or what kind of act identifier is valid.

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 that this tool fetches the full text of a US statute, regulation, or rule section by act_id, and specifies the two output forms: styled HTML and plain text. The use-case phrase 'actual statutory language... rather than just cite' distinguishes it from citation-style lookups among the sibling tools.

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

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

It gives an explicit when-to-use condition: when actual statutory language is needed for quoting, drafting, or analysis. It does not name sibling alternatives or state a when-not-to-use condition, so it stops short of complete 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?

No annotations are provided, so the description carries the full behavioral burden. It explicitly explains that a missing side is not an error, references hasBefore/hasAfter to decide what text is present, and warns that this tool returns section text with a cost implication. This is substantial behavioral disclosure beyond the 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 front-loads the core return value in the first sentence, then adds three targeted caveats in compact sentences. No filler; each sentence adds decision-relevant information.

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 output schema covers return structure, and the description covers null semantics, the hasDiff prerequisite, and the cost profile. The main gap is the lack of explicit parameter definitions for watch_id and change_id, which is notable given zero schema coverage.

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 needed to define watch_id and change_id, but it only refers to 'one specific change' and 'the change list.' The names are suggestive but not documented, leaving the agent to infer where the IDs come from and what they identify.

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 action and object: returning the full text of a changed section BEFORE and AFTER one specific change as whole documents ready to diff. It clearly distinguishes the tool from sibling list/statute tools, reinforced by the explicit contrast with the rest of the law-change tools.

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

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

It gives a concrete precondition ('Only meaningful where hasDiff is true on the change list') and a cost warning for looping, telling the agent when to invoke it and to be cautious at scale. It does not name a specific sibling alternative, but the guidance is enough to avoid misuse.

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

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

With no annotations, the description carries the full burden. It usefully discloses that results include refresh cadence and that boards are identified by corpusType plus state. However, it does not mention pagination behavior despite limit/offset parameters, and the phrase 'every watchable board' is ambiguous given the default limit of 500.

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 filler. It front-loads the action, defines the key domain concept, and ends with practical usage context. 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 read-only list tool with an output schema and four conventional parameters, the description is mostly complete: it defines what a board is, how it is identified, what data is returned, and when to call it. Minor gaps are the lack of explicit filter semantics and pagination notice, but the defaults and output schema cover much of that.

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. It does add meaning to state and corpus_type by explaining the identity rule and federal null-state case. It does not explain limit/offset, though those are conventional pagination parameters whose defaults are already in 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?

Description opens with a specific verb and resource: 'List every watchable board', then defines the domain term with concrete examples (Federal Register, CFR, state statutes). The board concept is clearly distinguished from sibling tools like list_watches or list_statutes_* by emphasizing 'watchable board' and the create_watch relationship.

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

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

'Use to discover what can be subscribed to before calling create_watch' explicitly states the intended context and links to the downstream tool. It does not provide when-not-to-use guidance or name alternative tools, so it falls short of a 5, but the usage window 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?

With no annotations, the description carries the behavioral disclosure burden. It usefully discloses that it walks the hierarchy, returns child divisions in statutory order, and works 'under any level.' However, it does not explain default behavior when code/state/corpus_type are null, how deep the walk goes, or pagination limits.

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 behavior is front-loaded, followed by a concise usage note. 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?

Despite an output schema, the description leaves critical invocation details unexplained: all three parameters are optional and undocumented, and the tool will likely rely on defaults to decide what to list. The description does not say how to target a specific jurisdiction or what happens at the top level with no parameters, making it incomplete for confident 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 0%, and the description does not compensate. It mentions 'under any level' and 'chapter' but never maps those concepts to the three parameters (code, state, corpus_type). An agent cannot tell which parameter identifies the code or what a null value means.

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 child divisions ... under any level, in statutory order.' It clearly names the kinds of divisions (titles, chapters, parts, or sections) and distinguishes itself from sibling tools that look up or search by section number.

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 the tool: 'when you do not yet know the section number, or to enumerate everything under a chapter.' This gives an explicit browsing use case, though it does not name alternatives or state explicit exclusions.

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

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

With no annotations, the description carries the behavioral transparency burden. It discloses that the tool returns a self-describing matrix and implies a read-only, introspective operation with no side effects. It does not explicitly state 'read-only' but the zero-parameter matrix-returning nature makes the behavior reasonably clear.

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 efficient sentences, no filler. The first sentence defines the output in a self-contained noun phrase, and the second sentence provides actionable usage guidance. Every word 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 output schema already documents the return structure, so no further return-value explanation is needed. For a zero-parameter introspection tool, the description fully covers purpose, use case, and selection 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?

The tool has zero parameters, and the schema confirms this. The description adds no parameter semantics nor does it need to; the baseline of 4 applies because there is nothing to document beyond the schema's empty properties object.

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 deliverable: a coverage matrix of every corpusType held with per-jurisdiction section counts. This clearly distinguishes it from siblings like list_statute_divisions or list_statutes_laws, which imply different data structures.

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 instructs when to use the tool: before answering a jurisdiction question, to verify that a state and body of law are actually covered. It also explains the consequence of not using it — searching a non-existent corpus — which serves as a clear behavioral directive.

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

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

With no annotations, the description carries the burden of explaining behavior. It describes the output contents (corpusType and section count) and implies a read-only catalog operation, but it does not mention pagination, default behavior, or any side effects. This is acceptable but not thorough.

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 concise sentences, both informative: the first defines what the tool returns and the second states the intended use. 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?

The output schema covers return values, and the core purpose is clear, but the 0% schema coverage for parameters leaves limit, offset, state, and corpus_type undocumented. For a simple optional-parameter list tool this is an adequate minimum, yet an agent still needs to infer parameter semantics from names alone.

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, but it does not explain limit, offset, state, or corpus_type beyond implying corpusType values in the output. The connection to 'a state's statutes' hints at the state parameter but never maps inputs to behavior.

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

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

The description clearly identifies the tool as a catalog of distinct bodies of law and states the key returned fields (corpusType and section count). It also connects the tool to search_us_statutes, distinguishing it from sibling list tools.

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

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

The description gives a direct use case: discover the corpusType values that filter search_us_statutes. It does not explicitly mention when-not-to-use or name alternative listing tools, but the context is clear enough 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the tool writes nothing, cannot suppress or double-fire a delivery, and only returns metadata (never section text). It also discloses the scope (entire captured history) and pagination behavior. This goes well beyond what would be expected and provides a clear safety profile for an agent.

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 ('What a watched source added, amended or removed'), then adds essential details in a logical order: metadata-only, history scope, safety/polling, and pagination. Every sentence provides value with no fluff 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?

While the description covers purpose, output type, scope, safety, and pagination intent, it introduces a pagination concept (sinceId/cursor) that is not reflected in the schema, which uses offset/limit. This inconsistency leaves the agent without a clear understanding of how to actually page through results. The output schema exists, so return values are likely covered, but input parameter handling is incomplete due to the mismatch.

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 has no descriptions (coverage 0%), so the description must compensate. However, it fails to explain the actual parameters limit, offset, and watch_id. Instead, it references 'sinceId' and 'returned cursor,' which do not appear in the schema, creating a mismatch with the offset/limit pagination. An agent would be uncertain how to set limit/offset or what watch_id refers to, though watch_id is implied by context. This is a significant gap given the low schema coverage.

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: additions, amendments, and removals from a watched source, with specific fields (section identifier, citation, title, detection time) and ordering (newest first). It differentiates itself from siblings by explicitly noting 'Metadata only, never section text' and covering the full history, not just since subscription, which sets it apart from list_watch_deliveries or get_section_changes.

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 to use the tool: it is safe to poll, writes nothing, and cannot suppress or double-fire a delivery. It also mentions pagination guidance ('Page with sinceId and the returned cursor') and clarifies that it covers the whole captured history, implying it can be used for historical retrieval. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full transparency burden. It reveals important behavior: logs are retained for 90 days, only webhook deliveries are logged, email sends are not logged per attempt, and an email-only watch yields an empty result. It does not mention pagination order or permissions, but these are minor for a read-only inspection 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?

Two sentences with no waste. The core purpose and the most important limitation are front-loaded, and the last sentence gives the intended use case. 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 description covers what the log contains, retention, webhook-only behavior, and the debugging use case. An output schema exists and the parameters are simple. The only notable gap is the undocumented limit/offset semantics, but this is minor given the simplicity and clarity of the rest of the description.

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 lack of parameter documentation. It connects watch_id to the target watch, but it says nothing about limit or offset, which are left to the agent to infer from standard list semantics. The schema only provides types and defaults, not meaning.

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 does: it returns a per-attempt delivery log for one watch, including status code, error, and attempt number. It distinguishes itself from siblings like list_watch_changes and test_watch by framing itself as the delivery-history debugging tool for webhooks.

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 concrete use case: debug a webhook that is not arriving. It also clearly warns that email-only watches always return an empty list, which prevents an agent from making a wrong call. It does not name alternative tools explicitly, but the context is sufficient.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It clarifies scope ('watches you own') and the included delivery outcome field, but does not explicitly state that the operation is read-only, nor does it mention pagination behavior, rate limits, or authorization requirements. The read-only nature is strongly implied but not stated.

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 unnecessary words. It front-loads the action and output fields, then provides the practical 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 output schema exists, so return-value details are covered structurally. The description explains what is listed, that it is scoped to owned watches, and why an agent would call it. It lacks explicit pagination semantics, but for a simple list tool with optional limit/offset, the overall context is nearly complete.

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

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

Schema description coverage is 0%, and the description does not mention the limit or offset parameters at all. Their names and defaults provide basic meaning, but the description adds no parameter-level guidance, such as default pagination behavior or how to page through all watches.

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'), a clear resource ('board watches you own'), and enumerates the returned fields. It also distinguishes itself from other watch-related tools by noting its role in finding a watchId for other watch operations.

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 context for use: 'Use to find a watchId for the other watch tools.' It does not explicitly state when not to use it or name alternative siblings, but the use case is sufficiently clear for an agent to select it.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly frames the operation as a retrieval action and enumerates what the response will contain. It doesn't cover failure modes or access constraints, but for a simple lookup operation the core behavior is 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?

Two sentences, front-loaded with the primary purpose, followed by usage guidance. Every phrase adds value 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?

The description covers purpose, output contents, and usage well, and an output schema exists to document return structure. However, the optional country_code parameter is completely undocumented and citation format is only implied through the sibling tool reference, leaving a real gap for an agent invoking the tool independently.

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 by explaining the parameters. It never describes the expected format of 'citation' or the meaning/purpose of the optional 'country_code'. The only hint is the instruction to use it after resolve_citation, which is not enough to correctly handle both 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 identifies the resource ('one US case') and specifies the returned content: opinion text, panel of judges, citation list, and disposition. It also distinguishes this tool from resolve_citation by framing it as the follow-up step for reading or quoting the opinion. This is specific and leaves no ambiguity about what the tool does.

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

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

It explicitly says 'Use after resolve_citation' and provides the deciding condition: use this when you need to read or quote the opinion rather than just confirm it exists. This gives clear, actionable guidance and differentiates it from the most relevant sibling 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?

With no annotations present, the description carries the burden of explaining behavior. It discloses that results are compact, top-few, limited to essential fields, and cheaper/flatter than the alternative. It also indicates the same boolean syntax as search_legal_cases. It does not mention potential rate limits, auth, or exact top_k behavior, but the essential behavioral traits are covered.

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 purpose, and each sentence adds value: what it returns, how it relates to a sibling, and when to prefer it. 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?

For a simple search tool with an output schema, the return format does not need to be spelled out in the description. However, with 7 parameters and 0% schema coverage, the description leaves invocation details thin. It adequately covers selection context but not enough of the parameter behavior to be fully complete.

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

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

Schema description coverage is 0%, so the description must compensate, but it only hints that query uses the same boolean syntax as search_legal_cases. Parameters like year_from, year_to, court_name, court_type, and country_code are not explained at all, though some are self-explanatory from their names. The description does not add enough value for the 7-parameter 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 starts with a specific verb and resource: a fast, compact US case law search that returns top results with a defined set of fields. It clearly differentiates itself from search_legal_cases while staying distinct from nearby siblings like lookup_case and resolve_citation.

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

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

It explicitly states when to use this tool ('quick orientation') and contrasts it with the alternative search_legal_cases for full results. The shape and cost difference is highlighted, so an agent can confidently choose between the two.

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

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

With no annotations, the description must carry behavioral detail. It discloses a key behavior: 'Returns found=false rather than an error when the citation cannot be resolved', which is useful and goes beyond the schema. It does not state read-only semantics or other side effects, but the resolver nature makes that less critical.

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

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

Three sentences, each earning its place: purpose with examples, failure behavior, and usage routing. No filler, and the most important information is front-loaded.

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 description covers core purpose, failure mode, output, and sibling context, and the output schema covers return values. The unexplained country_code parameter is the main gap, but the tool is still usable for its primary target case; this keeps it above average but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It explains the citation parameter with format examples and the 'US case citation' scope, but country_code is never mentioned. With one of two parameters left undocumented, the compensation is only partial.

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 with a specific resource ('Resolve a US case citation'), gives concrete examples ('603 U.S. 369', '410 U.S. 113'), and states the output ('canonical record', 'case details and cluster id'). The 'US case' scoping also distinguishes it from the sibling resolve_statute_citation.

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 'Use before lookup_case or get_citation_network, both of which want the resolved id', which gives clear context and names alternatives. It does not explicitly say when not to use it, such as directing statute citations to resolve_statute_citation, but the US-case scope implies that exclusion.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the result is 'confirmed' and includes an official source link and act_id, which is useful, but it does not disclose potential failure modes, validation behavior, jurisdiction limitations, or whether the operation is read-only. For a tool with zero annotation coverage, this is a meaningful gap.

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 filler. The first sentence front-loads the core behavior and expected return, and the second gives crisp usage direction. 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 a single required parameter and an output schema that can define the return shape, the description covers the essential invocation context: input format, example values, expected output components, and guidance on when to call it. It could be more complete by naming the alternative resolve_citation and clarifying how they differ, but the core decision context 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?

The input schema provides parameter name and type only, with 0% description coverage. The description compensates well by showing exact Bluebook example formats and the kinds of citations accepted. It does not exhaustively document edge-case formatting or validation rules, so it is strong but not flawless.

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 action (resolve), a specific resource (Bluebook citation string), and a specific outcome (exact section, official source link, act_id), with concrete examples. It is clear and non-tautological, but it does not explicitly distinguish itself from the sibling resolve_citation, so it stops short of a perfect 5.

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 when-to-use guidance: 'use this whenever the user gives you a citation rather than a question.' It also explains why the tool is preferable to searching. It does not formally name alternatives or list explicit exclusions, so it earns a 4 rather than a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses boolean syntax, filters, paginated results, returned fields, and even response-presentation guidance like 'Present the top results only and do not emphasize the total count.' It does not mention rate limits or auth, but for a search tool this is strong 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?

Four sentences, each earning its place: scope, syntax/filters, return format, and usage guidance. Slightly dense because it mixes invocation guidance with behavioral description, but still compact and front-loaded.

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 description covers scope, query syntax, filters, pagination behavior, and returned fields, plus explicit page-size guidance. The output schema exists, so return-value documentation is covered. Minor gaps around country_code and page semantics prevent a perfect score.

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. It explains query, page_size, court filtering, and year range, but does not explain the page parameter, the distinction between court_name and court_type, or country_code. With 8 parameters, this is useful but incomplete.

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 and resource: 'Boolean keyword search across 8M+ US federal and state court opinions.' This specifies both the action and the scope, and differentiates it from sibling tools like search_us_statutes and resolve_citation.

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 to use this tool — for keyword searching court opinions — and provides practical guidance on pageSize for conversational versus exhaustive responses. It does not explicitly name alternatives or exclusions, but the scope statements and search syntax make the intended use 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?

With no annotations provided, the description carries full behavioral disclosure. It reveals the semantic-plus-keyword search behavior, what kind of results are returned (sections with citation, hierarchy, source links), and an important cross-tool caveat that act_id should be taken from results rather than hand-built. It does not mention auth, rate limits, or pagination, but the output schema covers return shape.

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 four tightly packed sentences with no filler. The core action and scope are front-loaded, usage guidance comes second, filters and outputs third, and the act_id warning last. Every sentence earns its place and adds either selection guidance or operational detail.

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 six parameters, no annotations, and 0% parameter description coverage, the description does a solid job at the high level but leaves gaps: code, state, limit, and default behaviors are not explained. The act_id warning adds valuable cross-tool context, and the output schema covers result structure, but the description is not fully complete for correct invocation across all parameters.

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, but it only mentions two filters: 'corpusType' and 'titleNumber'. It does not explain query, limit, code, or state. It also uses camelCase names while the schema uses snake_case (corpus_type, title_number), which could create confusion. The parameter names are mostly self-explanatory, but the description does not adequately document all six 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 names the operation ('Semantic + keyword search'), the target resource ('US primary law'), and enumerates the specific corpora covered. It also differentiates from sibling tools by explicitly listing statutes, regulations, constitutions, and court rules while omitting case law, which aligns with search_legal_cases existing as a sibling.

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 direct positive guidance: 'Use for any what does the law say question.' It notes available filters (corpusType, titleNumber) and the scope of coverage. It does not explicitly name alternatives or say 'do not use for case law', but the stated corpus list implicitly excludes cases, providing enough context for an agent to choose this tool over search_legal_cases.

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

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

With no annotations, the description carries the full behavioral burden and does well by disclosing that test deliveries are not persisted, do not update the watch's last-notified timestamp, and are rate limited. It does not mention potential failures or external side effects in detail, but the provided details are substantial.

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

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

Three concise sentences, each adding distinct value: the action and purpose, the non-persistence and side-effect behavior, and the rate limit. The description is front-loaded and contains no filler.

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

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

For a single-parameter test operation, the description covers purpose, usage context, behavioral side effects, persistence caveats, and rate limiting. An output schema exists to document return values, so nothing critical is missing for an agent to call this 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%, but the description contextualizes watch_id as 'a watch's destination' and makes it clear the ID selects which watch to test. For a single self-named parameter, this is sufficient functional meaning beyond the raw 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 action ('send a synthetic notification'), a clear resource ('a watch's destination'), and the purpose ('verify signing, outbound auth and reachability'). It is clearly distinct from sibling watch tools like create_watch or list_watch_deliveries.

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 an explicit trigger for use: 'before relying on it' on a watch. It also clarifies that test deliveries will not show up in list_watch_deliveries, which helps an agent avoid confusion with that sibling tool, though it does not name alternatives or explicitly 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.

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

With no annotations, the description carries the full behavioral burden. It reveals that pausing keeps config/history and that the channel is immutable, but it does not disclose partial-update semantics, whether changing destination triggers side effects like verification, permission requirements, or consequences for existing deliveries — a significant gap for a mutation tool.

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

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

Three compact sentences with the core action first, a practical tip second, and a constraint third. No filler words; 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 simple, but zero schema coverage and absent annotations mean the description must supply more context. It fails to define update semantics (partial vs. full replacement), the role of each destination field, and the confusing reference to non-schema fields, leaving an agent uncertain about correct invocation despite the output schema being 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 0%, so the description must compensate. It maps webhook_url/email_address to 'destination' and is_active to 'active state,' but it never explains watch_id semantics, whether fields are independent, validation rules, or how to clear a field. The mention of 'signing secret' and 'outbound auth' with no corresponding parameters further muddles parameter meaning.

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 ('Change') and resource ('a watch'), and enumerates the aspects that can be changed, which distinguishes it from create/delete/list siblings. However, it mentions 'signing secret' and 'outbound auth' which are not present in the input schema, making the declared scope partially inaccurate and potentially misleading.

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 offers one concrete usage tip: setting isActive false pauses notifications while preserving config/history, and an exclusion: the channel cannot be changed. But it never names an alternative tool or explicitly states when to use update_watch instead of create/delete/test, so an agent must infer routing.

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