agnt-lock
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.
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 |
|---|---|
| acquire_lockA | Acquire an exclusive lock on a file before editing. Prevents other AI agents from modifying the same file simultaneously. Returns lock status and blocker info if already locked. |
| release_lockA | Release a previously acquired lock on a file. Call this after finishing edits to allow other agents to work on the file. The intent is committed to session history. |
| get_repo_stateA | Get the current coordination state of the repository. Shows all active locks, which agents are working, and recent intent history. Use this before starting work to understand what other agents are doing. |
| force_release_allA | Emergency: Force-release ALL active locks. Use only when agents are stuck or locks are stale. This will free every locked file in the repository. |
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 4 tools
Each tool has a clearly distinct purpose: acquiring, releasing, viewing state, and emergency release. The only potential overlap is between release_lock and force_release_all, but their scopes (single vs. all) and contexts (normal vs. emergency) make them unambiguous.
All tool names follow a consistent verb_noun pattern: acquire_lock, release_lock, get_repo_state, force_release_all. The verbs and nouns are descriptive and match their functionality, making the set predictable and coherent.
With 4 tools, the server is well-scoped for a lock management purpose. Each tool covers a necessary operation without redundancy, and the count falls comfortably within the ideal 3-15 range.
The server covers the full lock lifecycle: acquire, release, query state, and emergency cleanup. The only minor gap is a lack of a per-file lock check endpoint, but get_repo_state provides sufficient visibility into lock status.