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

Annotations already declare non-readOnly, idempotent, and closed-world, and the schema documents the 24h idempotency replay. The description adds genuinely new behavioral context: payment/signing cannot happen in chat and is emailed to the customer's registered channel, and session-preservation caveats are disclosed. It stops short of auth/error or rate-limit detail, but the added context is solid.

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 critical precondition is front-loaded in the first clause, and most sentences carry actionable guidance (session fallback, credential handling, payment channel). Some phrasing is convoluted ('Stay on the same consumer-operated MCP subset'), but there is little outright waste.

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 an output schema present, return values need not be explained, and the description covers the key concerns for a bind mutation: sequencing, session vs. token fallback, confirmation inputs, and payment handling. Missing only auth-failure/error handling detail, which keeps it short of complete.

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 only 40%, so the description must carry weight on uid, preview_token, and bind_confirmed. It explains that a preserved host usually needs only uid, and that preview_token is sent together with bind_confirmed: true after confirming previewed terms and the email channel. It adds real meaning beyond the schema, though it never clarifies uid format or preview_token provenance.

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 names a specific action (continue the homeowners bind follow-up) and situates it precisely in the workflow: it only runs after homeowners_consumer_select returns ready_to_finalize. This clearly separates it from prefill/select siblings. The verb phrasing is slightly process-oriented ('bind follow-up') rather than a crisp 'binds the policy,' but the intent is unambiguous.

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?

It states the exact precondition (only after select returns ready_to_finalize), the canonical path (preserved MCP shopper session, only uid needed), and an explicit alternative for hosts that cannot preserve session state (retry with the latest intake_access_token). It also steers away from raw HTTP and from asking the shopper for credentials.

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