Skip to main content
Glama

MCPFax Agent Continuity

Take work, leased so a dead worker cannot lose it

work_take

Take up to n items, LEASED not deleted — the same lease semantics as lease()/renew()/release(): a holder, a fence token, an expiry. Two workers can never be handed the same item, because one single-threaded Durable Object owns the queue. IF YOUR PROCESS DIES THE LEASE SIMPLY EXPIRES AND THE ITEMS RETURN TO THE QUEUE with attempts incremented; nothing had to stay alive to notice, and that recovery is the point. EACH ITEM CARRIES ITS OWN FENCE, drawn independently on every take: the token you are given for one item tells you nothing about the token another worker was given for another item, and it is not the previous holder's token plus one. The item's ORDER is generation (identical to attempts, the number of times it has been handed out) — that is the number to compare and the number to hand to an external store; the fence is the secret. $0.002 when at least one item is handed to you for the FIRST time; a re-take after your own lease expired is free, exactly like mailbox redelivery. An empty or cancelled queue returns nothing, says so, and costs nothing. Costs $0.002 USDC per call via x402 on Base, and ONLY when at least one item was handed to a worker for the FIRST time (a re-take after a lease expired is free); otherwise the same call returns the full answer and settles nothing. Authenticate with Authorization: Bearer , or pass agent_key as an argument if your host cannot set headers. Equivalent HTTP route: POST /v1/work/take.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nNoHow many items to take. 1..25. Default 1. Example: '5'.
holderNoWho is taking — an instance id you choose, exactly as with lease(). Default 'worker'. Example: 'worker-3'.
queue_idYesThe queue to take from. Alias: job_id — a job and its work queue are the same thing. Example: 'permit-batch-2026-08'.
agent_keyNoYour agent_secret, if your MCP host cannot set the Authorization header. Prefer the header.
lease_secondsNoHow long you hold them before they return to the queue. Default 300, min 5, max 86400. Example: '300'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / agent_key / examples
      Added value: +[
      +  "the agent_secret that register returned"
      +]
  2. Changed4 schema fields changed
    • addedInput schema / properties / holder / examples
      Added value: +[
      +  "worker-3"
      +]
    • addedInput schema / properties / lease_seconds / examples
      Added value: +[
      +  300
      +]
    • addedInput schema / properties / n / examples
      Added value: +[
      +  5
      +]
    • addedInput schema / properties / queue_id / examples
      Added value: +[
      +  "permit-batch-2026-08"
      +]
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations give only generic hints, but the description discloses the important behavioral traits: items are leased not deleted, single-owner exclusivity, per-item fencing, lease expiration returning items, and first-time-only billing. There is no contradiction with the annotations.

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

Conciseness3/5

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

Important information is front-loaded and logically grouped, but the $0.002 pricing condition is stated twice and several sentences are long and run-on, making the description more verbose than necessary for an agent to parse.

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?

Even without an output schema, the description covers edge cases, recovery behavior, fencing, cost, authentication, and the equivalent HTTP route. An agent has enough behavioral contract to call the tool correctly and know what to expect.

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%, but the description adds real meaning: it links holder and lease_seconds to the lease/fence model, explains agent_key as a header fallback, and clarifies what 'take n items' means in terms of leased items rather than deleted items.

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?

Opens with a specific action and object: 'Take up to n items' and immediately distinguishes itself by saying 'LEASED not deleted'. It clearly positions this tool against the lease family and against work_push/work_done/work_fail.

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?

Provides rich context for when to call it: lease semantics, expiry on worker death, empty/cancelled queues, auth options, and conditional billing. It does not explicitly list sibling alternatives to avoid, but the behavior is specific enough that the agent will not confuse it with push/done/fail/status.

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