Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Why Cerebro Uses MCP: The Right Tool for the Job

The Job Being Solved

The cerebro MCP server solves this specific problem:

Provide AI assistants with standardized, secure access to cerebro’s aggregated developer activity data to enable context-aware assistance during coding tasks.

More specifically:

  • Cerebro collects and processes data from: OpenCode sessions, git commits, TODO comments, manual notes, etc.
  • This data is stored in a cortex (configured via CORTEX_PATH)
  • The value isn’t just in collecting it, but in making it accessible to reduce context switching
  • AI assistants (like those in OpenCode, Claude Code, etc.) need to query this data to provide relevant, personalized assistance

Why MCP is the Right Tool

1. MCP Matches the Data Access Pattern Perfectly

MCP has three core concepts that align exactly with cerebro’s needs:

Resources (for data exposure):

  • Cerebro’s primary asset is its data store
  • MCP Resources are perfect for exposing:
    • Project information (cerebro://projects/{name})
    • Journal entries (cerebro://journal/{date})
    • Intent/goals (cerebro://intent/{period}/{identifier})
    • TODO items (cerebro://todos?project={name})
    • Search results (cerebro://search?query={term})

Tools (for actions):

  • Beyond reading data, users may want to trigger actions:
    • cerebro_build - Trigger a dashboard rebuild
    • add_journal_entry - Add a manual note
    • update_project_status - Mark project as active/inactive
    • refresh_cache - Force data re-collection

Prompts (for predefined interactions):

  • Common query patterns could be predefined:
    • summarize_recent_activity
    • get_project_status
    • find_related_todos

2. Standards-Based Integration Eliminates Custom Work

Without MCP, cerebro would need to:

  • Build custom HTTP/WebSocket APIs for each assistant type
  • Document and maintain separate integrations for OpenCode, Claude Code, etc.
  • Handle authentication, rate limiting, and error handling per integration

With MCP:

  • Implement the MCP protocol once
  • Any MCP-compatible assistant can automatically discover and use cerebro’s capabilities
  • OpenCode, Claude Code, and other MCP hosts handle the client-side complexity
  • Single source of truth for what data/actions are available

3. Security and Boundaries by Design

MCP provides natural security boundaries:

  • The assistant can only access what the MCP server explicitly exposes
  • No risk of arbitrary database access or unintended side effects
  • Tool invocations require explicit approval (configurable via permissions)
  • Read-only resources vs. write-capable tools are clearly distinguished

4. Layering on Existing Infrastructure is Efficient

Cerebro already had:

  • Data collection logic (OpenCode, git, TODOs)
  • Processing and storage systems
  • Dashboard generation algorithms
  • Query capabilities for the web interface

The MCP server is a thin adaptation layer that:

  • Exposes existing functionality through standard MCP interfaces
  • Requires minimal new business logic
  • Leverages all the existing data processing work
  • Avoids re-implementing core cerebro features

5. Enables Ecosystem Benefits

By adopting MCP, cerebro gains:

  • Compatibility with growing list of MCP-hosted assistants
  • Future-proofing as more tools adopt the standard
  • Ability to benefit from MCP ecosystem improvements
  • Reduced integration burden for users trying multiple assistants

Why It’s Not Just a RAG Problem

While cerebro’s data could be used in a RAG (Retrieval-Augmented Generation) system, MCP is more appropriate because:

RAG is a pattern; MCP is a protocol.

  • RAG describes how to retrieve and use context within a single LLM interaction
  • MCP defines how systems connect to provide that context and more

MCP is broader than just retrieval:

  • RAG focuses on fetching relevant information for a prompt
  • MCP also supports invoking actions (tools) and defining interaction patterns (prompts)
  • Cerebro isn’t just about reading data - it may want to allow assistants to trigger builds, add notes, etc.

They can work together:

  • An agent could use MCP to discover what cerebro offers
  • Then use RAG techniques to find the most relevant parts of large datasets
  • Or use MCP resources as the data source for a RAG system

Concrete Example: How an Assistant Uses Cerebro MCP

When a user asks in OpenCode: “What did I work on yesterday in my web-project?”

  1. OpenCode (as MCP host) connects to cerebro-mcp server
  2. Server advertises available resources/tools via MCP protocol
  3. OpenCode sees resources like: cerebro://journal/2026-04-16, cerebro://projects/web-project
  4. OpenCode reads the journal resource for yesterday
  5. Optionally reads project-specific data
  6. Combines this with the user’s question to form a complete prompt for the LLM
  7. LLM responds with a summary of yesterday’s work on web-project
  8. If user wants to take action (e.g., “Mark this project as inactive”), OpenCode can invoke the appropriate MCP tool

Addressing the “RAG-shaped problem” intuition

You’re right that at its core, this is about making data available to augment LLM context - which is what RAG does. However:

  • MCP solves the “how do we get the data to the assistant?” problem (the connection and discovery layer)
  • RAG solves the “how do we find the right data within a large corpus?” problem (the relevance filtering layer)
  • Cerebro needs both layers:
    • MCP provides standardized access to the cerebro data store
    • RAG-like techniques could be used internally by cerebro to rank journal entries by relevance, or by the assistant to process large result sets

MCP is the right foundational choice because it establishes the standard connection mechanism. Whether that data then gets used via simple retrieval, RAG, or other methods is a separate concern that MCP doesn’t prescribe - it simply makes the data available in a standardized way.

Conclusion

The cerebro MCP is the right tool for the job because:

  1. Job: Make cerebro’s developer activity data accessible to AI assistants in a standard, secure way
  2. MCP Fit: MCP’s Resources/Tools/Prompts map directly to cerebro’s data access and action needs
  3. Advantages: Standards-based, secure, leverages existing infrastructure, enables ecosystem benefits
  4. Not Overkill: It’s not unnecessarily complex - it’s the minimally sufficient standard protocol for this exact use case
  5. Complementary: Works well with RAG techniques rather than replacing them

This isn’t just following trends - it’s applying the right tool (MCP) to the right problem (standardized AI assistant access to structured personal data stores).