// あなたのクライアント
あらゆるMCPクライアント
23件のドキュメント化されたクライアント(Claude Code、Codex CLI、Gemini CLI、Cursor、Devin Desktop、Antigravityを含む)、または自作のエージェントにも対応。
MCP対応のあらゆるクライアント向け
統合はツールごとではなく、プロトコル単位です。Maguyvaは、ひとつのURLにある標準的なMCPサーバーです。だから、あなたのエージェントがどこで動いていても(Claude Code、Codex、Cursor、Gemini、Devin Desktop、Antigravity、Zed、Cline、あるいは自作のものでも)、同じ問い合わせ可能なリポジトリの地図を得られます。一度インデックス化すれば、接続するすべてのクライアントが、同じ根拠のある質問をできます。
Freeプラン: リポジトリ3個, インデックス済みリポジトリ行数、最大5万行、カード不要。
MCPサーバーはひとつ。クライアントはどれでも。ツールごとのプラグインもロックインもなし。 4つのパーツ。それぞれに役割があります。
// あなたのクライアント
23件のドキュメント化されたクライアント(Claude Code、Codex CLI、Gemini CLI、Cursor、Devin Desktop、Antigravityを含む)、または自作のエージェントにも対応。
// プロトコル
そのすべてが既に話している、オープンな標準規格。
// コードベース
MCPサーバーはひとつだけ。裏付けのあるリポジトリの事実を、file:line付きで返します。
// 支払うのは誰か
エージェントはシート料金を払いません。料金を見る
オープンプロトコルは、次善策ではなく正解です。ツールごとのプラグインの代わりにMCPの上に構築することこそ、より良いエージェントがリリースされるたびに再統合する羽目になるのを避ける方法です。以下のことを実現するのに適しています:
それは続けてください。MCPを標準にすることこそが、正しい一手です。
しかし、プロトコルはただの管です。質問と答えを運びますが、あなたのコードベースを知っているわけではありません。あなたのシンボル、呼び出し箇所、依存関係を実際にマッピングする何かが、反対側になければなりません。
どのエージェント単体のルールファイルでも解決できない、4つの失敗モード。
新しいエージェントを選べば、また何も見えない状態からリポジトリに向き合うことになります。同じファイルを貼り直し、同じコンテキストをピン留めし直し、同じルールを書き直す。共有レイヤーだったことが一度もないから、作業は引き継がれません。
CLAUDE.md、.cursor/rules、AGENTS.mdは、どれもツールごとのもので、あなたのコードを問い合わせ可能にするインデックスではありません。クライアントを乗り換えれば、手作業で作った地図は置き去りになります。
深いコードベースのコンテキストを、ひとつのベンダーのプラグインに組み込むということは、別のエージェントを試す日に、それを作り直すということです。コンテキストが優れているほど、離れるコストは高くなります。
MCPは、クライアントとサーバーの間で、ツールとコンテキストを運びます。あなたのシンボル、呼び出し箇所、依存関係グラフを知っているわけではありません。質問に実際に答える何かが、反対側になければなりません。
別のエージェントではありません。あらゆるMCPクライアントが呼び出せる、リポジトリコンテキストサーバーです:
https://maguyva.tools/mcpが、Claude Code、Codex CLI、Gemini CLI、Cursor、Devin Desktop、Antigravityにも、今朝あなたが書いたスクリプトにも対応します。 あなたのクライアントはMCPを話す。
Maguyvaは、あなたのコードについて尋ねられたときに答えるもの。
パッケージ横断、言語横断。クライアントは変わっても、根拠のある答えは変わりません。
// workflow 01
agent> このモノレポでは認証はどこで行われていますか? graph::query("authentication flow") 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、あるいは自作のスクリプトなど、どのクライアントがクエリを送ったかは関係ありません。同じ4つのファイルが、同じランキングで、実際のグラフに根ざした形で返ってきます。
// workflow 02
agent> normalizePhoneNumberはE.164をどのように処理していますか? semantic::query("normalize phone E.164") packages/shared/util/phone.ts:88 normalizePhoneNumber() ← 実装本体 packages/api/test/phone.spec.ts:14 jest.mock(...) ← スタブ [exit 0]
名前は嘘をつきます。モックは実際のコードを覆い隠します。Maguyvaは、尋ねてくるすべてのクライアントに対して同じように、実際の実装をテストモックより上位にランク付けします。
// workflow 03
agent> モノレポ全体でQueueDispatcher.publishを呼び出しているのはどこですか? graph::callers(QueueDispatcher.publish) packages/billing/* に3件 packages/audit/* に1件 packages/notifications/* に1件 services/python-worker/* に1件 ← gRPCスタブ経由で言語を横断 [exit 0]
パッケージ横断、そしてポリグロットなリポジトリでは言語横断でも、呼び出し箇所がインラインで表示されます。明日エージェントを乗り換えても、影響範囲はそこにあります。それはクライアントではなく、サーバー側にあるからです。
3ステップ。Freeプラン: リポジトリ3個, インデックス済みリポジトリ行数、最大5万行、カード不要。
// step 01
回答を検証できるよう、よく知っているものを選びましょう。Freeプランはリポジトリ3個, インデックス済みリポジトリ行数、最大5万行をカバーします。
// step 02
{
"mcpServers": {
"maguyva": {
"url": "https://maguyva.tools/mcp",
"headers": {
"Authorization": "Bearer mgv_xxxx"
}
}
}
} // step 03
1つのリポジトリと、「パッケージ横断でformatInvoiceを呼び出しているのは何か?」のような、検証可能な質問1つから始めましょう。答えがあなたの想定と一致すれば、そこに向けるほかのどのクライアントでも、同じ根拠のある結果が得られます。