Checkbox

Store the Stripe TEST restricted key (rk_test_)

store_stripe_test_key

Idempotent

Stores the site's ONE Stripe key in TEST mode: a restricted key (rk_test_…) from the project's env. Checked with Stripe; on a test-mode site it also connects Stripe (checks, fixes after the human approves, test runs). The human sees it on the dashboard and can revoke it. Live and sk_test_ keys are refused (the error says what to do). Never ask the human to paste a key into the chat.

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": {
      "secret_key": "<secret_key>"
    },
    "name": "store_stripe_test_key"
  }
}

Input Schema

Name	Required	Description
`site`	No	Site id (site_…). Optional when the account has exactly one site in this mode; list_sites shows them.
`type`	No	Optional: "stripe_test" (the REST body's type; "stripe" is accepted too). Always stored as a Stripe TEST key.
`secret_key`	Yes	rk_test_… key. Stored encrypted; never returned.
`confirm_account_mismatch`	No	Human said yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 9, 2026

addedInput schema / properties / confirm_account_mismatch

Added value: +{
+  "description": "Human said yes",
+  "type": "boolean"
+}

addedInput schema / properties / type

Added value: +{
+  "description": "Optional: \"stripe_test\" (the REST body's type; \"stripe\" is accepted too). Always stored as a Stripe TEST key.",
+  "enum": [
+    "stripe_test",
+    "stripe"
+  ],
+  "type": "string"
+}

AddedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well past the annotations: it discloses the external Stripe verification call implied by openWorldHint, the downstream side effects (Stripe connection, checks, fixes only after human approval, test runs), human visibility/revocation on the dashboard, and typed refusal behavior with actionable errors. The safety-relevant approval gate is exactly the context an agent needs before invoking a mutation.

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?

Front-loads the core fact (one test-mode restricted key) and keeps the whole thing to four sentences. The parenthetical asides make the middle sentence a bit dense and run-on, but no sentence is filler.

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 mutating, externally-verifying credential tool with no output schema, the description covers source of the secret, validation and refusal behavior, human-approval flow, post-write side effects, and revocability — everything needed to call it correctly without discovering behavior at runtime.

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; the description still adds meaning by telling the agent where secret_key must originate (the project's env) and prohibiting asking the human to paste it in chat, plus the accepted/refused key-type rule that governs the type and secret_key parameters. The site and confirm_account_mismatch semantics are left entirely 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 ('Stores the site's ONE Stripe key in TEST mode: a restricted key (rk_test_…)') and constrains the accepted input class, which no sibling tool covers. An agent can tell immediately this is the Stripe credential-storage tool rather than the checkout-session check or generic update tools.

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?

Gives clear operating conditions: use it for the single test-mode key, keys must come from the project's env, and live or sk_test_ keys are refused with an instructive error. It does not name an alternative tool or spell out sequencing relative to get_setup_status/start_test_run, so it stops short of full when/when-not routing.

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.