ready-check-mcp

Ready Check: read prepaid credit

ready_check_balance

Read-onlyIdempotent

Reads the remaining prepaid credit balance in US dollars for a key so users can confirm available check credit before a check or after payment.

Instructions

Read remaining prepaid Ready Check credit for a key, in US dollars. This does not run a check and does not charge check credit.

When to use: after paying for a pack (poll until credit appears, usually within seconds of payment confirmation); before a check; or after an insufficient_credit error. Reuse the same key for every check and later packs. Unused credit never expires while the key stays open.

A prepaid key is required (READY_CHECK_KEY, or the key argument). Prefer the environment variable so the key is not placed in the conversation. Never log, email, or share the key.

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

Input Schema

Name	Required	Description	Default
`key`	No	Prepaid key (rc_ + 43 URL-safe base64 characters). Prefer the READY_CHECK_KEY environment variable so the key is not placed in the conversation. Never log or share this value.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 11, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive, open-world), the description adds real operational context: USD denomination, near-immediate post-payment visibility ('usually within seconds'), non-expiring credit while the key is open, and explicit security handling for the key. None of this is recoverable from the annotations alone.

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?

Structure is strong and front-loaded: what it does, when to use it, then key handling. Minor deduction because the security advice about not placing/logging the key largely duplicates the key parameter's schema description, so those sentences do not fully earn their place.

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 single-parameter read tool with no output schema, the description covers purpose, currency, timing, and required key sourcing well. It stops short of indicating what the returned value looks like (a bare amount versus a structured object) or what happens with an invalid/expired key, which are the remaining small gaps.

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 already 100% and documents the rc_ + 43-character format, so the baseline is 3. The description adds value by resolving the required/optional ambiguity: the schema lists zero required parameters, yet the text clarifies a key is mandatory via either READY_CHECK_KEY or the key argument, with a stated preference for the environment variable.

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 description opens with a precise verb and resource ('Read remaining prepaid Ready Check credit for a key, in US dollars') and immediately disambiguates from the siblings by stating 'This does not run a check and does not charge check credit', which separates it from ready_check and ready_check_buy_credit.

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 gives explicit trigger conditions: after paying for a pack (with polling guidance), before running a check, or after an insufficient_credit error. It also fixes the key-reuse rule across checks and later packs, leaving no ambiguity about when this tool applies.

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

Deploy Server