Checkbox

Check checkout disclosure text

check_disclosure

Read-onlyIdempotent

Before shipping a checkout: checks the automatic-renewal disclosure shown next to the purchase button against every applicable law (ROSCA, CA, NY, …) and returns per-check verdicts with citations plus a REPLACEMENT verified by the rules engine (disclosure_text, consent_label, button_text, drop-in html and jsx). Pass the text exactly as rendered plus the plan terms. Example: {"text":"Renews monthly at $19.99 until you cancel.","price":19.99,"interval":"month","trial_days":14,"cancel_url":"https://acme.example/account/cancel","merchant_name":"Acme","consent":{"checkbox":true,"prechecked":false}}. If verdict is fail, put replacement.jsx (React) or .html above the button, then call again with the new text, consent and placement.bold: true (it is semibold). needs_review on styling means a rendered scan must confirm.

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": {
      "text": "<text>"
    },
    "name": "check_disclosure"
  }
}

Input Schema

Name	Required	Description
`plan`	No	With site: plan name or price_…
`site`	No	site_… whose plans judge it (as verify_task)
`text`	Yes	The disclosure shown next to the purchase button, exactly as rendered.
`as_of`	No	Evaluate the law as of this date, YYYY-MM-DD (default today).
`price`	No	Recurring price, major units (19.99).
`amount`	No	Or minor units (1999 = $19.99).
`consent`	No	The consent checkbox, if the page has one. Omit when there is none.
`currency`	No	ISO currency, default "usd".
`interval`	No	Billing interval: day, week, month or year (optional with site).
`placement`	No	Where and how the disclosure is shown (defaults: above the button, same page, 14px, high contrast).
`plan_name`	No	Plan / product name, e.g. "Pro".
`brand_name`	No	Alias of merchant_name.
`cancel_url`	No	https URL where subscribers cancel online (used in generated text).
`trial_days`	No	Free-trial days (0 or absent = no trial).
`button_text`	No	Purchase button label, e.g. "Start free trial".
`intro_price`	No	Promo first-period price, major units ($8 → 8).
`cancel_timing`	No	When a cancellation takes effect (default period_end).
`intro_periods`	No	Billing periods the promo lasts (default 1).
`jurisdictions`	No	Where the business sells: "all" (default) or state codes like ["US-CA","US-NY"] ("CA" works too). Federal law is always included.
`merchant_name`	No	Brand shown to subscribers, e.g. "Acme".
`order_summary`	No	Other text next to the button (order summary), if any.
`interval_count`	No	Default 1; 3 + month = quarterly.
`intro_percent_off`	No	Or the promo as % off (coupon percent_off).

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 9, 2026

changedInput schema / properties / interval / description

Previous value: -"Billing interval: day, week, month or year."New value: +"Billing interval: day, week, month or year (optional with site)."

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"
+}

changedInput schema / required

Previous value: -[
-  "text",
-  "interval"
-]New value: +[
+  "text"
+]

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

Changed6 schema fields changedNov 9, 2026

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

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

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

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

changedInput schema / properties / interval_count / description

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

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

Changed3 schema fields changedNov 8, 2026

addedInput schema / properties / intro_percent_off

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

addedInput schema / properties / intro_periods

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

addedInput schema / properties / intro_price

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

First observedNov 5, 2026

TDQS

A3.9/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 and closed-world, so the safety profile is covered. The description goes beyond them by disclosing the response shape (per-check verdicts with citations, plus disclosure_text, consent_label, button_text, html and jsx) even though no output schema exists, and by flagging the fail/needs_review verdict semantics. It does not state whether a pass verdict also returns a replacement or how many jurisdictions/citations come back, which caps it at 4.

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

Conciseness3/5

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

Purpose, example and remediation loop are front-loaded in that order, and every block carries information. However the prose is compressed to the point of ambiguity — 'placement.bold: true (it is semibold)' is unclear about whether it is an instruction or a description of the replacement — and the run-on final paragraph mixes verdict handling with styling caveats.

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?

For a 23-parameter tool with nested objects and no output schema, the description does the heavy lifting: it describes the return contents, the verdict vocabulary, and the iterate-until-pass workflow. Gaps remain around the full verdict set and whether replacement assets are always present, but an agent has enough to call this correctly on the first attempt.

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?

With 23 parameters at 100% schema coverage the baseline is 3, and the description earns extra by supplying a full worked payload showing which fields matter together (text, price, interval, trial_days, cancel_url, merchant_name, consent) and by insisting the text be passed 'exactly as rendered'. That framing — exact rendering, plus plan terms — adds meaning the individual schema field descriptions do not convey. It still leaves most of the 23 parameters (intro pricing, placement, order_summary, as_of) to the schema.

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

Purpose4/5

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

The description states a specific verb and resource — checks the automatic-renewal disclosure shown next to the purchase button against named regimes (ROSCA, CA, NY) — and describes the output as per-check verdicts with citations plus a rules-engine-verified replacement. That is far more than a restatement of the name. It does not name the obvious sibling it differs from (get_compliant_disclosure), so an agent must infer the split between 'check my existing text' and 'give me a compliant one'.

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?

Timing is explicit ('Before shipping a checkout') and there is a concrete remediation loop: on a fail verdict, place replacement.jsx/.html above the button and call again with the new text, consent and placement.bold: true. The needs_review path is also routed ('a rendered scan must confirm'). No exclusion or explicit alternative-versus-sibling guidance is given, which keeps it from a 5.

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.