agent-semaphore
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Coordination protocol for this repository (agent-semaphore):
After planning and BEFORE sustained edits, call
claimwith your expected scope (prefer whole directories likesrc/api/, not single files), a reason, and your task id. If blocked, read the conflict answer: narrow your scope, pick non-overlapping work, or wait for the lease to expire.If a file edit is denied or warned by the repo's write hook, do what the message says (usually: claim first, or stay out of another agent's scope). Never retry a denied write unchanged.
Lockfiles, migrations, generated code and CI config are protected classes: they always require your own exclusive claim.
When your branch is ready: commit, then
enqueue_land. Never merge to the target branch yourself. If your land is bounced, fix the rebase in YOUR worktree (your context is freshest) and enqueue again.Call
checkbefore expanding into new files;release(retain=true if your branch still awaits landing) when done. Readnoticesin every response and act on them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| claimB | Atomically claim path scopes (dir/ preferred, file, or basename glob) before editing them. Blocked responses name the holders, their intent, lease remaining, and advice (wait | narrow_scope | coordinate | steal_candidate). |
| releaseB | Release my claims (all, or those matching the given scope patterns). retain=true keeps them alive until my branch lands (use when work is committed but not yet merged). |
| checkA | Read-only: who holds these paths/scopes right now (holders with intents, hot-class membership). Call before expanding your edit scope. |
| statusB | Live coordination picture: agents, claims with intents, integration queue, wait tickets, stale items. |
| extendC | Extend one of my leases (activity usually renews them automatically). |
| report_intentB | Declare what you PLAN to touch (no blocking): records an intent claim and returns overlaps with other agents' claims and intents so overlapping tasks can be serialized before work starts. |
| radarA | Cross-worktree conflict prediction: dry-run merges (git merge-tree) between every dirty worktree snapshot and the integration target. TEXTUAL/STRUCTURAL pairs mean your uncommitted direction already collides with someone — coordinate now, not at merge time. UNSTABLE means a snapshot tore mid-scan: rerun. |
| enqueue_landA | Enqueue my branch for serialized, test-gated landing into the integration
target. My active claims become retained until the land completes. The queue is
processed by |
| land_statusB | Status of land-queue entries. Bounce/park results carry conflict files and exact instructions — a bounced entry means YOU rebase and fix in your worktree, then enqueue again. |
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 9 tools
Most tools have clearly distinct roles: claiming, releasing, extending, conflict prediction, enqueueing, and status inspection. The closest overlaps are check vs. status (scoped vs. global read-only views) and claim vs. report_intent (blocking vs. non-blocking declaration), but the descriptions make those distinctions reasonably clear.
The naming mixes bare verbs (claim, check, release, extend), verb_noun forms (report_intent, enqueue_land), and noun-style names (radar, status, land_status). It is still readable and none of the names are cryptic, but there is no predictable naming convention across the set.
Nine tools is well-scoped for an agent coordination server covering claims, intents, conflict detection, and landing. Each tool appears to earn its place without obvious redundancy in count.
The surface covers the main lifecycle: discovery, claiming, releasing, extending, intent reporting, conflict prediction, enqueueing, and status checking. Minor gaps remain, such as no explicit cancel/dequeue operation for a land-queue entry or intent revision, but core workflows are supported.