Checkbox

Check a subscription lifecycle email

check_email

Read-onlyIdempotent

Checks an acknowledgment, trial reminder, renewal reminder, price-change, annual-terms or cancellation-confirmation email against the laws that require it, and returns a template that passes the checks (subject, text, html with merge tags), verified by the rules engine, plus required_by (which laws make this email mandatory for this plan). Example: {"kind":"trial_reminder","subject":"Your trial ends soon","text":"…","terms":{"price":19.99,"interval":"month","trial_days":14,"cancel_url":"https://acme.example/account/cancel","merchant_name":"Acme"}}. For WHEN each email must be sent, use get_notice_schedule.

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": {
      "kind": "<kind>",
      "subject": "<subject>"
    },
    "name": "check_email"
  }
}

Input Schema

Name	Required	Description
`html`	No	HTML body.
`kind`	Yes	Which email (trial_reminder = trial_ending).
`plan`	No	Plan name or price_… (default: the one named)
`site`	No	site_… whose Stripe prices judge it (default: your Stripe site).
`text`	No	Plain-text body (give text, html or both).
`as_of`	No	Evaluate the law as of this date, YYYY-MM-DD (default today).
`terms`	No	price, interval, cancel_url (optional with site); price_change: NEW price
`subject`	Yes	Subject line.
`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 / 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)."

Changed4 schema fields changedNov 8, 2026

addedInput schema / properties / plan

Added value: +{
+  "description": "Plan name or price_… (default: the one named)",
+  "maxLength": 200,
+  "type": "string"
+}

addedInput schema / properties / site

Added value: +{
+  "description": "site_… whose Stripe prices judge it (default: your Stripe site).",
+  "maxLength": 100,
+  "type": "string"
+}

changedInput schema / properties / terms / description

Previous value: -"The plan the email is about: price (or amount), interval and cancel_url at least."New value: +"price, interval, cancel_url (optional with site); price_change: NEW price"

changedInput schema / required

Previous value: -[
-  "kind",
-  "subject",
-  "terms"
-]New value: +[
+  "kind",
+  "subject"
+]

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

First observedNov 5, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description adds the substantive behavior that matters — that the result includes a rules-verified template with subject/text/html and merge tags plus required_by law attribution. It omits any note on output size, pagination, or what happens when no template can satisfy the rules.

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?

Purpose is front-loaded and the closing sibling pointer is well placed; the worked example earns its space by showing nested terms. The first sentence is dense with a long comma-separated kind list, which adds length without much precision beyond the enum.

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

Completeness5/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 a nested terms object and no output schema, the description supplies what structured data cannot: the shape of the return value (verified template plus required_by), a concrete invocation example, and a routing rule to the timing sibling. An agent has everything needed to call this correctly.

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

Parameters3/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 and the schema already explains kinds, plan, site, as_of and the nested terms fields. The inline example adds real clarity about how a trial_reminder payload should look, but it does not explain field interactions (e.g. price vs amount vs previous_price) beyond what the schema says, and the kinds list in prose omits trial_ending and charge_notice that the enum allows.

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?

The first sentence names a specific verb (checks) and resource (a subscription lifecycle email) and enumerates the concrete email kinds it covers, plus what it returns (template, required_by). It is easily distinguished from get_notice_schedule, which the description explicitly frames as the timing tool.

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?

The closing line gives an explicit routing rule: use get_notice_schedule for WHEN an email must be sent, implying this tool is for validating content. It does not disambiguate against near-named siblings like get_notice_templates or check_disclosure, which an agent may reasonably confuse with this one.

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.