For any MCP-enabled client

If it speaks MCP,
it speaks Maguyva.

The integration isn’t per-tool — it’s the protocol. Maguyva is a standard MCP server at one URL, so whatever your agent runs in (Claude Code, Codex, Cursor, Gemini, Windsurf, Antigravity, Zed, Cline, or something you built yourself) gets the same queryable map of your repo. Index once, and every client you connect asks the same grounded questions.

Index your first repo Read the MCP setup

Public beta. Free tier: 3 repos, 50K indexed lines, no card.

One MCP server. Every client. No per-tool plugin, no lock-in.

What each layer does

Four pieces. Each one has a job.

// your client

Any MCP client

24 documented clients, including Claude Code, Codex CLI, Gemini CLI, Cursor, Windsurf, Antigravity, or your own agent.

// protocol

MCP

The open standard every one of them already speaks.

// codebase

Maguyva

One MCP server. Grounded repo facts, returned with file:line.

// who pays

Workspaces, not seats

Agents don’t pay seats. See pricing

MCP is the integration. Standardize on it.

The open protocol is the right call, not a workaround. Building on MCP instead of a per-tool plugin is exactly how you avoid re-integrating every time a better agent ships. It is the right place for:

One server config block that drops into any compliant client.
Tools and resources that are portable across editors, CLIs, and agents.
A boundary your security team can review once, not per vendor.
Freedom to switch clients without rebuilding your context stack.

Keep doing that. Standardizing on MCP is the move.

But a protocol is a pipe. It carries the question and the answer — it does not know your codebase. Something has to be on the other end that actually maps your symbols, call-sites, and dependencies.

Where per-tool context stops scaling

Four failure modes that no single agent’s rules file can fix.

// every tool re-onboards from zero

Pick a new agent and it starts blind on your repo again. You re-paste the same files, re-pin the same context, re-write the same rules. The work doesn’t transfer because it was never a shared layer.

// rules files don’t travel

CLAUDE.md, .cursor/rules, AGENTS.md — each is per-tool, and none is a queryable index of your code. Switch clients and the map you built by hand stays behind.

// integration lock-in is a tax

Wiring deep codebase context into one vendor’s plugin means the day you try a different agent, you rebuild it. The better your context, the more it costs to leave.

// the protocol is a pipe, not a map

MCP moves tools and context between client and server. It does not know your symbols, call-sites, or dependency graph. Something has to be on the other end that actually answers the question.

Maguyva is the layer on the other end of the protocol

Not another agent. The repo-context server that any MCP client can call:

One endpoint, every client the same https://maguyva.tools/mcp serves Claude Code, Codex CLI, Gemini CLI, Cursor, Windsurf, Antigravity, or a script you wrote this morning.
Semantic + AST + graph + text search by meaning, structure, dependency, or literal. Every hit returns a file path and line number, whichever client asked.
Branch-aware, cross-package Maguyva sees the version of the code the agent is editing, across every package in the monorepo.
No lock-in switch agents whenever you like; the context layer doesn’t move. Workspace pricing, not per-seat — index 1 repo or 50.

Your client speaks MCP.
Maguyva is what answers when it asks about your code.

Three workflows, identical from every client

Cross-package, cross-language. The client changes; the grounded answer doesn’t.

// workflow 01

Find the auth flow across packages, from any agent

agent> where does authentication happen in this monorepo?

graph::query("authentication flow")
  packages/web/src/auth/session.ts:42       middleware
  packages/api/src/auth/jwt.ts:88           token verify
  packages/shared/src/auth/types.ts:12      AuthContext
  packages/admin/src/auth/admin-only.ts:31  rbac gate

→ 4 entry points across 4 packages, ranked by call-site density.
[exit 0]

Claude Code, Cursor, or your own script — it doesn’t matter which client sent the query. The same four files come back in the same ranking, grounded against the real graph.

// workflow 02

Find the real implementation, not the test stub

agent> how does normalizePhoneNumber handle E.164?

semantic::query("normalize phone E.164")
  packages/shared/util/phone.ts:88     normalizePhoneNumber()  ← real impl
  packages/api/test/phone.spec.ts:14   jest.mock(...)          ← stub
[exit 0]

Names lie. Mocks shadow real code. Maguyva ranks the real implementation above the test mock — the same way for every client that asks.

// workflow 03

Check blast radius before a refactor

agent> what calls QueueDispatcher.publish across the monorepo?

graph::callers(QueueDispatcher.publish)
  3 in packages/billing/*
  1 in packages/audit/*
  1 in packages/notifications/*
  1 in services/python-worker/*  ← cross-language via gRPC stub
[exit 0]

Cross-package, and cross-language on a polyglot repo, call-sites surface inline. Switch agents tomorrow and the blast radius is still there, because it lives in the server, not the client.

Setup with any MCP client

Three steps. Free tier: 3 repos, 50K indexed lines, no card.

// step 01

Index a repo at maguyva.ai

Pick one you know well so you can verify the answers. Free tier covers 3 repos, 50K indexed lines.

// step 02

Add Maguyva as an MCP server in whatever client you use

// any MCP client: add a remote MCP server
{
  "mcpServers": {
    "maguyva": {
      "url": "https://maguyva.tools/mcp",
      "headers": {
        "Authorization": "Bearer <your-key>"
      }
    }
  }
}

// CLI clients can use the same endpoint:
//   https://maguyva.tools/mcp

// step 03

Ask one question whose answer you already know

Start with one repo and one verifiable question, like “what calls formatInvoice across packages?” If the answer matches what you’d say, every other client you point at it will get the same grounded result.