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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: session-state preservation requirements, the token fallback path, that drafts are not resumable by email alone, and the consumer-operated subset constraint. Some mutating language ("patch the canonical umbrella_details.* count field") is ambiguous about whether this tool writes, but it is generally attributed to consumer_intake_patch.

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?

A single sprawling paragraph mixes this tool's behavior with policy that belongs to consumer_intake_patch (patching counts), homeowners vs umbrella turn rules, birthday normalization, and estimated-value formatting. The purpose is front-loaded, but the bulk is dense, hard to scan, and only partially relevant to invoking this tool.

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 described, and annotations cover safety. But the description is bloated with tangential policy while still leaving the boundary between this tool and consumer_intake_patch ambiguous, and it never clarifies what the follow-up/status result actually contains. Adequate but muddled for the complexity involved.

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 50% (uid has no schema description), so the description must compensate, and it largely does: it explains that uid alone suffices when the host preserves the session, and that intake_access_token is the fallback reusing the latest token without showing it to the shopper. What 'uid' actually is (an issued draft identifier) is only implied, so it is not fully self-contained.

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 first sentence gives a workable verb+resource ("Continue a consumer-prefill homeowners or umbrella handoff in chat"), and it does name sibling tools (consumer_intake_patch, delegated tools) to differentiate. However, the name/title ("intake_issues", "follow-up status") imply a read/reporting tool while the body describes continuing a handoff and staging reviews, leaving the core purpose fuzzy. An agent can guess the intent but not cleanly state what this tool returns or does.

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 gives concrete when-to-use and when-not guidance: prefer the preserved hidden MCP session with only uid, retry with the latest intake_access_token rather than falling back to raw HTTP or asking the shopper for credentials, and stay in the default consumer MCP subset instead of jumping to delegated tools when no operator bearer key is present. It also names alternatives (raw HTTP, delegated tools, consumer_intake_patch). It stops short of a crisp decision rule for every case.

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