brindley
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
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_collectionA | Mark a folder as a collection: adds |
| 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 |
| 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 |
| 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 |
| 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 |
| set_dependenciesB | Add or remove |
| completeB | Mark an initiative done. |
| 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
| Name | Description |
|---|---|
| design-review | Work through an initiative's open questions with the user, one at a time, grounded in the code. |
| implement | Hand-off brief for an agent implementing one initiative. |
| triage | Review 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
| Name | Description |
|---|---|
| index | Overview of all collections, cross-collection dependencies and themes |
TDQS
Scored across 20 tools
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.
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.
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.
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.