Pathruleリファレンスのサーバーの役割
状態を保持するMCPサーバーの代表的な例であり、MCPとは何かを理解するには、本当にいちばんの近道です。エンティティはオブザベーションを持ち、リレーションは能動態でそれらを結び、すべてはエディターで開けるJSONLファイルに保存されます。そして全体が、アカウントもサービスもなしに、1つのコマンドで動きます。
1人での実験、プロトコルの学習、あるいは会話をまたいでエージェントに覚えておいてほしい少しの事実のためなら、それで十分です。このページも、それに異を唱えるものではありません。
並べて比較
| リファレンスのMCPメモリサーバー | Pathrule | |
|---|---|---|
| 通信の方式 | MCP | MCP。加えて、CLIまたはVS Code拡張機能がインストールするフックと指示ファイル |
| ナレッジの届き方 | エージェントがツールを呼び出す必要がある：`search_nodes`、`read_graph` | 各エージェントのフックやルールファイルを通じて、最初のツール呼び出しより前に届ける |
| スコープ | 共有のグラフが1つ。パスやユーザーのスコープはなし | ワークスペースごとに、リポジトリのパスで索引化 |
| 保存するもの | エンティティ、リレーション、オブザベーション | 型と優先度を持つメモリ、ルール、スキル |
| 強制 | なし | ツールのフックがあるクライアントでは、強制ルールが一致する変更をブロックできる |
| チーム | ローカルのJSONLファイル | ロールとレビューのある共有ワークスペース |
| 古くなったナレッジ | 自分で気づく必要がある | 承認するだけの修正案として提示 |
リファレンスのサーバーに関する記述は、2026年8月に読んだmodelcontextprotocol/serversのREADMEに基づいています。誤りのある行があればお知らせください。修正します。
そこから生まれる違い
エージェントが呼び出すのを覚えておかなければならないツール. READMEには、エージェントがツールを呼び出す必要があり、自動では何も起きないと明記されています。つまりエージェントは、動く前に検索すると判断しなければなりません。これは、クエリ起点のメモリすべてに共通する隙間です。いちばん必要な制約は、誰も調べようと思わなかった制約なのです。
グラフは1つ。場所の感覚はない. リポジトリのパスによるスコープも分離もありません。すべてのやり取りに共通の、1つの共有グラフです。数十個の事実なら問題ありませんが、1つのモノレポの中の2つのサービスで、正しい変更の姿についての考えが食い違うようになると、立ち行かなくなります。
制約になれるものがない. オブザベーションは、エージェントが読むかもしれないテキストです。Pathruleのルールはスコープ、優先度、強制レベルを持つので、ツールのフックがあるクライアントでは、ローカルのPathruleのフックが、一致する変更をモデルの判断に任せることなく、反映される前に止められます。
リファレンスのサーバーが正しい選択になるとき
MCPを学んでいるとき、1台のマシンで1つのエージェントのために依存関係のないメモ帳がほしいとき、あるいはナレッジが、チームが蓄積した規約ではなく、本当に少数のエンティティにすぎないときに使いましょう。リファレンス実装として、すべきことをそのとおりにこなしています。
ナレッジを作業が行われている場所に合わせてスコープする必要があるとき、チームメイトのセッションや2つ目のエンジンにも届ける必要があるとき、その一部が変更を思いとどまらせるのではなく関門として止める必要があるとき、そしてグラフを手で保守するより、残すべきものをエージェントに提案してほしいときは、Pathruleを選びましょう。
出典と検証
リファレンスのサーバーの公式ドキュメントは2026年10月1日に確認しました。リリース済みのリファレンスのサーバーのバージョンは、ローカルでテストしていません。Pathruleに関する記述は、2026年10月9日に、リリース済みのPathrule CLI 0.6.1と照らし合わせて確認しました。
- Model Context Protocol：リファレンスのメモリサーバー
リファレンスのサーバーのツール、グラフのモデル、JSONLによる永続化についての公式情報。
よくある質問
PathruleもMCPサーバーです。実際には何が違うのですか？
プロトコルは同じですが、届け方が違います。リファレンスのサーバーは、エージェントがツールを呼び出したときにナレッジを渡します。pathrule setupはそれに加えて、エージェントのためにフックを登録し、指示ファイルを書き込みます。そのため、作業しているパスを管理する部分が、エージェントが尋ねたかどうかに関係なく、最初のツール呼び出しより前に届きます。Claude CodeとCodexにはプロンプトフック、CursorとGitHub Copilotにはセッションとツールのフックがあり、Windsurfはルールファイルを読みます。
リファレンスのメモリサーバーをPathruleと併用できますか？
妨げるものはありませんが、両者は重なります。どちらも、エージェントがナレッジを保持する場所だからです。両方を動かすと、たいていは中途半端に保守された2つのストアになり、パスのスコープがないほうが劣化していきます。プロジェクトごとにどちらかを選びましょう。
ホスト型のMCPエンドポイントしか使えなくても、Pathruleは動きますか？
はい。ただし、知っておくべき制限が1つあります。CLI、VS Code拡張機能、Remote MCPは、同じPathruleのナレッジへの入り口です。https://cloud.pathrule.io/mcpのRemote MCPは、OAuthとPathruleのアカウントで、同じワークスペース、メモリ、ルール、スキルを公開します。ただしフックのインストールもローカルファイルの書き込みも行わず、ローカルモードもないため、最初のツール呼び出しより前に届けるのではなく、求められたときに答えます。フックの時点での配信は、CLIかVS Code拡張機能で利用できます。
Pathruleは、グラフのようにエンティティとリレーションを保存しますか？
ナレッジグラフは保持していますが、索引はエンティティ名ではなくリポジトリのパスで、コンテンツには型があります。メモリは事実、ルールはスコープと優先度を持つ制約、スキルは名前のついた手順です。この型があるからこそ、強制と順位づけが可能になります。