lockstep
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOCKSTEP_API_URL | No |
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 |
|---|---|
| notifyA | Publish a change to the project's change feed so other teams' agents see it. Use for something that already changed or is about to; use ask to pose a question and propose_decision to record a rule. Optionally tied to a surface (for example http:POST /session) with a contract delta. Risk tier owned publishes immediately; shared and contract changes wait for confirmation. Changes with a surface are delivered to repos that declared a dependency on it. Returns the change id, publish state, delivered count and impact (number of consuming repos). |
| inboxA | List this session's unread inbox items: changes, questions, tasks, decisions and conflicts. Does not mark them read; use ack_inbox for that. Use query instead to search the ledger by topic, and decisions to list decisions. |
| ack_inboxA | Mark inbox items as read by id. With no ids, marks every unread item in this session's inbox. Returns the acknowledged count. This only clears inbox items; to respond to a decision use ack_decision, and to reply to a question use answer. |
| queryA | Search the project's decisions, changes and answered questions for a natural-language question. The optional scope boosts matching results in the ranking rather than filtering them. Returns rows; the calling agent writes the answer. Read-only, nothing is sent to anyone; use ask when the ledger has no answer and a teammate should respond. |
| askA | Ask the project a question, optionally tied to a scope. It is delivered to the project's inboxes; urgent flags it. Returns the question id and status. Use for a question that needs a person or another team to reply; try query first, since it searches existing answers without notifying anyone. Replies are recorded with answer. |
| answerA | Answer a question from the project's inbox by its questionId. Records the response as an answer, marks the question answered and returns the answer id and status. Use ask to raise a question; answer is only for replying to one. Writes a permanent record; the call does not check that the question is still unanswered, so a second call adds another answer. |
| delegateA | Create a task from a description, with optional refs. The required to value is the assignee's GitHub login; if no member matches, the task is created with no assignee. Returns the task id and run state. Creates an open task and notifies the assignee through their inbox. Use complete to close it later; use ask instead if you only need an answer. |
| completeA | Mark a task closed by its taskId. The optional note is accepted but not currently stored. Sets the task to done and closed and returns the status; the call does not check who the assignee is. Use for a task created with delegate. |
| propose_decisionA | Propose a decision (rule, architecture or principle) for a scope, with optional rationale, rejected alternatives and review date. Uses optimistic concurrency: baseVersion must equal the decision's current version (0 for a new decision), otherwise the call fails with a conflict. Owner-scoped decisions bind immediately; shared or cross-cutting ones stay open until acknowledged. |
| ack_decisionA | Acknowledge a decision version. An ack or approve verdict (default ack) moves an open decision to binding. Records your review in the audit trail either way and returns the decision status. Use for a decision proposed by someone else that is awaiting acknowledgement; use propose_decision to create or change one, and decisions to find ids and versions. |
| register_dependencyA | Declare that this repo consumes a surface (for example http:GET /orders/:id), so changes to that surface are delivered to this repo. producedRepoId optionally names the producing repo. Repeating the same declaration is harmless. Changes to a declared surface then reach this repo through notify and its inbox. Use consumers to see who depends on a surface. |
| decisionsA | List the project's decisions, optionally filtered by scope. Read-only. Returns each decision with its id, scope, status (for example open or binding), version, rule text and review fields. Use query to search by topic instead, and check_decisions to test a diff against decisions. |
| whoownsA | Return the owners of a file path from the repo's current ownership snapshot (CODEOWNERS). Empty when there is no snapshot or no match. Read-only. Use before asking or delegating to find the right person; use consumers for who depends on a surface. |
| consumersA | List the repos that consume a surface, from the declared-dependency graph. Read-only. Only dependencies declared with register_dependency or found by scanning appear. Use before changing a surface to see who is affected; use whoowns for file owners. |
| get_product_contextA | Return the full product constraints and governed surfaces for a capability, surface or text scope, plus project principles. Constraints are empty when the product layer is off for the project. Read-only. Use before building a feature to learn the product rules for it. |
| set_feature_contextA | Set the active capability reference for this session. Writes local state and a feature-context file for the checkout's git remote when one exists. Later notify and propose_decision calls use it unless they pass their own capabilityRef. Call it when starting work on a feature; it changes only local state and never contacts the server. |
| check_decisionsA | Check the working-tree diff against accepted decisions. Returns status skipped unless hosted diff checks are enabled (lockstep checks on). The optional base is the git ref to diff against. Uploads the diff of tracked changes (untracked files are not uploaded) to the Lockstep server and returns the findings: possible contradictions with accepted decisions, each with file, line and the rule. Findings are advisory; use decisions to read the decisions themselves. |
| session_briefingA | Return the continuity briefing for this session: what changed and what is binding, scoped to the current feature context when one is set. Read-only. Call at the start of a session or after being away; use inbox for unread items addressed to you and decisions for the full list. |
| refresh_decision_packA | Download the compiled decision pack and rewrite the generated local decision-pack skill in the working directory. Returns the pack hash, file path, whether the file changed and counts. Writes local files. Call when decisions may have changed and the local skill is stale; it does not change any decision on the server and takes no input. |
| sync_skillsA | Sync managed organization skills into this checkout. Returns not_enrolled unless the checkout was enrolled with lockstep enroll. Installed or updated skills load from the next session. Writes local files in the checkout. Takes no input; use refresh_decision_pack for decisions instead of skills. |
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 distinct resource/action targets, and descriptions explicitly cross-reference alternatives such as query vs ask, inbox vs decisions, and refresh_decision_pack vs sync_skills. Some read-oriented tools (session_briefing, inbox, decisions, query) overlap conceptually but remain distinguishable.
Names are mostly lowercase snake_case and readable, but conventions are mixed: some are verb_noun (propose_decision, register_dependency), some are noun-only (inbox, decisions, consumers), and whoowns breaks the underscore pattern. The set is understandable but not predictably uniform.
Twenty tools is heavy for a single MCP server and sits in the borderline 16-25 range. The broad collaboration domain justifies many capabilities, but the surface feels near the upper bound for easy agent selection.
Core areas such as decisions, inbox, questions, changes, dependencies, and context are covered, but lifecycle gaps remain: tasks only support delegate and complete without list/get/update, and changes or dependencies lack direct listing/removal operations. These are notable gaps that could force workarounds.