ratchet-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RATCHET_API_KEY | Yes | Your Ratchet API key, used to authenticate MCP requests to the control plane. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ratchet_get_circuitA | Call this when a begin returned "approval_required" or "denied" and the reason mentions a circuit breaker. A breaker opens when an effect type is being performed far more often than its configured hourly ceiling — usually because something is looping. What to do with the answer:
|
| ratchet_begin_effectA | Call this IMMEDIATELY BEFORE performing any side effect that touches the outside world (sending a message, charging a card, creating a resource, writing to someone else's system). Returns a decision you MUST obey. If the response carries budget_warning, a spend ceiling exists but nothing was counted toward it — surface that to the operator rather than ignoring it. If it carries integration_warning, you have been beginning effects without reporting them: call ratchet_report_effect after every action, and tell the operator, because the effects already begun will start being blocked. Decisions:
|
| ratchet_report_effectA | Call this IMMEDIATELY AFTER performing an action that ratchet_begin_effect authorised. Pass the lease_token you were given. Report "succeeded" with a result — future duplicate callers replay that result instead of repeating the action. Report "failed" ONLY when you are certain the action did NOT reach the outside world (for example, a validation error before the request was sent). That permits a clean retry. If you are UNSURE whether it went through — a timeout, a dropped connection, an ambiguous error — do NOT report anything. Say so to the user. Letting the lease lapse records an honest "indeterminate", which is far safer than a false "failed" that licenses a duplicate. |
| ratchet_extend_leaseA | Call this periodically during a long action you were authorised to perform, before the lease expires. It tells Ratchet you are alive and extends your hold. Use it when work turns out to take longer than the lease you asked for — a slow vendor, a large export, a retrying upload. Without it, the lease expires while you are still working, the effect is recorded as having an UNKNOWN outcome, and your report is then refused. If it fails with lease_expired or lease_lost, STOP. Your hold is gone and the outcome is already recorded as unknown. Do not keep going and do not retry the action — call ratchet_begin_effect to find out where things actually stand. |
| ratchet_get_effectA | Look up the recorded state of an action WITHOUT reserving a lease and without consuming your plan allowance. Use it to answer "did I already do this?" — for example when resuming after a crash, or when a user asks whether something went through. To actually perform work, use ratchet_begin_effect instead; this tool never grants permission. |
| ratchet_resolve_effectA | Use ONLY after you have checked the third-party system and now know what really happened to an effect that was left "indeterminate". Record "succeeded" if the action did occur, "failed" if it did not, or "cancelled" to abandon it. Include how you verified it in |
| ratchet_get_runA | Recall the work already gated under a run id, before doing anything that might repeat it. Call this FIRST when resuming a task — after a restart, a handoff, or when your context has been compacted and you are no longer certain what you did. It returns what succeeded with the recorded results, what is still in flight, what failed, and — separately, because it is the only category that can hurt you — what has an unknown outcome. Anything under "done" has already happened: use its result rather than performing it again. Costs about a seventeenth of the context of listing the same effects. |
| ratchet_list_effectsA | Review recent effects for this workspace, optionally filtered by state or run. Use it to find unresolved work — filter by state "indeterminate" to see every action whose outcome is unknown and still needs verification. |
| ratchet_get_policyA | Shows how this workspace has configured a given effect type: whether it is allowed, how long a lease lasts, the attempt ceiling, spend limits, the approval threshold above which an action waits for a human, and — most importantly — what happens when an attempt ends indeterminate. Check this before designing a retry strategy. |
| ratchet_unwind_groupA | Call this when a multi-step workflow fails partway and the steps that already succeeded must be undone — a booking made but not paid for, a resource created but not configured.
Returns the exact compensations to perform, in the order to perform them, which is the REVERSE of the order they succeeded in. Undoing forwards can strand a step that depended on an earlier one.
Ratchet does NOT perform the compensations. For each step: call ratchet_begin_effect with the step's suggested_idempotency_key and compensates_effect_id, do the real undo, then call ratchet_report_effect. Gating the undo is what stops a retry from refunding twice.
Read |
| ratchet_get_groupA | Shows every step in a multi-step unit of work: what succeeded, what can still be undone, what has already been undone, what is irreversible, and what has an unknown outcome. Use it to answer "where did this workflow actually get to?" after a crash, without changing anything. |
| ratchet_get_usageA | Returns the current plan, remaining included effects for the month, prepaid credit balance, and today's declared external spend against each budget ceiling. Use it to warn a user before a long run exhausts an allowance or a budget. |
| ratchet_list_receiptsA | Returns a signed receipt for every decision made about one effect, refusals included. Each signature is over the exact bytes in |
| ratchet_reconcile_effectsA | Given the idempotency keys for actions a vendor says actually happened, returns which ones went through Ratchet and which it has never seen. The unseen ones are code paths that acted WITHOUT asking, so a retry there can act twice — a bug the operator almost certainly does not know about. Send references only; never send credentials. |
| ratchet_get_prevented_lossA | Counts duplicate actions refused in the last 30 days and what they would have cost. Only counts refusals where a cost was declared on the effect, so it under-reports rather than flatters. IMPORTANT: pass estimated_cost_micros on ratchet_begin_effect or this reads zero — the number is only as good as what callers declare. This is money not spent at your vendors, never money paid to Ratchet. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Each tool targets a distinct concern: authorization, reporting, lease extension, state lookup, group/run inspection, receipts, policy, usage, reconciliation, and safety statistics. The only superficially similar retrieval tools (get_effect, list_effects, get_run, get_group) are clearly separated by what they return and when to use them.
All tools share the ratchet_ prefix and follow a consistent snake_case verb_noun pattern (begin_effect, report_effect, get_policy, unwind_group). Even compound targets like get_prevented_loss preserve the same structure, so the naming convention is predictable.
Fifteen tools is at the top of the ideal range, but the domain is substantial: effect lifecycle, leases, lookup, audit receipts, policies, budgets, circuit breakers, reconciliation, and rollback. Each tool has a distinct role and none feels redundant.
The surface covers the full effect lifecycle—begin, report, extend, resolve—plus all inspection and recovery needs: runs, groups, circuits, receipts, policy, usage, reconcile, and prevented-loss stats. No obvious dead end exists for the intended agent workflows.