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

Annotations already cover the read-only, non-destructive, closed-world profile, and the description adds genuinely new behavior: fuzzy matching tolerates typos/word order/punctuation, miss returns `name_not_found` plus lookalikes, and results are 'candidates, not proof'. It also warns that no booking, ordering or payment happens without permission — a safety boundary the annotations do not express.

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 the core identity and the not-found path, then parameters, then the safety coda — a sensible ordering. Dense but not padded; the density is driven by the tool's fallback semantics rather than by 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 7 parameters and no output schema, the description carries the right load: matching tolerance, the failure mode, the meaning of the lookalike list, and the per-call card-shaping role of four optional parameters. The only shortfall is that what the returned card actually contains is described by reference to `list_cards` rather than stated.

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 every parameter is already documented; the description only adds that `location` orders matches by nearness while `radius_miles` bounds the nearby list, and that `intent`/`query`/`needed_by`/`deliver_to` 'shape the short card the same way as list_cards'. That cross-reference defers the actual semantics to a sibling rather than explaining them, leaving little beyond 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?

States a specific verb+resource+scope: 'One business the user NAMED, matched by its name near `location`' — a named-entity lookup rather than discovery. That distinction cleanly separates it from `search_catalog` and `get_business`, so an agent can pick correctly without opening the 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?

Gives a clear trigger (the user named a business) and the fallback path when the name is absent from the catalogue, including that the up-to-5 nearby matches are 'never presented as the business asked for'. It never explicitly says to use `search_catalog` instead when only a description is known, so the sibling routing is only half spelled out.

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