Skip to main content
Glama

Run a synthetic test subscription (test mode)

start_test_run

Observes the WHOLE subscription lifecycle, not just the checkout: in the billing platform's TEST mode Checkbox subscribes a test customer (card 4242…) whose email is a Checkbox inbox, waits for your acknowledgment email, fast-forwards a Stripe test clock through every legal notice window before trial end and renewal (collecting reminder emails), then cancels online and waits for the cancellation confirmation. Nothing is charged. Needs a Stripe TEST-mode restricted key (rk_test_…) stored for the site: store it yourself with store_stripe_test_key (one key for checks, fixes and test runs; live keys stay with the human in the dashboard). Never ask the human to paste a key into the chat. If missing, the error's next_action says so. For non-Stripe sites use type "generic". Usually 1-2 minutes (real_checkout: a few): poll get_test_run (its next_action says when, and minutes_left estimates the rest). Each step reports observations, check results and agent-readable fixes; apply them and run again. mode "real_checkout" is the PROOF run: the shopper buys through the merchant's own checkout on its test deployment (stripe.checkout_url or stripe.payment_link), so the merchant's webhook handlers and email code fire; give stripe.test_account + stripe.cancel_url when customers cancel in the app. A step is "passed" only with evidence; "warning" means needs review. Cancel: stripe.cancel_via "stripe_portal" (default) or "merchant_flow" (cancel_url + cancel_steps; behind a login, test_account { login_url, email, password }).

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

Input Schema

NameRequiredDescriptionDefault
modeNoStripe runs: mirror (default; test clock through every notice window) or real_checkout (the proof run through the merchant's own checkout, webhooks and emails).
planNoPlan to run: a registered checkout config name or a price_… its line_items use.
siteNoSite id (site_…). Optional when the account has exactly one site in this mode; list_sites shows them.
typeNostripe (default when a Stripe test key is stored) or generic (test coupon / test account, no time travel).
cancelNoCancel online at the end (default true).
regionNoState the synthetic shopper visits from, e.g. "US-CA".
stripeNoStripe options.
genericNoGeneric (non-Stripe) options as in the API: checkout_url, checkout_steps, complete_purchase { steps, promo_code }, account { login_url, email, password }, cancel_steps.
cancel_urlNoShortcut for stripe.cancel_url.
advance_timeNoAdvance a Stripe test clock through trial end and first renewal (default true).
cancel_stepsNoShortcut for stripe.cancel_steps.
checkout_urlNoShortcut for stripe.checkout_url (real_checkout: your checkout page on your TEST deployment).
test_accountNoShortcut for stripe.test_account. email "{{inbox}}" uses the run inbox.
checkout_stepsNoShortcut for stripe.checkout_steps (embedded checkout: fill email/card, tick consent, click pay).
email_wait_secondsNoHow long to wait for each email (default 120).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / stripe / properties / coupon
      Added value: +{
      +  "description": "Mirror: TEST-mode coupon id for the test subscription.",
      +  "maxLength": 200,
      +  "type": "string"
      +}
    • addedInput schema / properties / stripe / properties / promotion_code
      Added value: +{
      +  "description": "Mirror: TEST-mode promotion code (promo_… or code).",
      +  "maxLength": 200,
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / plan
      Added value: +{
      +  "description": "Plan to run: a registered checkout config name or a price_… its line_items use.",
      +  "maxLength": 200,
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • changedInput schema / additionalProperties
      Previous value: -falseNew value: +true
  4. First observed

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare the write/open-world/non-idempotent/non-destructive profile, and the description adds genuinely useful context beyond them: nothing is charged, the run takes 1-2 minutes (longer for real_checkout), 'passed' requires evidence while 'warning' means needs review, and a missing key surfaces next_action. What it omits is what a re-invocation does (new run vs. resume) and any concurrency or rate-limit constraints.

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?

The content is high-value but delivered as a dense, parenthetical-laden block with long multi-clause sentences; the purpose statement is buried behind the lifecycle narrative rather than front-loaded. A short lead line ('Starts a synthetic test subscription run; poll get_test_run for progress') followed by the mode/key/cancel detail would make it scannable.

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 15-parameter, deeply nested tool with no output schema, the description covers the decisions that matter: which mode to pick, key prerequisite, expected duration and polling, cancel paths, and the fact that each step returns observations and fixes. It stops short of describing run-identity/idempotency behavior and a few nested Stripe options, but nothing critical for a first correct call is 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 description coverage is 100%, so a baseline of 3 is the floor, and the description earns a bump by explaining semantics the schema only labels: what mirror vs real_checkout actually exercise, cancel_via defaults (stripe_portal) and the login-gated merchant_flow case, the {{inbox}} placeholder, and the shape of checkout_steps. Several parameters (region, advance_time, email_wait_seconds, coupon/promotion_code, price_map, reset_url/cleanup_url) get no narrative treatment at all.

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 concretely describes what the tool does: it drives a full synthetic subscription lifecycle (test subscribe, notice windows, renewal, cancel) in Stripe TEST mode, and explicitly distinguishes mirror vs real_checkout. It never states the verb crisply up front (the opening sentence describes what is 'observed' rather than 'starts a run'), but an agent can still identify the action and its scope without opening the schema.

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

Usage Guidelines5/5

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

It names explicit alternatives and the conditions that select them: mirror is the default, real_checkout is 'the PROOF run' through the merchant's own checkout, and generic is required for non-Stripe sites. It also routes to store_stripe_test_key when the key is missing and tells the agent to poll get_test_run and re-run after applying fixes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.