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

Adds context about the irreversible advancement to filing and the necessity of a successful result before proceeding. Does not contradict the destructiveHint annotation, and provides clear failure-handling instructions. However, it does not elaborate on exactly what 'advances' implies (e.g., irreversible state change), so it stops short of fully disclosing side effects.

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?

Four sentences, each earning its place: the first states the core function, the second gives the typical alternative, the third warns about user claims, and the fourth prescribes failure behavior. No redundant phrases.

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?

Fully explains when and how to invoke, along with success/failure behavior, and the output schema exists to cover return values. The only missing piece is parameter guidance, but the tool's complexity is moderate and the description covers the main decision logic.

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?

The description does not address the parameters; only formationId is described in the schema, while stripeSessionId and paymentConfirmed remain undocumented. Given schema coverage is only 33%, the description should compensate but does not.

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?

Clearly states its function: verifying with Stripe that payment completed and advancing the formation to filing on success. This verb+resource combination distinguishes it from other formation tools like formation_get_payment_link or formation_purchase_formation.

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?

Explicitly states when to use: only if the user explicitly returns and says they have paid, while noting the usual webhook auto-confirmation makes it generally unnecessary. It also provides a clear exclusion: 'A user saying they paid is NOT proof'.

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