Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
LOCKSTEP_API_URLNo

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 20 tools

Disambiguation4/5

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.

Naming Consistency3/5

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.

Tool Count3/5

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.

Completeness3/5

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.

Maintenance

ActivityActive
ResponsivenessNo issues