Every question answered on the WearableDocs FAQ and the Medical & Legal FAQ, in the words they are answered in. Covers enforceability, refusing vaccines and blood, brain death, organ procurement practice, and what happens if a refusal is ignored. Use this for a general question about how refusals work, and get_state when the question names a jurisdiction.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
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.
Add one secure layer between your agents and this server.