MCPの概要

PathruleはModel Context Protocolに対応しています。このプロトコルは、AIコーディングアシスタントが外部ツールを呼び出したり外部の状態を読み取ったりするために使うものです。Pathruleはアシスタントからは通常のMCPサーバーとして見えるため、MCPに対応したクライアントであればどれでも利用できます。

接続方法は2つあります。ローカルサーバーはPathrule CLIとPathrule VS Code拡張機能に同梱されています。アシスタントとはstdioで通信し、Cloudワークスペースの場合はランタイムがHTTPS経由でPathrule Cloudと通信します。ホスト型サーバーに接続するクライアント向けには、Remote MCPがOAuthサインインとワークスペースへのスコープ付きアクセスを備えたStreamable HTTPによる直接接続を受け付けます。ローカルのstdioとRemote MCPでは、ツールのカタログとスキーマが異なります。接続先サーバーのtools/listを確認してください。Pathruleがリポジトリのソースコードを自動でアップロードすることはありません。ただし、ローカルのプロジェクト学習ツールは、知見を検証するためにその知見に紐づくファイルを参照することがあります。

サーバーが公開するもの

PathruleのMCPインターフェースは型付けされており、データモデルに沿ってグループ分けされています。以下のコアツールで、日常的なコンテキスト、コンテンツ、アクティビティの操作をカバーします。正式な一覧はツールリファレンスを参照してください。

ローカルサーバーは最初のtools/listの時点で、読み取りと書き込みを含むすべてのツールを提示します。そのため、最初の書き込みの前に何かを有効化する必要はなく、セッションの途中で一覧が変わることもありません。必要になるまで書き込みツールを保留する遅延モードもオプトインで利用できます。詳しくはローカルの遅延書き込み制御を参照してください。

読み取りツール

• pathrule_get_context。主要なエントリポイントです。現在の作業ディレクトリとユーザーの意図をもとに、そのパスに適したメモリ、ルール、スキルを返します。レスポンスには、ワークスペースの概要、すでに該当しているルールとメモリ、次に読むべきもののヒントが含まれます。
• pathrule_read_memory、pathrule_read_rule、pathrule_read_skill。アシスタントが特定のノードを引用したり従ったりしたいときに、IDを指定して本文全体を取得します。
• pathrule_get_tree、pathrule_get_node。ワークスペースの構造や特定のノードを確認します。
• pathrule_list_memories。パス配下のメモリを列挙します。探索的なプロンプトで役立ちます。

書き込みツール

• pathrule_write_memory、pathrule_write_rule、pathrule_write_skill。ワークスペースのパスにコンテンツを作成します。パスの途中に存在しないノードがあれば、必要に応じて作成されます。
• pathrule_update_memory、pathrule_update_rule、pathrule_update_skill。既存のレコードを編集します。バージョンIDによる楽観的同時実行制御が適用されます。
• pathrule_delete_memory、pathrule_delete_rule、pathrule_delete_skill。論理削除を行い、30日間は元に戻せます。

アクティビティと管理

• pathrule_log_activity。ファイルを変更するレスポンスのあとに呼び出され、アシスタントがどこで何をしたかをチームが確認できるようにします。
• pathrule_goto。ユーザーが別のスコープのコンテンツを求めたときに、アシスタントの作業ノードを移動します。
• pathrule_ping。サーバーが正しく接続されていることを確認するヘルスチェックで、ランタイムから見た作業ディレクトリも表示します。

フックの役割

フックに対応したクライアントでは、Pathruleはフックによってアシスタントの応答速度を保ちます。セッション開始時とツール呼び出しの前後に、フックスーパーバイザーが現在の作業ディレクトリに対応するキャッシュ済みのデータを読み取り、コンテキストとしてエージェントに渡します。これにより、一般的なケースでは同期的なMCPのラウンドトリップを避けられます。セッション開始フックはPathruleのプロトコル自体も渡すため、フック対応クライアントではリポジトリ内の指示ファイルは短いメモで済みます。

クライアントによって届け方は異なります。

• Claude CodeとCodexには、プロンプト送信フックを含むフックがあります。そのため、関連するナレッジがプロンプトごとに、エージェントが動く前に届きます。
• CursorとGitHub Copilotにはセッションフックとツールフックがありますが、プロンプト送信フックはありません。コンテキストはセッション開始時とツール呼び出しの前後に届きます。
• Windsurfにはフックがありません。セッション開始時にPathruleのルールファイルを読み込み、それ以上の情報はすべてMCPツールで取得します。

フックで十分な場合、アシスタントがpathrule_get_contextを呼び出す必要はありません。適切なデータはすでに手元にあります。MCPツールが使われるのは次の2つの場面です。

1. フックが提示した以上の情報をアシスタントが必要とする場合。たとえば、メモリの本文全体が必要な探索的プロンプトや、フックが想定していなかったパスに及ぶリファクタリングです。
2. 残しておく価値のあるものがある場合。アシスタントがメモリ、ルール、スキルを提案し、あなたが確認したうえで書き込みます。あるいは、あなたが直接書き込みを依頼することもできます。書き込みは書き込みツールを通じて行われ、それぞれアシスタントによる書き込みとして記録されてバージョン管理されるため、レビューしたり元に戻したりできます。

内部の仕組みについてはフックの仕組みを参照してください。

エージェントとの連携

Pathruleはインテリジェンスレイヤーです。コーディングエージェントは引き続き実行エンジンとして動き、モデルプロバイダーもそのまま使います。CLIとVS Code拡張機能は、各クライアントが対応するフック、指示ファイル、MCPを通じて、すでに使っているエージェントを同じワークスペースに接続します。

• Claude CodeとCodex: プロンプト送信フックを含むフック、指示ファイル、ローカルMCPサーバー。どちらもRemote MCPにも接続できます。
• CursorとGitHub Copilot: セッションフックとツールフック、指示ファイル、ローカルMCPサーバー。VS Code拡張機能がCopilotのエージェントモード向けにサーバーを登録します。
• Windsurf: PathruleのルールファイルとローカルのMCPサーバー。フックはありません。
• その他のMCPクライアント: stdioで接続します。クライアントの設定にPathruleのMCPコマンドを追加すると、同じツール群を利用できます。
• ホスト型サーバーに接続するクライアント: Streamable HTTP経由でRemote MCPを指定し、OAuthでサインインします。Remote MCPはフックをインストールせず、ローカルファイルも書き込みません。

次に読むもの

• キャッシュからエディタまでの間で何が起きるかについてはフックの仕組み。
• ツールが扱うデータモデルについては基本概念。
• サーバーをホストするランタイムのセットアップについてはCLIのインストール。