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

Annotations cover read-only, idempotent, non-destructive. The description adds substantial context beyond those: it runs fully locally with no network calls and no authentication, it is a point-in-time snapshot with an always-current hosted twin, and it imposes a data-sensitivity contract ('never send patient information, claim documents, clinic credentials or booking requests'). This safety framing is exactly the kind of behavioral disclosure that annotations alone do not convey.

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?

Though long, every sentence earns its place: purpose, content scope, usage constraints, return format, snapshot caveat, hosted twin, execution model, and safety contract are each distinct and non-redundant. The high-level purpose is front-loaded before the supporting detail, and the safety constraints are positioned last with a clear warning nature. There is zero filler or repetition of annotation content.

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

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

For a search tool with an output schema, the description is fully sufficient: it explains the relevance ordering and score semantics ('0-1 relative to the best match'), specifies the empty-list meaning, flags the snapshot-versus-live-site distinction, and defines the safety envelope. Even though an output schema exists, the description voluntarily clarifies return-value semantics, which removes any ambiguity about how to interpret results. Nothing an agent needs to call and use it 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?

Schema description coverage is 100% — both `query` and `max_num_results` have detailed schema descriptions including the 3-15 word recommendation and default/maximum values. The description largely reinforces the schema's 'one topic per call' advice rather than adding new parameter-level meaning. It does clarify the return structure (chunks with url/title/score/text and relevance ordering), but that is output semantics more than parameter semantics, so the high-coverage baseline of 3 is appropriate.

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 — 'Keyword (BM25) search over a bundled snapshot of vascue.io's public pages' — and enumerates the exact content domains covered (guides, clinic products, integrations, security/compliance, case studies, pricing, blog). This is far beyond a tautology; an agent knows precisely what content the tool can reach and that it operates over a snapshot, not the live site. No siblings exist, so the specificity of the resource alone distinguishes it cleanly.

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

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

Usage context is explicit: 'Use it to answer questions about what Vascue offers, how its products work and what it has published,' with operational constraints — 'One topic per call; cite the returned page URL for every excerpt you use.' It also states clear negative capabilities ('It cannot book appointments or look up clinic data') and behavior on empty results ('say so rather than guessing'). Since there are no sibling tools to route among, this fully satisfies the when/when-not guidance dimension.

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