Skip to main content
Glama

Take or refresh a lease

claim

Second step, after look, when you actually start: writes a lease on the key so that other agents see it is taken. mode shared (default) only counts you among the others, and with slots it lets you in only while fewer than that many others hold the key; mode exclusive is granted to one agent at a time and is refused with a wait time while another holds it; mode once is for an intent of your own, such as a payment id, that must happen exactly once within thirty days, and is refused on public venue work. Returns lease id, token, expiry, your position and the number of others; a refusal returns the reason and how long to wait. The token is shown only once: keep it. A lease dies by itself at its expiry; to keep it call claim again with lease and token before that. Use release when you finish. Do not use claim just to find out who is there: that is look.

Input Schema

NameRequiredDescriptionDefault
keyYesthe same key you looked at, written the same way
ttlNoseconds until the lease dies unless refreshed, 30 to 3600, default 600
hopsNoremaining delegation hops when this work was handed to you; pass the number you received minus one
modeNoshared, exclusive or once; default shared
agentYesyour stable name, the same you used in look
leaseNoto refresh: the lease id
slotsNowith mode shared: how many agents you allow on this key at once, for example the paid places of a task or the parallel calls an API bears; the claim is refused with a wait time while that many others hold it
tokenNoto refresh: the token
intentNoone line: what you are going to do

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / agent / description
      Previous value: -"your stable name"New value: +"your stable name, the same you used in look"
    • changedInput schema / properties / key / description
      Previous value: -"the same key you looked at"New value: +"the same key you looked at, written the same way"
    • addedInput schema / properties / slots
      Added value: +{
      +  "description": "with mode shared: how many agents you allow on this key at once, for example the paid places of a task or the parallel calls an API bears; the claim is refused with a wait time while that many others hold it",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations mark it non-readonly/non-idempotent but say nothing about lease semantics; the description fills that gap richly — the token is shown only once, the lease self-expires, refresh requires lease+token, refusals return a reason and wait time, and 'once' mode is refused on public venue work. These are exactly the stateful, hard-to-reverse traits an agent needs, beyond what the annotations provide.

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?

It is front-loaded with the workflow position and the core action, and essentially every sentence carries operational information. It is dense and semicolon-heavy, which makes it slightly harder to scan than it could be, but there is little dead weight.

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?

With no output schema, the description correctly carries the return contract (lease id, token, expiry, position, count of others) and the refusal shape (reason, wait time). Combined with the lifecycle and mode coverage, an agent has everything needed to call it correctly without opening anything else.

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%, but the description still adds genuine meaning the schema only gestures at: it explains the three mode behaviors (shared/exclusive/once) and what slots does ('counts you among the others' / caps concurrent holders). Only 'hops' goes unmentioned in the description, keeping it from a 5.

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 names the specific action and resource up front: it 'writes a lease on the key so that other agents see it is taken.' It also positions itself in a workflow ('Second step, after look') and explicitly distinguishes itself from both siblings look and release, so an agent can tell exactly what claim does vs. its neighbors.

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?

Gives explicit when-to-use ('after look, when you actually start'), when-not ('Do not use claim just to find out who is there: that is look'), and the lifecycle handoff ('Use release when you finish'). The refresh trigger ('call claim again with lease and token before that') is spelled out with its condition. Nothing is left to inference.

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