Argyph：local-first な MCP code context server
AI coding agent が便利になると、すぐに別の問題が出てくる。Agent は codebase をどう読むべきなのか。雑なやり方は repo 全体を大きな context として詰め込むこと、あるいは grep 用、embeddings 用、symbol search 用、repo packing 用の MCP server をいくつもつなぐことだ。動くことは動くが、install、indexing、permission、context budget が新しい摩擦になる。
今日見るのは ezzy1630/Argyph。狙いはかなり絞られている。Local-first で read-only な MCP code context server として、file search、tree-sitter symbol graph、hybrid semantic search、token-budgeted repo packing を Rust の単一 binary にまとめる。README の主張も「agent に自動で code を書かせる」ではなく、agent が手を動かす前に、必要な code context をより速く、小さく取れるようにすることだ。
GitHub repository API、README、Releases、Tags、default branch commit history、Cargo.toml、CHANGELOG.md、ARCHITECTURE.md、license files を 2026-08-06 時点で確認すると、ezzy1630/Argyph は 20 stars、3 forks。主要言語は Rust。Workspace license は MIT OR Apache-2.0 で、repository page には MIT と Apache-2.0 の license file が並ぶ。Repository created time は 2026-05-10 20:34:51 UTC、latest push は 2026-08-05 10:46:21 UTC。Default branch の現在の latest commit は e420f43、commit time は 2026-07-13 13:56:01 UTC、commit message は chore: update download badge (#46)。最新 GitHub Release は v1.0.4、published time は 2026-05-18 19:21:23 UTC。最新 tag も v1.0.4。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | ezzy1630/Argyph |
| 位置づけ | local-first、read-only な MCP code context server |
| Stars | 20 |
| Forks | 3 |
| 主要言語 | Rust |
| ライセンス | MIT OR Apache-2.0 |
| 作成日時 | 2026-05-10 20:34:51 UTC |
| Latest push | 2026-08-05 10:46:21 UTC |
| 現在の default branch commit | e420f43、2026-07-13 13:56:01 UTC |
| 最新 GitHub Release | v1.0.4、2026-05-18 19:21:23 UTC |
| キーワード | MCP、code search、semantic search、tree-sitter、local-first、Rust、agent context |
これは「repo 全体を model に渡す」道具ではない
Argyph の面白いところは、agent の code lookup をいくつかの層に分けている点だ。最初から full file や full repo を返すのではない。README では ask が primary entry point として設計されている。Bare identifier は symbol search に、structured locator は locate に、natural-language question は hybrid search に routed され、返ってくるのは line boundary を持つ Span だ。
これは agent にとってかなり効く。たとえば「session expiration はどこで制御されているか」と聞くとき、model は auth directory 全体を読む必要はない。必要なのは候補になる definition、call site、周辺 code だ。Argyph は bounded span として context を小さく返し、必要なら expand_span で続きを読ませる。この interface は「file 全体を読んで自分で探す」より context を節約しやすく、agent が何を見たかも追いやすい。
Repo packing も残っているが、それが唯一の答えではない。「まず project 全体を把握する」場面では packing が役立つ。一方で「この symbol の呼び出し元を探す」場面では、symbol graph と span retrieval のほうが向いている。
三層 indexing がいちばん engineering らしい部分
Argyph の architecture document は indexing を Tier 0、Tier 1、Tier 1.5、Tier 2 に分けている。Tier 0 は file inventory、hash、language、.gitignore aware tree を作り、cold start でも早く使えることを狙う。Tier 1 は tree-sitter で symbol graph を作り、definition、references、callers、callees、imports、outline を支える。Tier 1.5 は Markdown、JSON、YAML、TOML、CSV など structured non-code file の locator を扱う。Tier 2 で embeddings と BM25 + vector の hybrid semantic search を作る。
この分割の実用的な価値は、agent が embeddings 全部の完了を待たなくてよいことだ。Structural question は Tier 0 / Tier 1 で先に答えられる。Semantic question は Tier 2 の coverage が上がったあとでより正確になる。README も tool が index_coverage を返すと説明しており、agent は結果が full index なのか partial index なのかを判断できる。
Codebase context tool は semantic search を中心に置きがちだが、日常の coding question の多くはまず structure の問題だ。この function はどこにあるか、誰が呼んでいるか、この config key はどの file で定義されているか、この import はどこから来たか。Argyph が structure query を embeddings より前に置いているのは、かなり現実的な設計だと思う。
Local-first と read-only boundary
Argyph は local-first を強調している。Embedding model、vector store、SQLite index は developer machine 上で動かせる。Cloud vector DB や remote embedding API は、始めるための必須条件ではない。Private code では、これは単なる売り文句ではなく導入条件そのものだ。多くの team は agent によりよい repo context を与えたいが、code fragment を別の vector service に送るのは避けたい。
Read-only boundary も重要だ。Architecture document は明確で、Argyph は file を編集しない、shell を実行しない、git を変更しない、agent orchestration もしない。.argyph/ の local index を維持し、MCP 経由で query tool を出すだけだ。この boundary によって、agent toolchain の中で「code を読む能力」として入れやすくなる。実行権限を増やす layer ではない。
Claude Code、Codex、または他の MCP client を使っているなら、この read-only context server は risk を評価しやすい。Agent の observation capability は広がるが、execution permission は増えない。
Install path はかなり整っている
README が列挙している install path は、npx argyph、Claude Code の claude mcp add argyph -- npx argyph@latest、Homebrew、universal installer、Cargo、source build、Claude Desktop DXT。crates.io と npm の latest version も 1.0.4 で、license field はどちらも MIT OR Apache-2.0 になっている。
小さな project として、これはよい signal だ。小規模 MCP server は idea より distribution でつまずくことが多い。Install path が散らばり、version publish が不安定で、最初の run が脆い。Argyph は npm、Cargo、Homebrew、GitHub release binaries、DXT をすでに通しており、配布体験をちゃんと扱っている。
もちろん caveat もある。Cargo install は Rust toolchain 1.88 を要求する。README は Intel Mac について、ONNX Runtime の prebuilt がないため Cargo で source install する必要があるとも書いている。Cross-platform binary と local embedding backend には、どうしても system dependency の細部が出る。npx 一行だけを見て判断しないほうがよい。
誰に向いているか
Agent workflow が「まず project を読む」段階でよく詰まるなら、Argyph は試す価値がある。たとえば、知らない repo を agent に調べさせて entry point と主要 module を出させる。Bugfix の前に function の definition、references、call chain を探す。Agent に patch を作らせる前に、関係する span だけを読ませる。Private codebase で remote service に embeddings を渡さず local semantic search を使う。
逆に、万能 agent runtime が欲しい user には向かない。Argyph は task を調度しないし、code も書かないし、test も走らせない。LSP replacement でもない。Architecture document は cross-file resolution が best-effort であり、language server レベルの正確な semantic resolution ではないと認めている。非常に大きな monorepo についても、ROADMAP は 81K+ files、約 2M LOC の規模で Tier 1 にまだ改善余地があると書いている。
つまり boundary ははっきりしている。「agent のために code context を探す」ことを local、read-only、progressive indexing の MCP server として切り出した project だ。
Caveat
第一の caveat は project がまだ若いこと。Repository は 2026-05-10 作成で、stars は 20、forks は 3。v1.0.4 まで release されているとはいえ、community validation はまだ初期段階だ。重要な private repo で使う前に、中規模の repo で indexing time、result quality、memory usage を見たほうがいい。
第二の caveat は language coverage。README と architecture document は tree-sitter symbol graph を強調しているが、language ごとの parse quality と cross-file resolution は均一ではない。ROADMAP では Go、Java、Kotlin の additional language packs が Next に置かれており、coverage はまだ拡張中だと分かる。
第三の caveat は local embedding が無コストではないこと。Cloud dependency は避けられるが、その分 model download、ONNX Runtime、CPU / memory usage、platform compatibility が local machine 側に来る。軽い repo なら気にならなくても、大きな repo や制限の強い environment では実測が必要だ。
まとめ
ezzy1630/Argyph が面白いのは、agent の code context retrieval を小さく明確な infrastructure layer にしているところだ。Local に動き、read-only で、progressive index を持ち、bounded spans を返す。新しい agent platform になろうとはしていないし、すべてを embeddings に任せてもいない。
MCP client をすでに使っていて、agent に full file ではなく relevant span を読ませたいなら、Argyph は tool box に入れてよい小さな project だ。まだ早いが方向はよい。Codebase を agent が query できる構造にしてから、model をより小さく正確な context で働かせる、という考え方は今後も効いてくる。