MCP server

SecondOS speaks the Model Context Protocol, so any MCP-capable AI tool reads your codebase map through one interface. One sync, one growing toolset, every editor.

How it fits together

You sync a repo with the CLI. The map and embeddings live in the cloud (or your self-hosted instance). The MCP server exposes that map to your tools. Nothing re-scans your repo per tool, and nothing re-explains context per session.

your repo → CLI push → map + vectors
                          │
                    MCP server
        ┌─────────────┼─────────────┐
     Cursor      Claude Code     Copilot

The tools

Every connected tool gets the same surface. The ten codebase tools:

• project_overview — A structure-aware summary of the repo: what it is, its shape and its entry points.
• search_codebase — Hybrid lexical + semantic search over the map, including symbol bodies when deep-synced.
• recent_activity — What changed recently, from git re-entry, so a tool starts where the last one left off.
• who_uses — Callers of a symbol, resolved across modules in TS/JS, Go, Python, Rust, Java, PHP and Ruby, ranked by confidence.
• impact_of — Blast radius of a change across the resolved call graph: what will break vs what might break.
• schema_drift — Columns your code writes that the Drizzle schema does not have. A read-only alert with both locations.
• schema_timeline — How the database schema evolved over time, so an agent can see when a table or column arrived.
• schema_at — The schema as it stood at a given point, so a question about the past reads the past shape.
• cross_repo_drift — Drift across repos in a workspace: shared contracts and conventions that have diverged.
• symbol_detail — The full record for one symbol: signature, location, callers and callees.

Plus seven memory tools (remember, recall, capture_decision, ingest_issues, memory_history, restore_memory, reconcile_memories) and five context tools (get_context_pack, read_doc, read_living_doc, what_changed_since, and prime: a memory-first orientation call that hands a new agent the index before it even asks). Twenty-two in all: codebase memory only, no action layer.

Two of those pull knowledge in from where decisions actually get made. ingest_issues reads a linked repo's recent issue and pull-request discussions and distils the durable decisions into reviewable proposals (opt-in, manual, read-only, human-accepted), and a PR-sourced note binds to the file the PR touched so it can go stale when that code moves. read_living_doc serves the LLM-generated living docs straight into an agent, so it reads the architecture someone already wrote down instead of re-deriving it.

Connecting a tool

The fast path: run bunx @secondos/cli mcp-config to print the ready-to-paste configuration for Cursor, Claude Code, Claude Desktop, Windsurf and VS Code. Copy, paste, done. Under the hood it is a small JSON entry pointing at the server command:

{
  "mcpServers": {
    "secondos": {
      "command": "bunx",
      "args": ["@secondos/cli", "mcp"]
    }
  }
}

Once connected, the tool can call any of these tools above against your synced map. If your tool supports it, memory writes go through the same protocol, so notes are validated and bound to real symbols.

That's the local path (stdio). For a hosted agent that can't spawn a process (a claude.ai custom connector or ChatGPT), connect over HTTP with a project-scoped token instead. See Remote MCP.

Privacy note

The MCP server serves the map, never your source, because the source was never uploaded in the first place. See security for the full boundary.

Next

Head to the CLI reference for sync options, or back to the quickstart.