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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context beyond annotations: it confirms read-only behavior explicitly, notes it spends no quota, describes sequential routing behavior ('recipients whose turn has not arrived show status waiting'), and specifies required API scope ('signatures:read') plus the authentication failure behavior ('without a key, returns dashboard setup instructions'). The only minor gap is not documenting potential error responses for invalid envelope IDs.

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 a single, well-structured paragraph that front-loads the core purpose and return data. Every sentence adds distinct value: what the tool does, what it returns, when to use it (and when not to), behavioral details (sequential routing, waiting status), read-only guarantee, and authentication requirements. No wasted words.

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?

Given only one required parameter with full schema coverage, no output schema, and no nested objects, the description is remarkably complete. It covers purpose, return fields, usage context, behavioral nuances, auth scope, and edge cases (no key behavior). There is no obvious gap that would hinder an agent from correctly using this tool.

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% with one parameter (envelopeId) already well-described in the schema. The description reinforces this by mentioning that the ID comes from create_envelope. While the description doesn't add new parameter details, the schema is already complete, so the baseline of 3 applies, and the mention of the source (create_envelope) provides useful cross-tool context, justifying 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 starts with a clear verb ('Fetch') and a specific resource ('one multi-signer envelope'), then lists exactly what data is returned (recipients with sign_url, status, etc.) and the envelope's own status. It explicitly distinguishes itself from the sibling tool 'get_signature_request' by noting that tool returns no recipient list.

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 tells the agent exactly when to use this tool ('who still has not signed? after a create_envelope send'), and when to use an alternative ('get_signature_request answers that for a single standalone request and returns no recipient list'). This is exemplary contextual guidance.

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