Mcp-Omega-Brain
# Omega Brain MCP
Omega Brain provides task-scoped memory retrieval, explicit claim evaluation and local audit records for MCP clients.
The standalone 2.3 release replaces unsafe argument steering and uncalibrated approval scores with advisory alignment. SSWP can enforce Brain's operator-policy receipts at its witness entry point. Retrieval uses indexed lexical candidates with stable features; it does not claim dense semantic recall.
Install with `python -m pip install .`, then run `omega-brain-mcp` or `python omega_brain_mcp_standalone.py`. Add that command to your MCP client's persistent user configuration. Data defaults to `~/.omega-brain`; use absolute paths for a portable desktop setup.
Call `omega_preload_context` with `task` and `task_id`, then use the same ID on `omega_rag_query` and `omega_ingest`. `omega_integrity_status`, `omega_brain_report` and `omega_ecosystem_status` expose current health and historical verification limits. `omega_write_handoff` requires `conversation_id` equal to the task ID.
The supplied Python client performs the MCP initialization handshake, bounds requests, drains diagnostics and raises server errors. `omega_call("omega_rag_query", query="deployment decision", task_id="example-task")` performs a scoped lookup.
The companion [Stenographer](https://github.com/VrtxOmega/omega-stenographer-mcp) preserves conversations; [SSWP](https://github.com/VrtxOmega/sswp-mcp) runs software checks. Their shared state directory and task IDs must agree.
See [current operating contract](docs/CURRENT_STATE.md) for migration, permissions, evidence semantics and recovery. Historical manuals and examples describe older contracts; this document and the current MCP schemas take precedence. Legacy network mode is outside the standalone deployment's tested guarantees.
Run `python -m unittest discover -s tests -p "test_contracts.py"` and `python -m pytest tests/test_build_gates.py`. The integration suite lives in `integration-tests/` and uses `OMEGA_SUITE_ROOT` pointing to sibling `omega-brain`, `omega-stenographer`, `sswp` checkouts and a shared `.venv`.
TDQS
Scored across 27 tools
Every tool has a clearly defined role: omega_* tools handle context, storage, alignment, execution, and reporting, while veritas_* tools are specialized gates with discreet purposes and explicit cross-references (e.g., omega_rag_query vs omega_vault_search, omega_cortex_check vs omega_cortex_steer, veritas_evidence_gate vs veritas_compute_quality). The descriptions carefully disambiguate overlapping-sounding tools, so an agent can accurately select the right tool for a given task.
All names follow a consistent snake_case convention with a clear two-part prefix taxonomy: omega_* for brain/memory/governance operations and veritas_* for verification pipeline operations. Verbs and nouns are consistently separated and meaningful (e.g., ingest, search, check, steer, run_pipeline, resolve, transition), making the toolset predictable and scannable.
With 27 tools, the server exceeds the 25-tool threshold that marks an heavily oversized set. While each tool individually has a purpose, the sheer number places a significant cognitive burden on an agent and requires the agent to parse many near-similar gates and helpers; a more consolidated surface (e.g., merging that run_pipeline already wraps individual gates) might be more appropriate.
The toolset covers the full lifecycle of the domain: context loading, semantic storage/retrieval, alignment checking, audit sealing, session persistence, handoffs, and the total VERITAS 10-gate pipeline. Missing pieces are minor (e.g., no individual trace gate, no deletion/update operations for stored fragments), but the does not create blocking gaps for the can be worked around via the pipeline and report tools.