ops-brain
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DATABASE_URL | Yes | PostgreSQL connection string | |
| OPS_BRAIN_LISTEN | No | HTTP bind address | 0.0.0.0:3000 |
| OPS_BRAIN_MIGRATE | No | Run migrations on startup | true |
| OPS_BRAIN_TRANSPORT | No | Transport mode: 'stdio' or 'http' | stdio |
| OPS_BRAIN_AUTH_TOKEN | No | Main bearer token. Required for http transport; a missing or blank token aborts startup unless OPS_BRAIN_DEV_NO_AUTH=true. | |
| OPS_BRAIN_DEV_NO_AUTH | No | Serve HTTP with no auth. Dev only; never expose beyond localhost. | false |
| OPS_BRAIN_AGENT_TOKENS | No | JSON array of identity-bound tokens for /mcp. Enforces identity, not tenant isolation. See docs/agent-tokens.md. | |
| OPS_BRAIN_ALLOWED_HOSTS | No | Comma-separated allowed Host values (DNS-rebinding protection). Set your public hostname when behind a reverse proxy. | loopback only |
| OPS_BRAIN_EMBEDDING_URL | No | OpenAI-compatible embedding API | http://localhost:11434/v1/embeddings |
| OPS_BRAIN_MACHINE_TOKENS | No | JSON array of scoped tokens for POST /api/handoff and GET /api/pending. See docs/machine-callers.md. | |
| OPS_BRAIN_EMBEDDING_MODEL | No | Embedding model name | nomic-embed-text |
| OPS_BRAIN_EMBEDDING_API_KEY | No | Bearer for the embedding API, if it needs one | |
| OPS_BRAIN_EMBEDDINGS_ENABLED | No | Enable embeddings (the example compose file ships with them off) | true |
| OPS_BRAIN_INSTRUCTIONS_EXTRA | No | One line appended to the built-in MCP instructions for this deployment only. No line breaks. Rejected when the initialize text would pass 1400 bytes. |
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 |
|---|---|
| accept_handoffA | Claim a pending handoff and record its acceptor. Bound tokens use their own identity; family credentials and unbound broadcast claims require a concrete agent_name. Follow with complete_handoff. |
| add_knowledgeA | Add a knowledge entry. Cross-agent only: gotchas, safety/compliance rules, verified patterns, vendor behaviour. Host-local lessons belong in your own docs, not here. Requires |
| check_inA | Pending-work query: open action handoffs addressed to you or to nobody in particular (max 20), plus recent notify-class handoffs to you or broadcast (max 5, compact). |
| complete_handoffA | Mark a handoff as completed. Optional |
| create_handoffA | Create a handoff for another agent; this is sufficient notification. Category |
| delete_handoffA | Permanently delete a handoff by ID (hard delete). The delete is audited: audit_log keeps a tombstone with the handoff id, who deleted it, and its sender, recipient, title and status |
| delete_knowledgeB | Delete a knowledge base entry by ID. |
| get_handoffA | Get one handoff by its full UUID, including its complete body and context. |
| list_handoffsA | List handoffs with optional filters. Use status='pending' to see what needs attention. |
| list_replies_to_meA | List handoffs that reply to ones you sent. Returns handoffs whose |
| mark_mergedA | Flip a handoff to status=merged and record the merge commit. Typically called by an integrator script after the bundle containing the handoff's commit_hash lands in main. Idempotent on identical merge_commit; refuses to overwrite a different one. |
| search_busB | Search knowledge and/or handoffs. Set tables param for multi-table. Modes: fts/semantic/hybrid (default). Empty query or '*' browses recent entries. |
| update_knowledgeB | Update an existing knowledge base entry by ID. Only provided fields are updated. |
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 13 tools
The handoff lifecycle actions (create, get, accept, complete, mark_merged, delete) are clearly distinct, and the knowledge tools (add/update/delete) are unambiguous. However, three listing tools overlap heavily: list_handoffs, list_replies_to_me, and check_in all enumerate handoffs with related filters, and search_bus also spans handoffs, so an agent may hesitate over which to pick despite descriptive help.
Nearly all tools follow a clean snake_case verb_noun pattern (list_handoffs, create_handoff, get_handoff, add_knowledge, update_knowledge). Only mark_merged (verb_adjective) and check_in (verb_preposition) deviate slightly, but the convention is otherwise predictable.
13 tools is well-scoped for a coordination server spanning handoff lifecycle plus knowledge management and cross-table search. Each tool earns its place with a discrete operation.
Handoffs have full lifecycle coverage (create, get, list, accept, complete, mark_merged, delete). The knowledge side lacks a dedicated get-by-ID, relying on search_bus brow/search instead, a minor gap an agent can work around.