Create a Stripe checkout session for card payments using a checkout link or session token. Supports optional email, amount, promo code, and embedded or redirect checkout.
Create a Stripe checkout session for card payments.
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| embed | No | Embedded session rather than a redirect. | |
| token | Yes | The checkout link or session token being paid. | |
| amount | No | Only for an open-amount link. | |
| promo_code | No |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden for a tool that creates an external payment resource. It doesn't disclose what is returned (session URL or token), whether the call is idempotent, what auth/API key is needed, or how embed vs redirect changes behavior. Only the card-payment scope is added beyond the schema.
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?
A single front-loaded sentence with no filler, which is structurally clean. The terseness comes at the cost of the missing guidance, so it reads as under-specified rather than optimally concise.
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?
A payment-session creation tool with no annotations, no output schema, and 40% of parameters undocumented leaves the agent without return-value, auth, or failure context. The description should carry this load but does not.
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 60%: token, embed, and amount are documented in the schema, while email and promo_code are bare, and the description adds no parameter meaning at all. It does not explain that token is the checkout link being paid or clarify amount's open-amount restriction, so it fails to compensate for the coverage gap.
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 verb and resource (create a Stripe checkout session) plus a scope qualifier (for card payments), which helps separate it from create_paypal_order and create_checkout_session. It never explicitly names a sibling, so the differentiation is implicit rather than stated.
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 gives no when-to-use guidance, no prerequisites, and no alternatives, despite the sibling list containing near-neighbors like create_checkout_session, create_paypal_order, and create_mobile_money_payment. An agent must guess why it would pick Stripe/card over the other payment-creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.