Bicameral
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| bicameral_statusA | Backends, sign-in state, editor models available right now, and history. Call first. |
| bicameral_recallA | Lessons, similar accepted edits and routing track record relevant to a task, plus lessons committed in the repository's .bicameral/lessons.md. Call before planning. |
| bicameral_review_diffA | Review-only mode: an independent model reviews the working tree's diff against a git ref (default HEAD) and returns findings with file:line, each verified to point at a line the diff touches. No plan, no edits. Use when the user asks for a review or a second opinion on a change. |
| bicameral_critiqueA | Ask the editor model to critique your draft plan before anything is edited: under-specified steps, wrong files, missing steps, unverifiable acceptance criteria. Same arguments as bicameral_begin. Revise where it is right, then call bicameral_begin. |
| bicameral_beginA | Register your plan and start a run. Routes each step to you or to the editor model (set pin=true on a step to forbid the router from overriding suggested_role), runs the baseline verification, and returns the routing. editor_model may be 'self' to do every step yourself. |
| bicameral_executeA | Execute one step. Delegated steps are edited by the editor model and come back as a diff plus verification output; steps routed to you return instructions to edit yourself. Pass feedback on retries. |
| bicameral_checkA | After editing a step yourself: diff the workspace against the snapshot, run verification, and get the editor model's second opinion on your diff. |
| bicameral_reviewA | Accept or reject the applied edit for a step. Rejection rolls the files back; feedback goes to the next attempt. |
| bicameral_finishA | Close the run: final verification, outcome logging, lesson storage and scoring. Returns the summary to report. |
| bicameral_statsB | Success rates, routing table, eval results and top lessons. |
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 10 tools
Each tool maps to a distinct phase of the bicameral workflow: pre-flight introspection, plan critique, diff review, run lifecycle, and per-step execution control. Despite some review/check overlap, the described targets (working tree diff vs. applied step edit vs. draft plan) are clearly separated.
All tools share the consistent bicameral_ prefix and snake_case style, and most use verb-like names (begin, execute, check, review, finish). The noun-style names status and stats deviate slightly from the otherwise action-oriented pattern, but the overall scheme is predictable and readable.
Ten tools is well-scoped for a multi-stage editing workflow. Each lifecycle phase has a dedicated tool, and there is no sense of redundancy or unnecessary bloat.
The tool surface covers the full workflow: gather context, review before planning, critique a plan, start a run, execute steps, self-check edits, accept/reject changes, finish, and inspect stats. There are no obvious dead ends or missing lifecycle operations for the stated purpose.