system-brain-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SYSTEM_BRAIN_DB | No | SQLite path for db_schema and analytics | |
| SYSTEM_BRAIN_ARCH_DOCS | No | Colon-separated markdown files describing your system | |
| SYSTEM_BRAIN_MODELS_DIRS | No | Colon-separated directories holding model artifacts | |
| SYSTEM_BRAIN_DEPLOY_MANIFEST | No | Path to the manifest that init wrote | |
| SYSTEM_BRAIN_OBSIDIAN_VAULTS | No | JSON object mapping vault name to path, e.g. {"Name":"/path"}. Optional. Used for backlog --includeVault and roadmap. | |
| SYSTEM_BRAIN_FABRICATION_DIRS | No | Colon-separated directories to scan for fabricated values |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| brain_where_deploysA | Resolve the canonical deploy target for a file/path and cross-check it against repo config. |
| brain_backlogB | Unified open items across GitHub PRs/issues and local git. |
| brain_db_schemaA | List tables in the configured local SQLite database, or (with |
| brain_ml_modelsA | List on-disk ML model artifact files across configured model directories. Presence on disk does NOT mean a model is loaded or active. |
| brain_analyticsB | Row counts and recency for known prediction/feedback tables in the local dev SQLite database. Honestly labeled as local/dev, not production; flags feedback famine. |
| brain_architectureA | Curated architecture docs (gateway skills). No |
| brain_fabrication_auditA | Read-only static scan for fabricated-core leaves (Math.random()-fed confidence/accuracy/score/decision values) across configured engine directories. A signal, not proof ; verify each finding against stub-detection-audit before certifying REAL/ABSENT. |
| brain_lensesA | List available reasoning lenses (mental models / thinker-inspired frames) for framing a decision. |
| brain_roadmapA | Scan configured Obsidian vaults for plan/roadmap/next-steps notes (filename-matched, most-recently-modified first) and count their open |
| brain_recommendA | Rank next steps from the brain's own read-only evidence (analytics, backlog, models; |
| brain_reframeA | Reframe a real brain_recommend recommendation (looked up by |
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 11 tools
Each tool targets a distinct resource or action: deploys, backlog, DB schema, ML models, analytics, architecture docs, fabrication audit, lenses, roadmap, recommend, and reframe. Descriptions clearly separate related tools like db_schema vs. analytics and backlog vs. roadmap.
All tools share the 'brain_' prefix, creating a clear family, but the suffixes mix nouns (backlog, analytics, architecture), verbs (recommend, reframe), and query-like phrases (where_deploys). This is mostly consistent but not a strict verb_noun pattern.
11 tools is well within the ideal range for a decision-support brain. Each tool covers a discrete capability needed for the apparent domain, and none feel redundant or superfluous.
The tool surface covers the full gather-analyze-recommend-reframe loop using available evidence sources. Minor gaps exist—e.g., no direct GitHub issue/PR detail lookup beyond the backlog aggregate, and no tool for explicit doc searches—but agents can work around these.