mcpls - Language Server のコード理解を AI agent に渡す

AI coding agent が code を変更するときに起こりやすい失敗の一つは、codebase をただの text の集合として扱ってしまうことです。grep で探し、file を読み、function name から意図を推測することはできます。しかし IDE は本来そう動いていません。IDE は language server に、symbol の type、definition、references、diagnostics、rename の影響範囲を尋ねています。

今日紹介する bug-ops/mcpls は、その IDE 側の経路を AI agent に渡す tool です。Rust で書かれた MCP to LSP bridge で、Language Server Protocol の機能を Model Context Protocol tools として公開します。GitHub search result では現在およそ 38 stars、8 forks。主な言語は Rust です。Repository は 2025 年 12 月に作成され、2026 年 6 月現在も active です。Cargo.toml の workspace version は 0.3.6 で、git ls-remote でも latest tag v0.3.6 を確認できます。

プロジェクト概要

項目	内容
リポジトリ	bug-ops/mcpls
位置づけ	Universal MCP to LSP bridge
Stars	約 38
Forks	8
主な言語	Rust
ライセンス	MIT OR Apache-2.0
Current version	0.3.6
Install	cargo install mcpls または GitHub Releases

Agent の semantic blind spot を埋める

多くの agent workflow は、file の読み書き、test 実行、shell command の利用にはかなり強くなりました。一方で、code understanding の層は text matching に戻りがちです。たとえば process_request の return type を知りたいとき、agent は definition 付近の file を開き、import、trait、type alias を手で追っていきます。これは動くこともありますが、cost が高く、language がすでに知っている情報を見落としやすいです。

LSP はもともとこの問題のためにあります。rust-analyzer、pyright、typescript-language-server、gopls などは、hover、definition jump、reference search、diagnostics、completion、code action、format、rename、call hierarchy を答えられます。mcpls の価値は、それらを MCP tools に変換し、Claude Code のような MCP client から直接使えるようにするところです。

これは AI を魔法のように賢くする tool ではありません。より信頼できる data source に接続する tool です。Type、references、diagnostics が language server から来るなら、agent の推測は減り、根拠が増えます。

どんな MCP tools があるか

README では tool が用途ごとに整理されています。Code intelligence 系では次のようなものがあります。

• get_hover: 現在位置の type signature、documentation、inferred type を読む。
• get_definition: symbol の定義へ移動する。
• get_references: workspace 内のすべての参照を探す。
• get_completions: type と scope に基づいた completion を得る。
• get_document_symbols: file の構造 outline を得る。
• workspace_symbol_search: workspace 全体で symbol を探す。

Diagnostics と refactoring まわりも実用的です。

• get_diagnostics と get_cached_diagnostics: language server の実際の error / warning を読む。
• get_code_actions: quick fix、refactor、source action を取得する。
• rename_symbol: reference tracking に基づいて workspace-wide rename を行う。
• format_document: language 固有の formatter を呼ぶ。
• prepare_call_hierarchy、get_incoming_calls、get_outgoing_calls: function の call relationship を見る。

この組み合わせは、agent が code を変更する前に聞くべき問いをかなりカバーします。何を変更しているのか。誰がそれを使っているのか。今どんな compiler/type error があるのか。rename で呼び出し元を漏らさないか。

Rust project は zero-config から始めやすい

mcpls は Rust project でかなり入りやすい default path を用意しています。README では、mcpls と rust-analyzer を入れれば Rust project は zero configuration で使えると説明されています。Install は短いです。

cargo install mcpls

MCP client 側には server を設定します。README では Claude Code の設定例が出ています。

{
  "mcpServers": {
    "mcpls": {
      "command": "mcpls",
      "args": []
    }
  }
}

Rust 専用ではありません。README にある default heuristics では、project marker を見て必要な language server を起動します。Rust は Cargo.toml、Python は pyproject.toml、setup.py、requirements.txt、TypeScript は package.json、tsconfig.json、Go は go.mod、C/C++ は CMakeLists.txt、compile_commands.json、Makefile、Zig は build.zig を見ます。

この設計は重要です。Monorepo では backend、frontend、script、tooling が混在します。Agent のためにすべての language server を常に起動する必要はありません。Project marker による heuristic startup は resource waste を減らし、failure の切り分けもしやすくします。

Pure grep より構造化変更に向いている理由

Text search は今でも必要です。String、config、AST に出てこない convention を探すには便利です。ただし agent が structured change をする場面では、LSP の利点がはっきり出ます。

たとえば:

• Public function signature を変える前に、get_references で call sites を確認する。
• Variable type が不明なとき、context から推測せず get_hover を使う。
• Error を直すとき、get_diagnostics で language server の診断を読む。
• Symbol rename は global replace ではなく rename_symbol を使う。
• Function を分割する前に、call hierarchy で call chain を見る。

人間の developer にとって、これらは IDE の中にずっとあった機能です。しかし terminal-first の agent からは安定して使えないことが多いです。mcpls は IDE の semantic layer を MCP 経由で agent workflow に出す、という素直な設計です。

境界も明確

mcpls は complete code indexing platform ではなく、review tool でもありません。Language server 自体の品質に依存します。ある language の LSP configuration が壊れている、project が正しく load できない、dependency が足りない、という状態では結果も弱くなります。README でも、少なくとも一つの language server が必要だと説明されています。

また、LSP は agent に「この type は何か」「参照はどこか」を教えられますが、test、build、code review の代わりにはなりません。現実的な workflow は、LSP で不確実性を下げ、code を変更し、project 側の verification command を実行する、という流れです。

私はこれを agent toolbox の infrastructure layer として見るのがよいと思います。事実を取り出す役割は mcpls。判断するのは agent と human reviewer です。

向いている場面

mcpls は次のような場面に向いています。

• Claude Code、Codex、Cursor など、MCP 対応の coding agent を使っている。
• Agent に text guessing だけでなく language server へ質問してほしい。
• Project に rust-analyzer、pyright、typescript-language-server、gopls などの LSP 設定がある。
• Cross-file change、rename、call site analysis、diagnostic fix を agent に任せることが多い。
• Multi-language workspace の code semantics を一つの MCP interface で公開したい。

もし project に安定した language server configuration がまだないなら、まず IDE と LSP を正常に動かすのが先です。mcpls はその上の layer を接続する tool なので、下の層が不安定なら上も安定しません。

まとめ

bug-ops/mcpls の面白さは、とても基礎的で実用的な方向にあります。AI coding agent に code を text として読ませるだけでなく、language server がすでに持っている semantic information を渡す。Hover、definition、references、diagnostics、rename、call hierarchy は新しい概念ではありませんが、MCP 経由で agent workflow に入ると、cross-file change の推測コストをかなり下げられます。

特に良いのは、code understanding engine を再発明していないことです。成熟した LSP ecosystem を MCP に接続する bridge に徹しています。AI agent を日常開発に入れ始めた team では、こういう橋渡し tool のほうが、また一つの万能 agent より実際に効くかもしれません。

リポジトリ：https://github.com/bug-ops/mcpls