Every subsystem, as MCP tools.

01 What it is.

The MCP server lives in src/llm_bawt/mcp_server/. It's a FastMCP application registered with a flat namespace where every tool name is prefix-grouped:

Sum: 60 tools. The first 41 live in mcp_server/server.py (1,242 lines); the agent task system tools live in mcp_server/task_tools.py (933 lines) and decorate the same shared mcp instance.

02 Two consumers, one set of functions.

The server has two completely independent consumer paths against the same Python functions:

The function bodies are identical — @mcp.tool(name="memory_search") registers the function as an MCP tool but doesn't change what it does. When llm-bawt's tool executor needs memory_search, it imports and calls the function directly. When VS Code needs it, FastMCP serializes the JSON-RPC call and invokes the same function.

03 Startup and configuration.

The FastMCP instance is constructed in server.py with:

• json_response=True — replies are plain JSON, not chunked.
• stateless_http=True — no per-connection session state. Every call is independent.
• TransportSecuritySettings with DNS rebinding protection enabled — only hosts matching the allowlist may issue requests. Default allowlist: 127.0.0.1:*,localhost:*; override with LLM_BAWT_MCP_ALLOWED_HOSTS.

The server runs inside the same uvicorn worker as the FastAPI service when launched via the app container — service/api.py's lifespan calls _ensure_mcp_server(config) to bring it up. Standalone, it's reachable via llm-mcp-server or python -m llm_bawt.mcp_server with these flags:

04 Memory tools.

Fourteen tools cover everything the memory layer can do. Most operations target a specific bot_id namespace; cross-bot variants are explicit.

05 Messages and sessions.

Fifteen messages_* tools plus four sessions_* tools cover the full conversation-history surface. The interesting one is the soft-delete family — messages_ignore_* moves messages out of search/recall without dropping the row, and messages_restore_ignored reverses it. messages_remove_last_partial drops the trailing assistant message if it's marked partial (used after an aborted stream).

messages_mark_recalled attaches a recall marker to messages a summary was built from — used by the summarization layer to know which raw messages have already been compressed. Sessions are the shared, cross-bot grouping for conversations; tools cover create-implicit (via messages_add), close, get-by-id, list, and get-active.

06 Inter-bot messaging.

Two tools, but they enable real multi-bot workflows:

• bots_list_available() — discovers what bots can receive a message. Filters out bots without memory clients or that explicitly opt out of inter-bot.
• bots_send_message(target_bot_id, message, sender_bot_id, max_tokens, temperature) — runs a one-shot chat completion against the target bot via the internal _dispatch_bot_message helper and returns the response text. The target bot's full pipeline runs; the sending bot sees only the reply.

This is how bots can delegate to specialists. Nova can call out to Snark for snark, or to a code-specialist bot to write a function. Each bot remains responsible for its own memory and personality; the calling bot just sees a tool result.

07 The agent task pipeline.

The 19 tools in task_tools.py wrap the agent task REST API at LLM_BAWT_TASK_API_URL (default http://echo.lan.zenoran.com — the BawtHub frontend, which owns the task DB via Prisma). They exist so agents don't have to hand-roll HTTP calls for what is otherwise a normal CRUD surface.

An agent's typical loop: tasks_get_context for the briefing, steps_update(status="RUNNING"), do work, steps_update(status="COMPLETED", output=...), repeat until task done, then tasks_update(status="REVIEW", response=...).

08 The action-routed profile tool.

Unlike the prefix-grouped tools, profile is a single router tool. Calling shape:

profile(action, entity_type?, entity_id?, category?, key?, value?)

Actions: get, set, delete, list_categories, plus higher-level get_user_summary / get_bot_summary that render the structured profile to a prose paragraph for prompt injection.

09 Fact extraction.

facts_extract is the only tool whose entire job is to invoke an LLM. Given a list of messages, a bot_id, and a user_id, it runs MemoryExtractionService from memory/extraction/ against the maintenance model (default Grok), parses out facts, and optionally writes them into the bot's memory. With store=true, it also walks the extracted facts and routes high-importance ones (default threshold 0.6) into profile_attributes, subject to the ALLOWED_PROFILE_KEYS allowlist and BLOCKED_PROFILE_PATTERNS regex set defined in mcp_server/extraction.py.

The scheduler in service/scheduler.py calls this tool on a cadence to drain completed turns into long-term memory, but external agents can call it ad-hoc against any message bundle they care about.

10 System tools.

Two tools, both essential:

• system_stats(bot_id?) — per-bot counts of messages, memories, summaries, sessions; or service-wide if bot_id omitted.
• system_run_maintenance(bot_id?, run_consolidation?, run_recurrence_detection?, run_decay_pruning?, run_orphan_cleanup?, dry_run?) — kicks off a maintenance cycle. The scheduler runs this on its own cadence; this is the manual override.

11 The storage indirection.

Every tool body looks the same: storage = _get_storage(); return await storage.<op>(...). The storage abstraction in mcp_server/storage.py (935 lines) is the single backend interface — today implemented by PostgreSQLMemoryBackend from memory/postgresql.py, registered via the llm_bawt.memory entry point group.

This separation matters: every MCP tool stays trivial (one line of dispatch plus logging), all the SQL/vector work lives in one place, and a future alternative backend (DuckDB? Qdrant?) can be slotted in by implementing the same interface and changing one config setting.

12 Key files.