給任何支援 MCP 的用戶端

只要它懂 MCP，
它就懂 Maguyva。

整合的對象不是逐一工具，而是這個協議本身。Maguyva 是一個標準的 MCP 伺服器，只有一個網址，所以不管你的代理跑在哪裡（Claude Code、Codex、Cursor、Gemini、Windsurf、Antigravity、Zed、Cline，或是你自己打造的工具），都能取得同一份可查詢的程式碼庫地圖。只要索引一次，之後每個連接進來的用戶端，問的都是同樣紮根於事實的問題。

免費開始閱讀 MCP 設定說明

Free 方案：3 個儲存庫, 最多 5 萬行索引儲存庫行數，免信用卡。

一個 MCP 伺服器，適用所有用戶端。不需要逐一工具的外掛，也沒有綁定。

每一層各自負責什麼

四個部分，各司其職。

// 你的用戶端

任何 MCP 用戶端

24 個有文件紀錄的用戶端，包括 Claude Code、Codex CLI、Gemini CLI、Cursor、Windsurf、Antigravity，或是你自己的代理。

// 協定

MCP

這是它們每一個早就已經在講的開放標準。

// 程式碼庫

Maguyva

一台 MCP 伺服器。有憑有據的儲存庫事實，附上 file:line 回傳。

// 誰付錢

以工作區計費，不是席位

代理不用付席位費。查看定價

MCP 就是整合方式，統一採用它。

採用開放協議是正確的選擇，而不是權宜之計。建立在 MCP 之上、而不是逐一工具的外掛，正是避免每次有更好的代理問世就得重新整合一次的方法。這裡適合放：

一份能套用到任何相容用戶端的伺服器設定區塊。
能跨編輯器、CLI 與代理攜帶的工具與資源。
安全團隊只需審查一次、不必逐一廠商審查的邊界。
換用戶端時不必重建整套脈絡技術堆疊的自由。

繼續這樣做，統一採用 MCP 就是對的方向。

但協議只是一條管道，負責搬運問題與答案——它並不認識你的程式碼庫。管道的另一端，必須要有真正能對應你符號、呼叫點與依賴關係的東西。

逐一工具的脈絡方案在哪裡無法擴展

四種失效模式，沒有一個代理的規則檔案能單獨解決。

// 每個工具都要從零開始上手

換一個新代理，它對你的程式碼庫又是兩眼一抹黑。你得重新貼上同樣的檔案、重新釘選同樣的脈絡、重新寫同樣的規則。這些工作無法轉移，因為它從來就不是共享的一層。

// 規則檔案不會跟著你走

CLAUDE.md、.cursor/rules、AGENTS.md——每一個都是特定工具專屬的，沒有一個是可查詢的程式碼索引。換用戶端之後，你手動建立的地圖就留在原地了。

// 整合綁定是一種稅

把深度的程式碼庫脈絡接到某個廠商的外掛裡，代表哪天你想換用另一個代理，就得重建一次。你的脈絡做得越好，離開的代價就越高。

// 協議是管道，不是地圖

MCP 負責在用戶端與伺服器之間搬運工具與脈絡，但它並不認識你的符號、呼叫點或依賴關係圖。管道的另一端，必須要有真正能回答問題的東西。

Maguyva 就是協議另一端的那一層

它不是另一個代理，而是任何 MCP 用戶端都能呼叫的程式碼庫脈絡伺服器：

一個端點，適用所有用戶端 同一個 https://maguyva.tools/mcp，服務 Claude Code、Codex CLI、Gemini CLI、Cursor、Windsurf、Antigravity，或是你今天早上才寫的腳本。
語意 + AST + 圖譜 + 文字 依語意、結構、依賴關係，或字面文字搜尋。不管是哪個用戶端發出請求，每一筆命中結果都會回傳檔案路徑與行號。
感知分支，跨套件 Maguyva 看得到代理正在編輯的那個程式碼版本，涵蓋整個 monorepo 裡的每一個套件。
沒有廠商綁定 隨時想換代理就換；上下文層不會跟著搬家。以工作區計費，不是按席位計費——索引 1 個儲存庫，還是 50 個，都一樣。

你的用戶端懂 MCP。
Maguyva 就是它問起你的程式碼時，會回答的那一方。

三種工作流程，每個用戶端都一模一樣

跨套件、跨語言。用戶端會換，但紮根的答案不會變。

// workflow 01

從任何代理出發，找出跨套件的驗證流程

agent> 這個 monorepo 裡，驗證邏輯發生在哪裡？

graph::query("驗證流程")
  packages/web/src/auth/session.ts:42       中介層
  packages/api/src/auth/jwt.ts:88           權杖驗證
  packages/shared/src/auth/types.ts:12      AuthContext
  packages/admin/src/auth/admin-only.ts:31  RBAC 閘門

→ 4 個進入點，橫跨 4 個套件，依呼叫點密度排序。
[exit 0]

Claude Code、Cursor，或是你自己寫的腳本——是哪個用戶端送出查詢並不重要。回來的都是同樣的四個檔案、同樣的排序，紮根於真實的圖譜。

// workflow 02

找出真正的實作，而不是測試 mock

agent> normalizePhoneNumber 是怎麼處理 E.164 格式的？

semantic::query("正規化電話號碼 E.164")
  packages/shared/util/phone.ts:88     normalizePhoneNumber()  ← 真正的實作
  packages/api/test/phone.spec.ts:14   jest.mock(...)          ← mock
[exit 0]

名字會騙人，mock 會掩蓋真正的程式碼。不論是哪個用戶端來問，Maguyva 都會把真正的實作排在測試 mock 之前。

// workflow 03

重構前先確認影響範圍

agent> 這個 monorepo 裡，誰呼叫了 QueueDispatcher.publish？

graph::callers(QueueDispatcher.publish)
  packages/billing/* 中有 3 筆
  packages/audit/* 中有 1 筆
  packages/notifications/* 中有 1 筆
  services/python-worker/* 中有 1 筆  ← 跨語言，透過 gRPC stub
[exit 0]

跨套件，遇到多語言程式碼庫時也跨語言，呼叫點會直接顯示在結果中。就算明天換一個代理，影響範圍的資訊依然還在，因為它存在於伺服器端，而不是用戶端。

在任何 MCP 用戶端中設定

三個步驟。Free 方案：3 個儲存庫, 最多 5 萬行索引儲存庫行數，免信用卡。

// step 01
在 maguyva.ai 索引一個程式碼庫
挑一個你熟悉的儲存庫，這樣你才能驗證答案是否正確。Free 方案涵蓋 3 個儲存庫, 最多 5 萬行索引儲存庫行數。

// step 02

在你使用的任何用戶端中，把 Maguyva 加為 MCP 伺服器

// 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
問一個你已經知道答案的問題
從一個程式碼庫、一個可驗證的問題開始，例如「跨套件有誰呼叫了 formatInvoice？」如果答案跟你預期的一樣，之後你指向的每一個用戶端，都會得到同樣紮根於事實的結果。