tower-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TOWER_TOKEN | No | Shared secret for authenticating with the Tower server. Treat it like push access. Required when running the server in HTTP mode for team collaboration. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| claim_intentA | Register intent to edit code BEFORE editing. Returns any collisions with other active agents. Call this first, always. Also pass |
| check_collisionA | Check for collisions without registering a claim (a dry run). |
| heartbeatB | Keep an active claim alive; claims auto-expire without heartbeats. Returns |
| complete_claimA | Release a claim after committing (optionally record the commit sha). Pass |
| release_claimC | Abandon a claim without committing. |
| list_claimsB | List claims, optionally filtered by repo/branch/status. |
| log_decisionC | Record an architecture decision and WHY it was made, for the team's shared memory. |
| get_decisionsC | Recall past architecture decisions before acting. |
| next_taskB | Ask the sequencer for a task whose module is safe to start right now. |
| send_messageB | Send an async message or task to another agent (toAgentId, or '*' to broadcast). Delivered on their next Tower contact. kind 'task' delegates work; reply with kind 'task_update' (replyTo=the task id) when done. |
| fetch_messagesA | Read your inbox (marks messages read). Call whenever claim_intent reports unreadMessages > 0. |
| pendingA | Read-only count of unread messages + open tasks waiting for you. Marks nothing read — the interactive nudge; if it returns > 0, call fetch_messages / list_tasks. |
| accept_taskB | Claim a delegated task before working on it (first accept wins — prevents two agents doing the same work). |
| complete_taskA | Finish an accepted task: success or failure, with the result and optional commit sha / PR url. Auto-notifies the delegator. |
| list_tasksB | List delegated tasks by repo/status/recipient/assignee (the worker's poll). |
| request_approvalB | Park a task for human approval before running it (remote-approve worker mode) — a person approves it from the board/phone. |
| resolve_approvalC | Approve or reject a parked task (used by the board; also callable by tools). |
| heartbeat_workerB | Announce that this worker is online and ready to run tasks (call it every poll so the board shows live presence). |
| propose_intentA | BEFORE you research or write anything: say in plain English what you plan to work on. Returns anyone already doing the same work, matched on meaning rather than file paths — so it catches a duplicate even when you would have picked a different filename. One call per task; it is the cheapest check Tower offers and the only one that fires before your tokens are spent. |
| record_readsA | Record declarations you just read, so your next claim_intent knows what your work is built on. Returns |
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 20 tools
Most tools have clearly distinct roles, and the rich descriptions help separate the claim lifecycle (claim_intent/check_collision/release_claim/complete_claim) from intent proposals (propose_intent) and task flows. However, a couple of pairs invite confusion: heartbeat vs heartbeat_worker, and the trio claim_intent/propose_intent/check_collision all touch pre-work collision checking.
The dominant pattern is predictable verb_noun (claim_intent, release_claim, complete_claim, list_claims, send_message, accept_task, complete_task, list_tasks, request_approval, resolve_approval). A few deviations stand out—heartbeat, heartbeat_worker, pending, next_task—which break the otherwise clean convention.
20 tools is on the heavier side, but the server legitimately spans several subdomains (claims, tasks, messaging, decisions, approvals, presence), so most tools earn their place. A little redundancy exists (pending duplicates part of fetch_messages/list_tasks; two heartbeat tools), but not enough to feel bloated.
Coverage is strong: full claim lifecycle, task delegation/accept/complete with approvals, messaging, decision memory, and presence. Minor gaps remain—no explicit task-creation tool (folded into send_message with kind 'task') and no update/delete for recorded decisions.