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

Annotations declare readOnlyHint=false and destructiveHint=false, so the description correctly treats it as a mutating/state-creating operation. The description adds critical context beyond annotations: it must not request prohibited data (SSN, identity image, raw formation document, Mercury credentials, legal name/EIN override), it should never create a new idempotency key after a timeout, it invokes a canonical shared backend action and should trust the returned actual_tool_output, and it requires explicit user confirmation before calling. This gives the agent clear behavioral boundaries that annotations alone would not convey.

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 relatively dense and front-loaded with the core action, and it covers a lot of safety-critical guidance in a compact space. However, it is long and somewhat repetitive with appended boilerplate-style sections ('Canonicality', 'Idempotency', 'Confirmation boundary') that could be tightened or integrated more cleanly. It earns its place but is close to the edge of over-specification.

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 the complexity of an 11-parameter tool with nested objects and no output schema, the description covers the most decision-critical behaviors: preflight status check, confirmation requirement, what not to send, idempotency handling, and trusting the actual output. It does not describe the returned signup link structure or what happens after a rejected application, but it provides enough for an agent to invoke the tool correctly in most scenarios. A small gap is that the many nested parameter groups are not explained at all, so the agent must infer acceptable values from the schema alone.

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 only 9%, and the description does not enumerate the 11 parameters or explain the nested objects (about, formationDetails, businessLegalAddress, etc.). However, the description names the key required parameters (inviteEmail, beneficialOwners, founderAuthorizedDataSharing, idempotencyKey) and gives substantial semantic guidance on idempotencyKey reuse, and clarifies that founderAuthorizedDataSharing must reflect fresh founder confirmation. This partially compensates for the schema gaps, but the large nested objects remain undocumented in the description, so it does not fully compensate.

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 opening sentence states a specific verb ('Create'), the resource ('one consented Mercury partner prefill'), and the return artifact ('founder-only signup link'). This clearly distinguishes it from siblings like get_bank_onboarding_status (status check) and start_payment_route_onboarding (different onboarding domain), and the description explicitly names get_bank_onboarding_status as a prerequisite rather than confusing it with this action.

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 explicitly instructs to call get_bank_onboarding_status first, requires fresh founder confirmation before calling, specifies the prerequisite of authenticated active organization access, and states that data is loaded server-side (so the agent should not request company facts from the user). It names the alternative workflow implicitly by telling the agent when to use status checks as a precursor, and clearly states the flow ownership and not to invent idempotency keys.

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