Checkbox

Suggest conversion improvements that keep the checks passing

suggest_improvements

Read-onlyIdempotent

OPTIONAL, after compliance: concrete ways to make the checkout page, Stripe Checkout, lifecycle emails and the cancellation flow convert or retain better WITHOUT breaking automatic-renewal laws. Deterministic library; every after-example was run through Checkbox's own checks for the merchant's states before it is offered. Each suggestion gives apply.where + apply.content (the exact copy, Stripe JSON patch or flow change to make), apply.instructions, preconditions that must be true (never apply one whose precondition is false), and guardrails with catalog requirement ids (e.g. California / Colorado click-to-cancel next to any save offer, Minnesota ask-first). Never invent figures or add urgency, pre-checked boxes or obstacles. With a site id (or one site in this mode): suggestions from what Checkbox observed. Or send the copy you are writing: terms + any of disclosure, page_html, stripe_checkout_session_params, emails, cancellation_flow (as in the check_* tools). Surfaces whose compliance checks fail are held: fix them first (get_compliance_plan). Suggestions never block and never count toward compliance. After applying one, re-run the check named in verification.operation_id on the real copy.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

Name	Required	Description
`site`	No	Site id (site_…). Optional when the account has exactly one site in this mode; list_sites shows them.
`as_of`	No	Evaluate the law as of this date, YYYY-MM-DD (default today).
`terms`	No	The plan sold (price or amount, interval, trial_days, merchant_name, cancel_url). Required with disclosure or emails.
`emails`	No	Lifecycle emails (as in check_email).
`surfaces`	No	Only these surfaces.
`page_html`	No	Rendered checkout page HTML (as in check_page_html).
`disclosure`	No	Your own checkout (as in check_disclosure, plan terms in terms).
`other_plans`	No	Other plans you sell (enables cheaper-plan / plan-choice suggestions).
`jurisdictions`	No	Where the business sells: "all" (default) or state codes like ["US-CA","US-NY"] ("CA" works too). Federal law is always included.
`trial_reminders`	No	You send a trial-ending reminder to every trial subscriber.
`cancellation_flow`	No	Your cancellation flow, one entry per screen from the account page to the confirmation.
`stripe_checkout_session_params`	No	Exactly what your code passes to stripe.checkout.sessions.create.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedNov 9, 2026

addedInput schema / properties / other_plans / items / properties / brand_name
```
Added value: +{
+  "$ref": "#/properties/terms/properties/brand_name"
+}
```

changedInput schema / properties / terms / 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 / terms / properties / brand_name

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

changedInput schema / properties / terms / 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 / terms / properties / interval / description

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

changedInput schema / properties / terms / properties / interval_count / description

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

changedInput schema / properties / terms / 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)."

Changed6 schema fields changedNov 8, 2026

addedInput schema / properties / other_plans / items / properties / intro_percent_off
```
Added value: +{
+  "$ref": "#/properties/terms/properties/intro_percent_off"
+}
```
addedInput schema / properties / other_plans / items / properties / intro_periods
```
Added value: +{
+  "$ref": "#/properties/terms/properties/intro_periods"
+}
```
addedInput schema / properties / other_plans / items / properties / intro_price
```
Added value: +{
+  "$ref": "#/properties/terms/properties/intro_price"
+}
```

addedInput schema / properties / terms / properties / intro_percent_off

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

addedInput schema / properties / terms / properties / intro_periods

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

addedInput schema / properties / terms / properties / intro_price

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

First observedNov 5, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world, so the bar is lower — yet the description adds substantial context: a deterministic library, every after-example pre-validated against the merchant's states, precondition semantics ('never apply one whose precondition is false'), and prohibitions on invented figures, urgency, pre-checked boxes or obstacles. It stops short of describing result ordering or volume of suggestions, but behavior is well covered beyond annotations.

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?

Front-loaded with the optionality and purpose, then structured into what a suggestion contains, the guardrails, the two input modes, and the held-surface rule. Dense but nearly every sentence carries operational information; the long enumerations of field names make it heavier than strictly necessary.

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 and 12 parameters including nested objects, the description does the work of describing the return shape (apply.where, apply.content, apply.instructions, preconditions, guardrails with requirement ids) and the follow-up step (re-run verification.operation_id). Remaining gaps are minor, e.g. how many suggestions come back or how held surfaces are reported.

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 coverage is 100%, so the baseline is 3; the description earns above that by explaining the mode selection (site id, or one site in this mode), which copy fields pair with which checks, and how surfaces/jurisdictions gate the result. It adds meaning rather than restating field text.

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 (suggest conversion/retention improvements across checkout page, Stripe Checkout, lifecycle emails, cancellation flow) with the constraint 'WITHOUT breaking automatic-renewal laws'. It explicitly frames itself as separate from the check_* tools and get_compliance_plan, so an agent can distinguish it from all siblings.

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

Usage Guidelines5/5

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

Gives explicit sequencing ('OPTIONAL, after compliance'), an exclusion rule ('Surfaces whose compliance checks fail are held: fix them first (get_compliance_plan)'), and two alternative input modes (site id vs. pasting copy as in the check_* tools). It also states the tool never blocks and never counts toward compliance, which tells the agent when not to rely on it.

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.