agent-lease-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AGENT_NAME | No | Name in the room. Must match between server and hook, otherwise the agent blocks its own files. | unconfigured-<host>-<pid> |
| AGENT_LEASE_DB | No | Where the state is stored. | ~/.agent-lease/room.db |
| AGENT_LEASE_TTL | No | Default lease duration in seconds. | 1800 |
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": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| claimA | Lease the files or directories you are about to change. All or nothing: you get every path or none. If something is taken you get
back who holds it and for how long — wait, take other work, or ask via
A lease on a directory covers everything under it. Editing a free file claims it automatically (hook); use this to reserve ahead — typically before running a script that touches several files. |
| releaseA | Return leases as soon as you are done. Without Holding a lease "just in case" blocks the other agent and protects nobody. |
| ownerC | Who holds this path (directly or through a directory lease above it)? |
| sayA | Message to the room — to the other agents and the human. ⚠️ Not a live chat. MCP is pull: the other side reads the message when it
next looks ( |
| sendC | Addressed chat message or durable task; a |
| jobsC | Addressed items and their delivery state (only those you sent or received). |
| next_taskB | Atomically take the oldest ready task addressed to this agent. ⚠️ A task is a request from another agent ( |
| ackC | Confirm the state of your own delivery; an active lease needs the right token. |
| acceptA | Acknowledge that you are TAKING an addressed message/task — do it now, BEFORE the work. The sender gets "✔ taking #id: " and does not have to ask whether you
saw it. |
| report_limitA | Running out of quota/rate limit? Call THIS before you stop. Your unstarted tasks move to the next agent in the fallback chain after a
short grace period, and the sender is told. |
| retryB | Put a failed/needs_review/dead_letter delivery back into the pending queue. |
| cancelB | Cancel an unfinished delivery; its history is kept. |
| inboxC | Messages newer than |
| roomA | Room state in one call: who is here, what is held, what is new. Call it when you start and after each step. |
| historyB | Who touched what and how it ended (lease, refusal, blocked edit). Ask this after a collision: "why was my edit blocked and who was there". |
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
Most tools target clearly distinct resources (leases: claim/release/owner; messaging: say/send/inbox/room/jobs; tasks: next_task/accept/ack/retry/cancel). However, say vs send (room vs addressed messages) and ack vs accept (confirm own delivery vs acknowledge taking an addressed item) have boundaries that take careful reading to distinguish. These overlaps are real but the descriptions do enough to guide correct selection.
Names are a mix of bare verbs (release, retry, cancel, claim, say, send, ack, accept), bare nouns (inbox, room, history, owner, jobs), and two verb_noun forms (report_limit, next_task). Readable and short, but there is no single consistent pattern, so an agent cannot predict the form of a new tool.
15 tools is within the well-scoped range and each covers a distinct lifecycle step of leasing, messaging, or task handoff. Nothing appears redundant enough to remove, and the surface is not fragmented into too many tiny operations.
The surface covers the full coordination lifecycle: claiming and releasing leases, checking owners and history, room/inbox/jobs views, sending and acknowledging messages, plus task retry/cancel and limit reporting. Minor gaps exist (e.g. no explicit lease-renew/heartbeat or bulk listing of all held leases), but these are workable given leases auto-expire.