Checkbox

Get the Checkbox Elements snippet for a site

get_elements_snippet

Idempotent

Returns paste-ready Checkbox Elements markup for a site: the pinned tag (with SRI) for , the element for directly above the pay button, the publishable key, and a React usage example. The element renders the locked disclosure (it passes the checks) with an unchecked, required consent checkbox, gates the pay button, and records each consent (cons_…) in the evidence vault. Terms come from the site's billing connection unless you pass them. This creates a disclosure record (write, safe to repeat). Consents themselves are recorded by the browser, never by agents.

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": {
      "site": "<site>"
    },
    "name": "get_elements_snippet"
  }
}

Input Schema

Name	Required	Description
`plan`	No	Billing price / plan id (price_…) when the site has several.
`site`	Yes	Site id (site_…); list_sites shows them.
`price`	No	Recurring price, major units (19.99).
`amount`	No	Or minor units (1999 = $19.99).
`currency`	No	ISO currency, default "usd".
`interval`	No	Billing interval.
`cancel_url`	No	https URL where subscribers cancel online (used in generated text).
`trial_days`	No	Free-trial days (0 or absent = no trial).
`cancel_timing`	No	When a cancellation takes effect (default period_end).
`merchant_name`	No	Brand shown to subscribers, e.g. "Acme".
`interval_count`	No	Default 1; 3 + month = quarterly.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 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)."

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_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)."

First observedNov 5, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, but the description adds the missing substance: it names the side effect ("creates a disclosure record") and confirms repeat-safety, and it clarifies that consents are written by the browser, not by agents, preventing a misconception about the tool's scope. It also describes the rendered element's runtime behavior (gates the pay button, records cons_… in the evidence vault).

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 short paragraphs, front-loaded with what the caller gets, then how the element behaves, then the write semantics. Every sentence carries information; the React-example mention and the evidence-vault detail are the only mildly tangential items, but both are return-content facts the agent needs.

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 an 11-parameter tool with no output schema, the description covers what is returned, the key side effect, and the default behavior of the billing params, which is most of what an agent needs. It stops short of stating auth/permission requirements or whether the snippet can be regenerated identically (though idempotentHint covers repeat-safety).

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 sentence "Terms come from the site's billing connection unless you pass them" adds real decision-relevant meaning — it tells the agent the ten optional params are overrides of a derived default rather than required configuration. No per-parameter syntax details are added, which the schema already covers well.

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?

States a specific verb and resource — "Returns paste-ready Checkbox Elements markup for a site" — and enumerates the four artifacts returned (script tag with SRI, <checkbox-disclosure> element, publishable key, React example). An agent can tell this is a snippet generator, though it never explicitly contrasts with near neighbors like setup_checkbox or get_compliant_disclosure.

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

Usage Guidelines3/5

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

Usage context is implied rather than spelled out: the description says terms come from the site's billing connection "unless you pass them," which tells the agent when to supply plan/price params, but there is no explicit when-to-use-this-vs-alternatives guidance or prerequisite statement. The placement requirement ("directly above the pay button") is a usage hint for the output, not for the tool.

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.