Skip to main content
Glama

Agentic Endpoints

Claim an action exactly once

once_key_claim
Idempotent

Atomic idempotency witness. Claims a {namespace, action_key} pair exactly once, so a fleet of agents cannot perform the same side effect twice. Call this BEFORE any non-idempotent action such as sending an email, charging a card, or posting an order. Returns one of: 'claimed' — you won, do the work, then call once_key_complete; 'in_progress' — another agent holds a live lease, wait retry_after seconds and do NOT do the work; 'duplicate' — already done, and the 'result' field carries the original outcome, so use it instead of repeating the work; 'held' — another agent claimed this key, set no lease, and has NOT completed it: there is no result and there may never be one, so do NOT do the work and do NOT treat it as done, because the key stays locked until expires_at; 'conflict' — the same key was claimed with a different payload hash, so your key derivation is wrong. Backed by a strongly consistent Durable Object; this is not something an agent can safely reimplement locally. Costs $0.010 in USDC on Base, paid via the x402 protocol, or from a credit token — call credits_trial for free credit if you have neither.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ttlNoClaim lifetime in seconds (default 86400)
lease_ttlNoSeconds you have to call once_key_complete before the claim is treated as abandoned and another agent may take it over. Set this if your work could crash partway. Omit it to hold the claim for the full ttl, which guarantees nothing else can ever run the side effect.
namespaceYesIsolation scope, e.g. your application name
action_keyYesStable identifier for the action being claimed
credit_tokenNoOptional. A credit token from credits_trial or /credits/buy. Supplying it pays for this call from that balance, so no x402 payment or wallet is needed.
payload_sha256NoOptional hash of the action payload. If it differs from the stored hash, the result is a conflict.
namespace_tokenNoOne-time token issued by the first call that claimed this namespace. Required for every later call.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoPresent alongside a newly issued namespace_token
resultNoThe recorded result, present when status is 'duplicate'.
statusYes'claimed' means you own the action and must perform it. 'duplicate' means someone already did: do NOT repeat the side effect, use `result` instead.
receiptNoPayment receipt
namespaceNoIsolation scope
action_keyYesThe key that was claimed
claimed_atNoISO-8601 claim time
expires_atNoISO-8601 expiry of the claim record
has_resultNoDistinguishes a recorded null result from no result at all
namespace_tokenNoIssued only on the first claim in a namespace, shown exactly once
lease_expires_atNoCall once_key_complete before this or the claim may be taken over

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only provide basic flags (readOnlyHint: false, idempotentHint: true). The description goes far beyond that by explaining the underlying consistency (strongly consistent Durable Object), cost details ($0.010 USDC), payment methods (x402 or credit token), lease semantics (lease_ttl vs ttl, abandonment, takeover), and the meaning of 'held' (key stays locked until expires_at). It also clarifies that 'conflict' indicates a key derivation error. None of these are in the annotations, and there is no contradiction.

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 long but every clause earns its place. It opens with the core purpose, then the invocation timing, then the return-value contract, then cost/payment. The information is dense yet logically ordered, with no fluff. For a tool with five distinct outcomes and a payment model, this level of detail is necessary and well-structured.

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 the complexity (7 params, 5 return states, payment integration), the description is remarkably complete. It covers all return values, retry behavior, lease expiration, cost, payment fallback, and the recommendation to use credits_trial. It even notes what not to do in each scenario. An agent has everything needed to invoke this correctly without further investigation.

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?

The schema already documents all 7 parameters with 100% coverage, so the baseline is 3. The description adds value by explaining the relationship between lease_ttl and ttl, the consequence of omitting lease_ttl (hold for full ttl), the requirement of namespace_token for later calls, and the conflict semantics tied to payload_sha256. It doesn't restate each parameter's schema description but gives usage-oriented context that helps an agent choose and set them correctly.

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 a specific verb ('claims'), a concrete resource ('{namespace, action_key} pair'), and the exact purpose: to ensure a side effect is performed exactly once across a fleet of agents. It distinguishes itself from siblings like once_key_complete and once_key_release by clarifying that this is the entry point before any non-idempotent action. The primary behavior is unmistakable.

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 explicitly says 'Call this BEFORE any non-idempotent action' and lists concrete examples (email, charge card, post order). It then enumerates the five possible return values and the precise action an agent should take for each (e.g., wait retry_after seconds, use the result, do not do the work). It also mentions the fallback to credits_trial for free credit and warns against reimplementation. This leaves no ambiguity about when and how to use it.

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.

Resources