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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real value by enumerating the four content blocks returned (quote, duration, survey day, payment) — meaningful disclosure given there is no output schema. It stops short of saying whether the response is static marketing copy or varies by service slug beyond the added steps.

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, content scoping first, parameter guidance second — appropriately sized with no filler. The opening clause 'What happens when you ask Roome Land Surveying for a survey' is slightly padded but frames the domain usefully.

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 single optional-parameter read tool with annotations and no output schema, the description covers content and parameter effect but omits sibling routing guidance (when which_survey or request_quote is the better call) and says nothing about response shape or length. Adequate, with noticeable gaps.

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%, and the description still contributes beyond it: it explains the effect of supplying the slug (adds 'what you receive' and step-by-step for that service), not just its type. It does not repeat the list_services provenance that the schema already provides.

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 makes clear this tool returns the 'what to expect' narrative for a survey engagement — the free quote, survey duration, survey day, and payment — which is specific content an agent can distinguish from list_services or request_quote. It lacks an explicit action verb like 'get/returns', so purpose is inferred from the enumeration rather than stated outright.

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 is only implied: 'Give a service slug to add what you receive and the steps for that survey' tells how to widen the response, but never says when to call this versus which_survey or contact_details. There are no exclusions or prerequisites stated.

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