Checkbox

Check a checkout / pricing page (HTML or URL)

check_page_html

Read-onlyIdempotent

Checks a whole checkout or pricing page: finds the purchase button, the renewal disclosure, consent checkboxes and terms/cancel links, and evaluates them. Send html = the RENDERED page (after JavaScript; for React/Next pages, render it or paste the server output) — this is how to check a page before deploying. Or send url to fetch a live public page (live mode on an activated account only; test keys must send html). Static HTML cannot measure styling, so placement/styling passes come back as needs_review until a scan confirms; failures are real. When it fails, replacement holds verified drop-in markup.

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": "check_page_html"
  }
}

Input Schema

Name	Required	Description
`url`	No	Live public page URL to fetch instead (live, activated accounts).
`html`	No	Rendered checkout page HTML. Give html or url.
`site`	No	Your site_…: judge it as verify_task does (the site's Stripe-checked plans).
`as_of`	No	Evaluate the law as of this date, YYYY-MM-DD (default today).
`plans`	No	Multi-plan pricing page: EVERY plan it sells (price, interval, trial_days each). Each plan card is judged against its own plan; plan_replacements gives each plan its own markup for its own button.
`terms`	No	The plan sold on the page. merchant_name / cancel_url alone are fine (no price compared).
`page_kind`	No	Default checkout.
`checkout_type`	No	Where shoppers pay (default: inferred).
`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
```

Changed7 schema fields changedNov 9, 2026

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

Changed2 schema fields changedNov 8, 2026

addedInput schema / properties / site

Added value: +{
+  "description": "Your site_…: judge it as verify_task does (the site's Stripe-checked plans).",
+  "maxLength": 100,
+  "type": "string"
+}

changedInput schema / properties / terms / description

Previous value: -"The plan sold on the page (helps judge price / interval statements). merchant_name / cancel_url alone are fine (no price compared)."New value: +"The plan sold on the page. merchant_name / cancel_url alone are fine (no price compared)."

Changed1 schema field changedNov 8, 2026

addedInput schema / properties / checkout_type

Added value: +{
+  "description": "Where shoppers pay (default: inferred).",
+  "enum": [
+    "own_page",
+    "stripe_checkout",
+    "payment_link"
+  ],
+  "type": "string"
+}

Changed4 schema fields changedNov 8, 2026

removedInput schema / properties / plans / items / $ref
```
Removed value: -"#/properties/terms"
```
addedInput schema / properties / plans / items / additionalProperties
```
Added value: +false
```

addedInput schema / properties / plans / items / properties

Added value: +{
+  "amount": {
+    "$ref": "#/properties/terms/properties/amount"
+  },
+  "cancel_timing": {
+    "$ref": "#/properties/terms/properties/cancel_timing"
+  },
+  "cancel_url": {
+    "$ref": "#/properties/terms/properties/cancel_url"
+  },
+  "currency": {
+    "$ref": "#/properties/terms/properties/currency"
+  },
+  "interval": {
+    "$ref": "#/properties/terms/properties/interval"
+  },
+  "interval_count": {
+    "$ref": "#/properties/terms/properties/interval_count"
+  },
+  "intro_percent_off": {
+    "$ref": "#/properties/terms/properties/intro_percent_off"
+  },
+  "intro_periods": {
+    "$ref": "#/properties/terms/properties/intro_periods"
+  },
+  "intro_price": {
+    "$ref": "#/properties/terms/properties/intro_price"
+  },
+  "merchant_name": {
+    "$ref": "#/properties/terms/properties/merchant_name"
+  },
+  "plan_name": {
+    "$ref": "#/properties/terms/properties/plan_name"
+  },
+  "price": {
+    "$ref": "#/properties/terms/properties/price"
+  },
+  "trial_days": {
+    "$ref": "#/properties/terms/properties/trial_days"
+  }
+}

addedInput schema / properties / plans / items / type
```
Added value: +"object"
```

Changed3 schema fields changedNov 8, 2026

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

Changed2 schema fields changedNov 8, 2026

addedInput schema / properties / plans

Added value: +{
+  "description": "Multi-plan pricing page: EVERY plan it sells (price, interval, trial_days each). Each plan card is judged against its own plan; plan_replacements gives each plan its own markup for its own button.",
+  "items": {
+    "$ref": "#/properties/terms"
+  },
+  "maxItems": 20,
+  "type": "array"
+}

changedInput schema / properties / terms / description

Previous value: -"The plan sold on the page (helps judge price / interval statements)."New value: +"The plan sold on the page (helps judge price / interval statements). merchant_name / cancel_url alone are fine (no price compared)."

First observedNov 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds genuinely non-obvious behavior: static HTML cannot measure styling, so placement/styling results come back as needs_review while failures are real, and failures include verified drop-in replacement markup. That is useful beyond the annotations; it still does not say how findings are scored or what pagination/limits apply in live mode.

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?

Three sentences, front-loaded with the action and its scope, then the two input paths, then the result caveats. Dense but every sentence carries information; the nested parentheticals add mild reading friction but no wasted claims.

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

Completeness3/5

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

For a 9-parameter tool with nested plans/terms objects and no output schema, the description leaves the response shape largely implicit — an agent knows failures and needs_review passes exist but not how they are structured or what live-mode fetch errors look like. The input-side guidance is strong, so the gap is moderate rather than severe.

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

Parameters5/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, but the description exceeds it by clarifying that html must be the RENDERED page (post-JavaScript, render React/Next pages or paste server output) and that url carries live-mode account restrictions. It also binds `site` to verify_task semantics, adding meaning the schema only gestures at.

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 opening sentence gives a specific verb and resource (checks a whole checkout or pricing page) plus the concrete artifacts it inspects: purchase button, renewal disclosure, consent checkboxes, terms/cancel links. It is clearly distinct from data-fetch siblings, but it never explicitly contrasts itself with close neighbors like check_disclosure, run_scan, or verify_site, so the agent must infer the boundary.

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?

It states two concrete input modes and the condition selecting each: send html for rendered pages (the pre-deploy check), or send url for a live public page, with the constraint that live mode needs an activated account and test keys must send html. That is real when/when-not guidance, though it stops short of naming alternative tools for adjacent tasks.

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.