Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
create_collectionA

Mark a folder as a collection: adds brindley: 1 and the given details to its README.md front-matter, creating the folder and README if needed. Works on a folder that already holds numbered initiative files. The first collection in a repo also returns the agent-instructions snippet for AGENTS.md / CLAUDE.md.

update_collectionC

Edit a collection README's details, including its status (active | done | abandoned).

collectionsB

Every collection with its details, counts by initiative status, and number ready.

listC

List initiatives (whole root unless collection is given), optionally filtered.

getB

Full detail of one initiative, including its dependency report (each dependency classified satisfied / blocking / external / missing), dependants, open questions and acceptance criteria.

readyB

Initiatives that are designed with nothing blocking — what an agent can pick up now — in suggested order (prerequisites first).

graphB

Dependency graph as an adjacency list plus Mermaid: a collection's active work, one initiative's neighbourhood, or a tag (theme) across collections.

questionsC

Unresolved open questions, grouped by initiative.

next_questionB

The next unresolved blocking question in one initiative (after after, if given), with the count remaining. Drives the design-review conversation.

tagsA

Every tag (theme) in use plus declared-but-unused ones, with descriptions and counts by status.

validateA

Check initiatives and collection structure: missing or unknown statuses, status vs folder vs body-prose disagreements, files not in their collection's status folder, duplicate numbers, dangling references, cycles, broken links (with where a moved file now lives), stale READMEs. Returns errors and warnings with file and line.

check_docsA

Lint project docs for history phrasing, design debate and links into initiatives (docs must describe only what the code is). Defaults to docs changed vs HEAD.

createC

Create a new initiative. The number is coined automatically by scanning the working tree, other worktrees, branches and history. A folder path that isn't a collection yet is marked as one.

updateB

Edit an initiative's front-matter fields or H1, or replace a named body section. Cannot change its number or filename.

set_statusB

Change status, enforcing the lifecycle: designed needs no blocking open questions; in-progress needs ready; done goes through complete.

add_questionB

Add an open question. A blocking question moves a designed initiative back to draft. Use implementation=true for questions deliberately left to the implementer.

resolve_questionB

Resolve an open question. Default mode "remove": delete it and record the decision in record_in (default "Decisions", e.g. "Agreed direction"). Mode "tick": keep it as "- [x] … — answer".

set_dependenciesB

Add or remove depends_on (blocking) and related (non-blocking) entries. Refuses unknown initiatives and cycles.

completeB

Mark an initiative done. docs_impact is required: the project doc paths updated in this change, or "none: ". Reports which initiatives became ready.

regenerate_readmesA

Rebuild the generated README blocks (tables + Mermaid). check=true only reports what is stale (for CI).

Prompts

Interactive templates invoked by user choice

NameDescription
design-reviewWork through an initiative's open questions with the user, one at a time, grounded in the code.
implementHand-off brief for an agent implementing one initiative.
triageReview the initiatives: stale drafts, unresolved questions, blocked chains, unconfirmed external dependencies, and what to pick next.

Resources

Contextual data attached and managed by the client

NameDescription
indexOverview of all collections, cross-collection dependencies and themes

TDQS

B3.3/5.0

Scored across 20 tools

Disambiguation4/5

Most tools target distinct resources/actions (collections vs initiatives, list vs get vs ready, validate vs check_docs). A few boundaries blur: update/set_status/complete all touch status (set_status explicitly delegates done to complete), and questions/next_question overlap in surface. Descriptions generally clarify these, so misselection is limited.

Naming Consistency3/5

Mutations follow a verb_noun pattern (create_collection, set_status, add_question, set_dependencies, regenerate_readmes), but queries and core ops use bare nouns or verbs (collections, list, get, ready, graph, tags, create, update, complete). It is readable but mixes conventions rather than following one predictable scheme.

Tool Count4/5

20 tools is on the heavy side, but the domain (initiatives, collections, lifecycle, dependencies, questions, graph, validation, docs linting) is genuinely rich and each tool maps to a real workflow. A couple could arguably be folded together (next_question into questions), keeping it just short of ideal.

Completeness4/5

The initiative lifecycle is well covered: create, update, set_status, complete, questions, dependencies, plus collections and validation. The notable gap is deletion/removal—there is no tool to delete an initiative or collection, so the surface is not fully CRUD-complete.

Maintenance

ActivityMaintained
ResponsivenessNo issues