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

Annotations indicate no readOnlyHint (write op), no idempotency, no destructive hint. The description adds that the tool creates a secure Stripe link, does not charge, and that payment credits appear automatically. It also mentions the post-condition (payment_status becomes credit_available) which is not in annotations, adding valuable context beyond what annotations provide. However, it doesn't mention potential failure modes or what happens if the user cancels, leaving a slight gap.

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 three sentences, concise and informative. It front-loads the primary purpose and usage condition, then explains the behavior and follow-up steps. No redundant phrasing or filler; every sentence earns its place. The tone is direct and action-oriented.

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?

The tool has an output schema and annotations, which reduces the description's burden. The description covers the trigger condition, the action, the non-charging aspect, and the follow-up verification step. It doesn't explain the full output schema (but that's provided separately) nor does it cover edge cases like what happens if payment fails. Given the output schema exists, the missing failure behavior is a minor gap, so a 4 is appropriate.

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% for both parameters (event_id and quantity) with descriptions. The description adds minimal extra meaning: it implies event_id is for the invitation being purchased and quantity relates to publish credits, but these are already explicit in the schema. The description doesn't clarify the relationship between quantity and pricing or any constraints beyond schema (e.g., max quantity per event), so it adds little beyond schema.

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 explicitly states the verb ('start checkout'), resource ('Lemonvite invitation'), and the specific use-case (when payment is required to publish and user wants to proceed). It distinguishes itself from related sibling tools like lemonvite_publish_invitation by making clear it creates a checkout link, not the actual publication. This avoids ambiguity with the publish tool.

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?

Provides explicit guidance on when to use (when payment is required and user wants to proceed) and what to do after (verify with lemonvite_get_invitation, check payment_status). It also clarifies what the tool does NOT do (does not charge the user), setting expectations clearly. No exclusion of alternatives is needed since this is a unique step in a workflow.

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