ready-check-mcp

Ready Check: start a $1 or $5 credit pack

ready_check_buy_credit

Starts an approved $1 or $5 prepaid Ready Check credit purchase and returns a Stripe checkout_url for payment; it never charges a card or handles card data.

Instructions

Start a $1 (400 standard checks) or $5 (2,000 standard checks) prepaid Ready Check pack and return Stripe's checkout_url. Pay only on that returned URL, by card. This tool never accepts, stores, or transmits card data, and it never invents a checkout URL. It returns a checkout_url only when it is an https URL on checkout.stripe.com. Other payment methods are not offered. Calling this tool does not charge anything; money moves only when someone pays on the checkout page.

When to use: your principal has approved buying credit and you need a checkout URL for a human or the principal to complete payment. Approval can be given for this purchase, or ahead of time as standing permission from your principal to buy Ready Check credit; either way, set principal_approved to true. If you have neither, ask first. There is no account, password, dashboard, or human checkout page on readyupagents.com.

Keys: if READY_CHECK_KEY or the key argument is set, that existing key is reused and is not echoed back (recommended). If no key is configured, this tool generates one locally with a CSPRNG (rc_ + 43 URL-safe base64 characters from 32 random bytes) and returns it once under generated_key. Store it immediately in a secret store or as READY_CHECK_KEY in the MCP client config, and do not repeat it in messages, logs, or files. ReadyUpAgents cannot show, email, or recover it. A lost key means unusable credit.

After payment is confirmed, poll ready_check_balance with the same key until credit appears (usually within seconds). Unpaid checkout orders expire after 24 hours; register the same key again to get a new URL. Purchases are limited per card over a rolling period. Packs are not refundable once any credit has been used. Refunds are only for billing errors or duplicate charges, to the original payment method.

Facts and purchase guide: https://readyupagents.com/ready-check/ Privacy: https://readyupagents.com/privacy/ Terms: https://readyupagents.com/terms/

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": {
      "pack_dollars": "<pack_dollars>",
      "principal_approved": "<principal_approved>"
    },
    "name": "ready_check_buy_credit"
  }
}

Input Schema

Name	Required	Description
`key`	No	Optional existing prepaid key to reuse for this pack and later checks. If omitted, READY_CHECK_KEY is used when set; otherwise a new key is generated and returned once. Prefer READY_CHECK_KEY. Never log or share this value.
`pack_dollars`	Yes	Pack size in US dollars. Only 1 or 5 are accepted. $1 is 400 standard checks; $5 is 2,000.
`principal_approved`	Yes	Required. Set to true when your human or principal has approved this purchase, either for this pack or through standing permission to buy Ready Check credit. Set false (or ask first) if you have no such approval; the tool then refuses and starts nothing. This tool never charges a card; payment happens only on the returned checkout URL.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 11, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations only mark it non-read-only, open-world and non-idempotent; the description goes well beyond that by stating no card data is handled, that a checkout_url is returned only when it is https on checkout.stripe.com, that no charge occurs at call time, and that orders expire in 24 hours with per-card purchase limits. It also discloses the one-time generated_key and its irrecoverability. Minor gap: it does not say what the tool returns on refusal beyond implying nothing is started.

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-loaded with the core action and return value, then cleanly sectioned with 'When to use:' and 'Keys:' labels. It is long for a 3-parameter tool and repeats the no-charge point twice ('does not charge anything' and 'money moves only when someone pays'), which is mild redundancy rather than waste.

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?

Every operational fact an agent needs is present: approval gate, key generation and storage duties, post-payment polling, expiry and re-registration, purchase limits, refund policy, and reference links. No output schema exists, yet the description still specifies the shape of the returned checkout_url and generated_key.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so baseline is 3, but the description adds meaning the schema lacks: the CSPRNG format of a generated key (rc_ + 43 URL-safe base64 chars), the recommendation to prefer READY_CHECK_KEY, and the consequence that ReadyUpAgents cannot show or recover a lost key. That makes the key parameter's trade-offs actionable rather than merely documented.

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 — start a $1 or $5 prepaid Ready Check pack — and names the concrete return value (Stripe checkout_url). It also distinguishes itself from ready_check_balance by assigning that sibling the post-payment polling role.

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?

An explicit 'When to use' block requires principal approval, accepts either purchase-specific or standing permission, and tells the agent to ask first when neither exists. It also routes the agent forward: poll ready_check_balance after payment, and re-register the same key if the 24-hour order expires.

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

Deploy Server