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

Annotations only cover readOnly/destructive/openWorld hints, while the description adds substantial behavior: what must never be sent (SSN, identity images, raw documents, EIN/legal-name overrides), who may authorize, the idempotency-key reuse rule after timeouts, and the sandbox-vs-real environment warning. This is exactly the kind of context annotations cannot express.

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 core action and prerequisite are front-loaded, but the confirmation requirement is stated twice (mid-body and again in the 'Confirmation boundary' line), and the Canonicality/Idempotency/Confirmation boilerplate partially restates earlier content. Dense and informative, but not free of redundancy.

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?

For a high-stakes mutation with 11 params, nested objects, no output schema, and 0% schema description coverage, the description covers auth, prerequisites, idempotency, confirmation, data-sharing scope, and environment handling well. Remaining thinness is in field-level parameter meaning rather than in operational guidance.

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?

With 0% schema description coverage across 11 nested params, the description compensates by enumerating the data categories being shared (owner, address, business, formation, legal-name, EIN, invitation email) and adding real constraints: addresses must be Google-listed with a postal code, and SSN/EIN overrides are forbidden. It still does not explain individual fields like percentOwnership, dateOfBirth, or isPep.

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 states a specific verb and resource: 'Create one consented Mercury partner prefill and return the founder-only signup link.' It clearly distinguishes this tool from get_bank_onboarding_status and reconcile_bank_onboarding by naming the status check as a separate prerequisite step.

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 explicitly states the prerequisite ('Call get_bank_onboarding_status first'), the authorization boundary (only an active owner, founder, or cofounder), and the confirmation requirement before calling. It does not, however, address the reconcile_bank_onboarding sibling or when a caller should prefer that path, leaving one routing gap.

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