WearableDocs

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

Annotations already declare read-only, idempotent, and closed-world, so the safety profile is covered. The description goes beyond them by disclosing that the whole set returns in one call, that there is nothing to filter by, and that re-calling is unnecessary — genuine behavioral context not present in the annotations. It does not discuss auth or rate limits, but those are minor for a static read.

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

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

Front-loaded with what the tool returns and its scope, then the routing rules — a sensible order. It is somewhat dense in the middle (field-by-field return description plus a long topic list), but every sentence carries information the agent needs. Minor trimming of the topic enumeration would tighten it without loss of correctness.

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?

No output schema exists, and the description compensates by naming the returned collection and its `question`, `answer`, and `page` fields. Combined with the explicit when-to-use routing and the no-argument note, an agent has everything needed to call this correctly and interpret the result.

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

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

The tool takes zero parameters, so the baseline is 4. The description reinforces this by stating there is nothing to filter by, which correctly sets the agent's expectation that no arguments can narrow the result set.

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+resource (read the FAQ) and defines the exact corpus: every question answered on the WearableDocs FAQ and the Medical & Legal FAQ, with the topical scope spelled out (enforceability, refusing vaccines and blood, brain death, organ procurement). It clearly distinguishes itself from get_state and search_site by naming both as different tools for different questions.

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 explicit routing rules: use this for a general question about how refusals work, use get_state when the question names a jurisdiction, and use search_site for topics these questions do not reach. It also tells the agent what to do with the result (pick the closest question from the list) and explicitly says not to call again, which is actionable usage guidance.

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

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

Annotations already establish readOnly/idempotent/non-destructive, so the bar is lower; the description adds genuinely useful context beyond them: prices are in US cents and dollars, they reflect what checkout actually charges, and only settled (non-provisional) prices are exposed. It does not cover pagination or response shape, but the core behavioral caveat about not inferring prices is valuable.

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 doing work: what is returned, the units and authoritative source, and the anti-inference guardrail. The core content 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 no parameters and no output schema, the description carries the full burden of describing the return payload, and it does so by naming each price category. An agent has everything needed to call it and interpret the results.

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 takes zero parameters, so the baseline is 4 by rule. The description correctly implies a parameterless, whole-catalog read, adding no misleading parameter expectations.

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 resource ('Every WearableDocs price') and enumerates exactly what is returned: yearly subscription for the first and each additional household member, one-time wearable costs, and the printed wallet card. This scope statement, plus the caveat about only settled prices, clearly separates it from the product-listing sibling get_products.

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

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

Gives an explicit exclusion rule: 'never quote a price for anything this tool does not return, and never infer one from a product name,' which tells the agent when NOT to rely on it. It stops short of naming a specific alternative tool for cases where a price is missing, so it falls just short of full 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?

Annotations already declare readOnly/idempotent/non-destructive and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral guidance not in structured data: read the `purchasable` flag rather than assuming, and direct buyers to the `url`. It stops short of describing error behavior, but for a static catalog read that is minor.

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 catalog enumeration comes first, then usage/routing, then return shape — well front-loaded. It is slightly verbose and prose-heavy ('the things a record code can be carried on'), but no sentence is truly wasted.

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

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

With no output schema in play, the description must carry the return contract, and it does — key, name, description, price, `purchasable`, `url`, plus what `url` points to. Nothing an agent needs to call and interpret this tool 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?

There are zero input parameters, so the baseline is 4 and there is no parameter semantics to clarify. The description instead spends its words on the returned fields, which is the right trade-off for a no-arg 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 names the resource (the WearableDocs product line) and enumerates its members (wallet card, tag pendant, coin pendant, coin bracelet, bangle bracelet), so an agent knows exactly what a call yields. It also implicitly separates itself from get_pricing, which covers figures only.

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?

Explicit routing: 'Use this to answer what a WearableDocs code can be worn on, or which shape suits someone; use get_pricing for the figures alone and for the subscription.' The when-to-use condition and the named alternative are both stated, leaving nothing to inference.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description could coast—but instead it discloses the return shape (citation, summary, facts list), coverage (50 states + DC), the special behavior of four 1968-act states ('facts report none', do not report witness/notary), and the exact error behavior for bad input.

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?

Purpose and routing are front-loaded, and the detailed facts-list enumeration plus the four-state caveat are dense but earn their place given there is no output schema. It is a touch long, but no sentence is filler.

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

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

With no output schema, the description fully carries return-value burden and pre-empts the biggest trap—misreporting witness/notary requirements for DE, FL, NY, PA. An agent can call this correctly and interpret the result without any other source.

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 the single 'state' param already documents that a name or two-letter postal code is accepted with an example. The description only adds that an invalid value errors with an enumeration of accepted codes, which is marginal beyond the schema, so the baseline 3 applies.

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

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

States a specific resource and scope: what one US jurisdiction requires to refuse an anatomical gift. It distinguishes itself from the singular/plural siblings by telling the agent to use this one for a question naming a state, and explicitly points to get_faq for the general case.

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 this for any question naming a state; use get_faq for a general one" gives an explicit selection rule plus the alternative to use otherwise. It also anticipates the error case (unknown state) so the agent knows the failure mode rather than discovering it at call time.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds substantive value beyond that by disclosing what each record actually contains (the governing statute per jurisdiction), which is not derivable from 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 tight sentences with no filler: the first defines the returned content, the second defines the action to take with it. Front-loaded and waste-free.

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 parameterless enumeration tool with no output schema, the description covers what is listed and why. It does not describe the response shape (e.g. how the statute is represented per state), but with no output schema and no inputs there is little an agent still needs.

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 takes zero parameters, so there is nothing to document and the baseline is 4. The description correctly avoids inventing filter options and instead directs the agent to get_state for narrowing.

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

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

States a specific verb and resource ('List every US state and the District of Columbia') plus the payload content ('the statute that governs a refusal of anatomical gift there'), making its scope unmistakably distinct from the sibling get_state, which returns a single jurisdiction.

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 both use cases (discover which jurisdictions are covered, or obtain the exact name to pass to get_state) and routes the agent to the correct sibling for per-state detail. Nothing is left to inference.

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

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

Annotations already cover readOnly/idempotent/non-destructive, but the description goes further: it describes the return shape (matches, best first, with url/markdown/title/headings/excerpt), states that matches are pointers rather than answers and must be fetched, and clarifies empty results are not errors. That is substantive behavioral context beyond 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?

Dense but front-loaded: what it does, what it returns, the fetch-before-answering caveat, the empty-result behavior, then the routing rules. Nearly every clause earns its place, though the coverage list of topic areas is slightly long.

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

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

With no output schema, the description carries the return-value burden and does so completely: field names, ordering, and the crucial instruction to fetch the markdown copy before answering. Error semantics and sibling routing are both covered for a two-parameter search tool.

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 both parameters are already fully documented in the schema, including the stemmed keyword-matching behavior, the two-character cutoff and the limit cap. The description reinforces the keyword-not-semantic point with its own examples but adds no syntax or format information the schema lacks, so the baseline 3 applies.

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

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

States a specific verb+resource ('Find which WearableDocs page answers a question, by keyword') and immediately distinguishes itself from siblings by naming get_state, get_faq and get_pricing with the conditions that route to each. An agent can select this tool without opening any schema.

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?

Explicit when-to-use ('anything about the product, the record page, evidence, engraving, the health and rights articles or the comparison pages') plus three named alternatives with the precise question type each handles. It also covers the failure case: no match is an empty list, retry with fewer plainer words.

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