Checkbox

Verify a task after applying its change

verify_task

Idempotent

Call right after you applied a task's change. Checkbox runs the fastest re-check that can confirm it and queues the confirming observation (a scan, a billing sync, the next real email). Send what you changed so the pre-check is exact and immediate:

page tasks: html = the rendered page HTML (before or after deploy; ≤ ~900 KB). Without it Checkbox fetches the live page.
Stripe tasks: stripe_checkout_session = exactly the object your code now passes to stripe.checkout.sessions.create.
email tasks: email = { subject, text and/or html } of the new template. Result: verification status passed / failed (with a diff of expected vs observed) / pending (waiting for the confirming scan). Waits up to wait seconds. Then follow next_action (usually get_compliance_plan). A verification with checks still needs_review is reported as failed with next_action type needs_review: it is not done.

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": {
      "task": "<task>"
    },
    "name": "verify_task"
  }
}

Input Schema

Name	Required	Description
`html`	No	Page tasks: the rendered page HTML.
`plan`	No	Email tasks: only this plan (name).
`task`	Yes	Task id (task_…).
`wait`	No	Seconds to wait for the result before answering (0-30; larger values wait 30; default 25). Use 0 to return at once and poll later.
`email`	No	Email tasks: the new template (passes when it matches one plan fully).
`recheck`	No	Not needed: a done task is always re-checked now; one closed with nothing observed passing is not_checked.
`price_id`	No	Email tasks: only this plan (Price id).
`stripe_checkout_session`	No	Stripe tasks: the params your code passes to stripe.checkout.sessions.create.
`stripe_checkout_sessions`	No	Stripe tasks, one params object per plan.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

changedInput schema / properties / recheck / description

Previous value: -"true re-checks a task that is already done (evaluates again now and queues a scan) instead of returning its last result."New value: +"Not needed: a done task is always re-checked now; one closed with nothing observed passing is not_checked."

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

Changed4 schema fields changedNov 8, 2026

changedInput schema / properties / email / description

Previous value: -"Email tasks: the new template."New value: +"Email tasks: the new template (passes when it matches one plan fully)."

addedInput schema / properties / plan

Added value: +{
+  "description": "Email tasks: only this plan (name).",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / price_id

Added value: +{
+  "description": "Email tasks: only this plan (Price id).",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / stripe_checkout_sessions

Added value: +{
+  "description": "Stripe tasks, one params object per plan.",
+  "items": {
+    "additionalProperties": {},
+    "type": "object"
+  },
+  "maxItems": 10,
+  "type": "array"
+}

First observedNov 5, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing async queueing of a confirming observation, a bounded wait (up to `wait` seconds, default 25, poll later with 0), return semantics including the expected-vs-observed diff, and an important edge case: a check still needs_review is reported as failed with next_action type needs_review. The side effects implied by 'queues the confirming observation' are consistent with readOnlyHint=false and openWorldHint=true, and idempotentHint=true matches the always-re-checked framing.

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

Conciseness5/5

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

The imperative call-to-action is first, followed by compact per-task-type bullets and a single result/next-step sentence. Heavily parenthetical but every clause carries load — the payload-per-task-type hints, the wait semantics, and the needs_review edge case each change how the tool is called.

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, nested-object tool with no output schema, the description still supplies the result shape and status semantics, the wait/polling model, per-task-type payload expectations, and the post-call routing step. Nothing an agent needs in order to invoke it correctly and interpret the answer is obviously missing.

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, but the description adds real conditional meaning the schema cannot express: which parameter applies to which task type (html for page tasks, with fallback to fetching the live page; stripe_checkout_session as the exact object passed to sessions.create; email as {subject, text and/or html}), plus the ~900 KB size hint. It leaves the remaining parameters (task, plan, price_id, stripe_checkout_sessions, recheck) to the schema.

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 ('verify a task' / 'after you applied a task's change') and defines the exact operation: it runs the fastest re-check that can confirm the change and queues the confirming observation (scan, billing sync, next real email). That composite behavior plus the result triad (passed / failed with diff / pending) makes it distinguishable from the single-check siblings without opening any schema.

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 guidance is explicit and front-loaded ('Call right after you applied a task's change'), and it tells the agent what to do next ('follow next_action, usually get_compliance_plan'). It also routes per task type (page, Stripe, email). It stops short of 5 because no alternatives or exclusions are named — nothing says when to use a lower-level check sibling instead.

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.