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

Annotations only say readOnlyHint=false, destructiveHint=false, openWorldHint=true; the description goes well beyond by disclosing that it legally accepts Terms of Service on the user's behalf, that it creates a real Stripe checkout, the refusal code, and the prerequisite gate. It also tells the agent exactly how to quote the returned pricing fields (verbatim, never 'charged today'), which is behavioral context annotations cannot carry.

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?

Front-loaded with the action and the safety gate, then the return-field quoting rules and the refusal condition — all operationally necessary. The Terms of Service link and the 'show and ask the user' instruction are repeated twice, minor redundancy in an otherwise dense description.

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?

Covers preprequisites, consent gating, refusal behavior, and how to use each returned field, so an agent can act correctly without further lookup. Return-value handling is spelled out even though an output schema exists, which is appropriate for a payment-related side effect.

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%, so the baseline is 3; the description adds operational meaning for termsAccepted by tying it to a user-confirmation workflow rather than just a boolean flag. It adds nothing for context/llm_model, but those are analytics-only and already self-documented.

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?

States a specific action chain: accepts the Terms of Service on the user's behalf and creates the Stripe checkout for the formation, plus names the company being paid for. It is clearly separable from siblings by naming verify_payment for the returned session ID and start_formation as the prerequisite.

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?

Gives an explicit gating workflow: show the ToS link, ask the user, and only call with {termsAccepted: true} after they say yes. It also states the exact refusal condition (PRECONDITIONS_NOT_MET until start_formation has saved name, country, and company name), leaving nothing to inference.

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