Skip to main content
Glama

Ask permission to perform a side effect

ratchet_begin_effect

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. Decisions:

  • "execute": you hold the lease. Perform the action now, then call ratchet_report_effect. If the response carries vendor_idempotency_key, send that key to the vendor as ITS own idempotency key (the response says where it goes). Where enforced is true the vendor itself will then refuse a duplicate, which protects the action even if some other caller skips this gate entirely.

  • "duplicate": this action ALREADY HAPPENED. Do NOT perform it. Use the returned result as though you had just done the work.

  • "in_flight": another process is doing it right now. Do NOT perform it. Wait retry_after_seconds and ask again.

  • "blocked": an earlier attempt may or may not have taken effect. Do NOT perform it. Tell the user what is unresolved, or verify at the vendor and call ratchet_resolve_effect.

  • "approval_required": a human must approve. Do NOT perform it.

  • "denied": policy or budget refused it. Do NOT perform it. The idempotency_key must be derived deterministically from the work itself so that a retry of the same logical action produces the same key. Never use a random value or the current time.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
run_idNoGroups all effects from one task or run.
vendorNoWhich vendor performs this effect (e.g. "stripe", "square", "adyen"). Shapes vendor_idempotency_key so it satisfies that vendor's rules.
payloadNoThe action's parameters. Only a hash is stored — the raw content never persists. Reusing a key with different parameters is rejected, which catches key collisions.
agent_idNoIdentifier for you, the calling agent.
group_keyNoUse when this action is one step of a multi-step workflow that must succeed or fail as a whole, e.g. "booking:trip_8812". Lets the whole unit be rolled back later.
effect_typeYesNamespaced kind of side effect, e.g. "email.send", "payment.charge", "github.pr.create". Policy is configured per type.
compensationNoHow to undo THIS step if the workflow has to be rolled back. Declare it now, while you still know what undoing means — it cannot be worked out later. Steps without one are permanent.
lease_secondsNoHow long you expect the action to take. Report before this elapses or the effect becomes indeterminate.
idempotency_keyYesDeterministic identifier for this specific logical action, e.g. "welcome-email:user_123" or "invoice:2026-08:acct_88123". The SAME action retried must produce the SAME key.
compensates_effect_idNoSet when THIS call IS an undo, naming the effect it reverses. Comes from ratchet_unwind_group.
estimated_cost_microsNoWhat this action will cost at the third party, in micro-USD (1000000 = $1). ALWAYS SEND THIS when the action costs money. Spend ceilings are computed from it, and a ceiling with nothing declared against it never fires — the operator would be relying on a limit that cannot trigger. If the response contains budget_warning, that is exactly what has happened: tell the operator. Ratchet does not collect this money; it only counts it.

TDQS

A4.7/5.0
Behavior5/5

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

The description goes far beyond the annotations by disclosing the full decision protocol, budget_warning semantics, vendor_idempotency_key behavior, enforced deduplication, and the irreversible consequences of each decision. It also explains that the action must not be performed for duplicate/in_flight/blocked/approval_required/denied outcomes, which gives the agent a complete behavioral contract.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured: the core call instruction is front-loaded, decisions are grouped and formatted for scanning, and each behavioral rule earns its place. It is long because the decision protocol genuinely needs that detail, not because of redundancy.

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?

Given 11 parameters, nested objects, no output schema, and a complex multi-decision tool, this description is remarkably complete. It explains when to call, what each decision means, what to do after each one, how to handle budget warnings, and how to derive idempotency keys, so an agent has enough context to invoke the tool and interpret the response correctly.

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, but the description adds meaningful guidance beyond the schema, particularly around deterministic idempotency_key derivation and never using random/time-based values. It also clarifies the meaning of a returned vendor_idempotency_key, which helps the agent use the input parameters correctly, though not every parameter gets a dedicated narrative.

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 states its role immediately: 'Call this IMMEDIATELY BEFORE performing any side effect that touches the outside world' and frames the tool as a permission/lease gate. It uses a specific verb, resource, and timing constraint, making it easy to distinguish from sibling tools like ratchet_report_effect or ratchet_check_effect.

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?

The description gives a clear when-to-use rule and routes follow-up actions per decision (`ratchet_report_effect`, `ratchet_resolve_effect`), which effectively distinguishes it from related tools. It lacks an explicit 'do not use this when...' statement or named alternatives for every sibling, but the intended usage boundary is strongly implied and actionable.

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.

TDQS

A4.2/5.0
Disambiguation4/5

Most tools map to clearly distinct lifecycle phases (begin/report/resolve/heartbeat) and are strongly described, but recall, group_status, and list_effects all deal with looking up past effect or workflow state and could be confused when resuming work. The use-case guidance in the descriptions mostly disambiguates them, so this is a minor rather than systemic issue.

Naming Consistency4/5

All tools share the ratchet_ prefix and snake_case, which gives a strong predictable family feel. However, some names follow verb_noun (begin_effect, resolve_effect) while others are noun phrases (effect_receipts, group_status, prevented_loss), so the pattern is consistent in style but not in grammatical form.

Tool Count5/5

Fifteen tools is at the upper end of the ideal range, but the domain is broad enough to justify every entry: effect lifecycle, lease maintenance, state inspection, circuit breakers, policies, receipts, reconciliation, rollback, and usage. Each tool fills a distinct role with no obvious redundancy.

Completeness5/5

The surface covers the full idempotency and safety lifecycle: authorize, execute, report, heartbeat, recover from indeterminate outcomes, verify with receipts, reconcile vendor truth, roll back multi-step work, and monitor budgets and policies. There are no dead ends or missing operations that would strand an agent in this domain.