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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds a key behavioral caveat: the URL is for the customer to open, and the agent must not open/fetch/follow it. This goes beyond annotations and is critical for safe correct use. No contradiction with annotations.

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?

The description is two concise sentences, front-loaded with the core function, followed by a critical usage caution and a usage trigger. Every sentence earns its place with no redundancy. It is appropriately sized for the tool's simplicity.

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?

The tool has an output schema, so return values are already defined externally. The description covers purpose, usage context, and the critical behavior of not opening the URL, making it complete for the tool's complexity. No gaps noted.

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% for both parameters (slug and offer_id), so the schema already documents them. The description adds context by tying offer_id to get_quote output and explaining the prerequisite, which slightly enriches parameter meaning beyond the schema. Baseline is 3; the added context justifies a 4.

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 clearly states the tool returns a plain-text summary of a priced offer plus a URL, with a specific verb (returns) and resource (priced offer summary/URL). It distinguishes itself from siblings by explicitly mentioning it is for customer self-service handoff and directing the agent not to open the URL, which is unique among sibling tools.

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?

The description gives explicit usage context: 'Use this once get_quote or a booking flow has produced an offer_id and the user is ready to review or continue with a priced offer.' It also states a clear prohibition: 'do not open, fetch, or follow it yourself,' preventing misuse. This is direct and actionable.

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