Checkbox

Check Stripe Checkout Session params (returns corrected params)

check_stripe_checkout_session

Read-onlyIdempotent

Before shipping Stripe Checkout code: pass, as params, EXACTLY the object your code passes to stripe.checkout.sessions.create (mode "subscription"). Checkbox evaluates it against automatic-renewal laws and returns correction.corrected_params — the full params with the fix applied, ready to paste — plus an RFC 6902 JSON patch and before/after verification per check. With a Price id (price_…) in line_items, pass site (its plans are used) or merchant { price, interval, trial_days, merchant_name, cancel_url }. Note: Stripe styles custom_text itself, so "clear and conspicuous" stays needs_review here; the plan shows it as a note, never a fix.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "params": "<params>"
    },
    "name": "check_stripe_checkout_session"
  }
}

Input Schema

Name	Required	Description
`plan`	No	With site: plan name or price_…
`site`	No	site_… whose plans judge it (as verify_task)
`as_of`	No	Evaluate the law as of this date, YYYY-MM-DD (default today).
`params`	Yes	The Checkout Session params object, e.g. {"mode":"subscription","line_items":[{"price":"price_123","quantity":1}],"success_url":"https://acme.example/welcome"}.
`merchant`	No	What the params do not say: merchant_name, cancel_url, and price/interval when line_items use a Price id.
`jurisdictions`	No	Where the business sells: "all" (default) or state codes like ["US-CA","US-NY"] ("CA" works too). Federal law is always included.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026
- changedInput schema / additionalProperties
```
Previous value: -falseNew value: +true
```

Changed6 schema fields changedNov 9, 2026

changedInput schema / properties / merchant / properties / amount / description

Previous value: -"Recurring price in MINOR units, Stripe style: 1999 = $19.99."New value: +"Or minor units (1999 = $19.99)."

addedInput schema / properties / merchant / properties / brand_name

Added value: +{
+  "description": "Alias of merchant_name.",
+  "maxLength": 200,
+  "type": "string"
+}

changedInput schema / properties / merchant / properties / cancel_url / description

Previous value: -"https URL where subscribers cancel online. Strongly recommended: generated text uses it."New value: +"https URL where subscribers cancel online (used in generated text)."

changedInput schema / properties / merchant / properties / interval / description

Previous value: -"Billing interval: \"day\", \"week\", \"month\" or \"year\"."New value: +"Billing interval: day, week, month or year."

changedInput schema / properties / merchant / properties / interval_count / description

Previous value: -"Intervals between charges (default 1; 3 + month = quarterly)."New value: +"Default 1; 3 + month = quarterly."

changedInput schema / properties / merchant / properties / price / description

Previous value: -"Recurring price in MAJOR units, e.g. 19.99. Or give amount."New value: +"Recurring price, major units (19.99)."

Changed2 schema fields changedNov 8, 2026

addedInput schema / properties / plan

Added value: +{
+  "description": "With site: plan name or price_…",
+  "maxLength": 200,
+  "type": "string"
+}

addedInput schema / properties / site

Added value: +{
+  "description": "site_… whose plans judge it (as verify_task)",
+  "maxLength": 100,
+  "type": "string"
+}

Changed3 schema fields changedNov 8, 2026

addedInput schema / properties / merchant / properties / intro_percent_off

Added value: +{
+  "description": "Or the promo as % off (coupon percent_off).",
+  "exclusiveMaximum": 100,
+  "exclusiveMinimum": 0,
+  "type": "number"
+}

addedInput schema / properties / merchant / properties / intro_periods

Added value: +{
+  "description": "Billing periods the promo lasts (default 1).",
+  "maximum": 36,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / merchant / properties / intro_price

Added value: +{
+  "description": "Promo first-period price, major units ($8 → 8).",
+  "exclusiveMinimum": 0,
+  "type": "number"
+}

First observedNov 5, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, and the description adds real value on top: it names the returned artifacts (corrected_params, an RFC 6902 JSON patch, before/after verification per check) and discloses a limitation that custom_text stays needs_review rather than being fixed. It still doesn't describe failure/error behavior when params are malformed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two front-loaded sentences plus a short caveat note, with the prerequisite ('Before shipping') leading and the fallback input rule second. Dense but each clause carries information; the nested parentheses in the first sentence slightly reduce readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly shoulders the burden of explaining returns (corrected params, patch, per-check verification). For a 6-parameter tool with a nested merchant object it gives an agent enough to call it and interpret the result, though it doesn't cover error paths.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds genuine semantic guidance beyond the schema: params must be the exact object passed to Stripe, and site or merchant is required when line_items use a price_… id. That relational constraint between parameters is not obvious from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: it evaluates the exact object passed to stripe.checkout.sessions.create against automatic-renewal laws and returns corrected params. The phrase 'Before shipping Stripe Checkout code' plus the named return artifact (correction.corrected_params) makes the tool unmistakable among siblings like check_disclosure or check_page_html.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear when-to-use framing ('Before shipping Stripe Checkout code') and a concrete branching rule: with a Price id in line_items, supply site or merchant instead. It does not name alternative tools or state when not to use it, so it stops short of full alternative routing.

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

All Checkbox tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.