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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description earns credit for adding non-obvious interpretation guidance: results are evidence, not permission, and an absent answer must not be fabricated. It still omits behavioral detail such as how `limit` truncates the returned answers or what happens when a desk has no rules.

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?

Four short sentences, front-loaded with the retrieval scope and followed by behavioral guardrails; nothing is padded. The two-sentence caution is slightly repetitious in tone but each sentence carries distinct guidance.

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?

An output schema exists, so return values need not be explained, and the description covers the tool's scope and the key downstream dependency. The remaining gap is parameter-level: with 0% schema coverage, an agent gets no explanation of `deskId` or the `limit` cap on how many answers come back.

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 0% across three parameters, and the description only implicitly covers `question` ('for a customer question'). Neither `deskId` nor `limit` (default 8, max 20) is mentioned, so the description does not compensate for the schema's total lack of parameter documentation.

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 concrete verb ('Retrieve') and an explicit composite resource: approved answers for a customer question plus the desk's refund rules, commitments, and escalation limits. That bundled scope inherently separates it from the granular siblings (search_approved_answers, list_refund_rules, list_escalation_limits), so an agent can pick it without opening schemas.

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 an explicit routing rule to a named sibling: 'Call evaluate_commitment before promising a refund, feature, or timeline,' and frames the output as evidence rather than authorization. It stops short of saying when to prefer the granular list_* tools over this aggregate call, so it is clear context without full when-not coverage.

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