WearableDocs

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

With no annotations, the description carries the burden, and it discloses the content boundary (both FAQ sets, verbatim answers) and the topic coverage an agent needs to decide relevance. It is a harmless parameterless read, so no auth/destructive caveats are required, but it says nothing about result format or whether the answers are exhaustive.

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, all load-bearing: scope first, topic coverage second, routing to get_state last. No filler and the most decision-relevant content 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?

For a no-argument lookup tool with no output schema, the description conveys enough to select it and predict the content. Minor gap: it does not indicate whether results are comprehensive or how they are shaped, but nothing critical to correct invocation is absent.

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 disambiguate and no schema description to duplicate. Baseline of 4 applies; no parameter-level meaning is needed or missing.

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 specific resources (the WearableDocs FAQ and the Medical & Legal FAQ) and the topic scope (enforceability, refusing vaccines and blood, brain death, organ procurement, ignored refusals). The verb is implicit rather than stated ('Every question answered on...'), but an agent can tell this retrieves FAQ answers, and it is distinguished from get_state.

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 trigger ('Use this for a general question about how refusals work') and names the alternative plus the condition that selects it ('get_state when the question names a jurisdiction'). 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?

No annotations are supplied, so the description carries the full behavioral burden. It discloses a key behavioral constraint: the tool only returns settled prices, items with unfixed prices are omitted, and no price should be quoted for anything not returned. That is meaningful non-obvious behavior. It does not cover output shape or pagination, but with a 0-param read tool the core behavioral note is present.

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

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

Three sentences, front-loaded with the core purpose, then the settlement constraint, then the quoting rule. Every sentence adds a distinct, useful constraint; 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?

For a no-parameter read tool with no output schema, the description gives the agent enough to know what is returned and how to interpret absences. It could add a bit about return format or refresh behavior, but the essential behavioral guidance for correct use 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?

There are zero parameters, so the baseline is 4. The description does not need to describe parameter meaning, and it appropriately adds no irrelevant parameter discussion.

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: it tells the agent this tool returns what WearableDocs costs (pricing). It also distinguishes itself from the sibling get_products by explaining that unsettled/flexible prices are absent here and appear there instead.

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 says only settled prices are published and that variable-price items appear in get_products without a figure. It also gives a hard rule: never quote a price for anything not returned by this tool. This covers both when to use it and when not to quote its output.

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 implies a read-only catalog and notes each entry carries an orderability flag, but says nothing about auth requirements, caching/static nature, or the shape of the result set.

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 the product enumeration front-loaded and the usage directive last. The first clause is a sentence fragment ('What a WearableDocs code can be carried on:'), which is slightly awkward but wastes no words.

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

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

With no output schema and no parameters, the description must carry the return-value burden, and it partially does by promising a per-item orderability indicator. It stops short of describing other returned fields (name, price, ordering link), which get_pricing suggests may exist.

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 in the schema; per the baseline a 4 applies. The description correctly makes no attempt to invent 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 enumerates exactly what the tool surfaces (wallet card, bracelet, pendant, Apple Watch band, dog tags) and the availability flag per item, so an agent can distinguish it from get_pricing or get_faq. However, it never states the action explicitly ('returns the catalog of WearableDocs products'), reading more like a definition of the domain object than a tool contract.

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 closing sentence 'Use this rather than assuming anything is for sale' gives a concrete condition for invoking it and an anti-pattern to avoid. It does not, however, contrast with siblings like get_pricing, which could plausibly overlap for purchasable items.

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 document what data comes back in detail, which substitutes for the missing output schema. However, it says nothing about behavior proper: no statement that it is read-only, no error behavior for an unrecognized state, and no indication whether territories or only the 50 states 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?

Two sentences, front-loaded with the substantive content list and closed with the usage trigger; no filler. The first sentence is dense with a long clause list, but every item is meaningful returned content rather than padding.

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 one-parameter read-only lookup with no output schema and no annotations, the description supplies enough about the return payload for an agent to judge relevance. The remaining gaps (invalid-state handling, jurisdictional coverage limits) are minor for this tool's complexity.

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' parameter already documents accepted forms with an example ('Texas' or 'TX'). The description's 'in a specific state' only confirms scope and adds no format, validation, or edge-case detail beyond the schema, so baseline 3 applies.

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

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

The description states exactly what the resource is (refusal-of-anatomical-gift requirements for one US jurisdiction) and enumerates the concrete content returned: statute citation, witness rules, notary requirement, and what an unrevoked refusal bars. This is far more specific than the generic name 'get_state' suggests. It does not explicitly contrast itself with the similarly named sibling 'list_states', so it stops short of a 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?

'Use this for any question about organ donation refusal requirements in a specific state' gives a clear and unambiguous trigger condition. There are no explicit exclusions or named alternatives (e.g., 'for a list of states, use list_states'), so the routing guidance is one-sided.

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 explain what a returned item contains (state/DC name plus governing statute). It does not mention auth, caching, or whether the list is static, but for a zero-parameter read-only enumerator those gaps are 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?

Two sentences, no filler. The scope ('every US state and the District of Columbia') and returned data are front-loaded, with usage guidance following immediately.

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

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

There is no output schema, so the description must convey what comes back, and it does: jurisdiction names plus the governing statute. Combined with the explicit hand-off to get_state, nothing an agent needs to call this correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4; the description correctly implies no filtering or input is required. There is no parameter information it could add beyond that.

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

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

The description states a specific verb and resource ('List every US state and the District of Columbia') and adds the payload each entry carries (the governing refusal-of-anatomical-gift statute). It is trivially distinguishable from siblings like get_state, get_pricing, or search_site.

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 names two concrete uses ('to find which jurisdictions are covered' and 'to get the exact name to pass to get_state'), explicitly routing the agent to the sibling it complements. That is precise when-to-use guidance rather than implied context.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the return shape (titles, headings, Markdown copy address) and that it is a discovery step before answering, but it omits whether results are ranked by relevance (implied by 'best match first' in the limit schema, not the description), whether the Markdown copy is a separate fetch, and any rate or authentication behavior.

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 purpose and return value, followed by a compact usage directive. Every clause earns its place with no filler.

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

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

For a two-parameter search tool with no output schema and no annotations, the description is nearly complete: it says what to expect back, when to use it, and how queries are interpreted. The only minor gap is that it doesn't explain how to go from the returned Markdown address to actual page content.

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

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

Schema coverage is 100%, so the schema already documents both parameters in detail. The description adds meaningful search-behavior semantics—it clarifies that this is keyword search, not semantic, and that a few plain nouns work better than whole sentences—which goes beyond the schema's stopword and stemming notes.

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+resource+question framing ('Find which WearableDocs page answers a question') and explicitly states what is returned (page titles, headings, clean Markdown copy address). This clearly distinguishes it from siblings like get_faq, get_pricing, and get_state, which appear to be direct entity lookups rather than general search.

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 explicit when-to-use guidance ('Use this before answering anything about the product, the record page, evidence, engraving, pricing or health and rights'), which routes the agent toward this tool for a broad set of product questions. However, it does not name when to prefer a specific sibling (e.g., get_pricing for a direct price question) or when not to use this tool.

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