consult について
consultは、コーディングエージェント向けのMCPサーバーです。別のAPIキーを用意せず、ローカルでログイン済みのClaude Code、Codex、Grok、Antigravity CLIに意見を求められます。変更の並列レビューに加え、任意で稼働中セッションへの質問やコーディングタスクの委任もできます。
主な機能
- 01他のコーディングCLIへの相談
- 02複数アドバイザーへの並列質問
- 03Git変更とプルリクエストのレビュー
- 04稼働中セッションへの質問やメッセージ送信
- 05CodexまたはGrokへのタスク委任
活用シーン
- 01修正を繰り返しても解決しない問題の相談
- 02完了前に複数エージェントで変更をレビュー
- 03アーキテクチャやデータモデルの判断
- 04CodexまたはGrokへのコーディングタスク委任
MCP 対応
consultは、ローカルでログイン済みのエージェントCLIをアドバイザーツールとして公開するMCPサーバーです。検出したClaude、Codex、Grok CLIに登録し、任意でセッションへの質問、メッセージ送信、タスク委任のツールも提供します。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
4掲載時のツール一覧 · 1 週間前に更新
| パラメーター | 型 | 必須 | 説明 |
|---|---|---|---|
| cwd | string | いいえ | アドバイザーが読み取れるディレクトリ。このサーバーの起動時に使用したディレクトリがデフォルトです |
| agent | enum | はい | 相談する CLIclaude | codex | grok | agy |
| model | string | いいえ | その CLI で使用するモデル。例:gpt-6-astra、opus、grok-4.7、gemini-3.1-pro-high。省略すると CLI のデフォルトが使われます。選択肢は list_agents で確認できます |
| effort | enum | いいえ | 推論の強度。省略すると CLI のデフォルトが使われますlow | medium | high |
| question | string | はい | 回答に必要な十分なコンテキストを含む質問(ファイルパス、試したこと、制約) |
| session_id | string | いいえ | 追加質問に使用する、以前の応答に含まれる session_id |
詳細
consult
コーディングエージェントに、別の意見を聞かせましょう。
consult は、Claude Code、Codex、Grok が互いに相談したり、Google の Antigravity CLI にアドバイスを求めたりできる MCP サーバーです。マシンですでにサインイン済みの CLI を通じて利用します。API キーは不要です。各アドバイザーは、その CLI がすでに利用しているサブスクリプションで動作します。
Opus を使う Claude Code は、GPT-6 Astra を使う Codex に計画のレビューを頼めます。Codex は、テストが不安定な理由を Grok に尋ねられます。また、どれでも一度にほかのすべてに質問できます。作業完了とする前に、エージェントは一度の呼び出しでほかのベンダーに変更差分をレビューしてもらえます。ターミナルから、あなた自身も同じようにできます。
npx -y consult-mcp@latest review # every installed advisor reviews your uncommitted changes
npx -y consult-mcp@latest review --base main
ライブセッションを有効にすると、エージェントはすでに実行中のセッションに相談したり、メッセージを送ったりすることもできます。また、タスクのディスパッチを有効にすると、コーディングタスクを Codex または Grok のワーカーに任せ、その進捗を確認できます。
インストール
npx -y consult-mcp@latest install
これにより、PATH 上で見つかったすべてのエージェント CLI(claude、codex、grok)に、ユーザースコープで consult が登録されます。その後、実行中のエージェントセッションを再起動してください。
Antigravity(agy)はアドバイザー専用です。agy は MCP サーバーを有効にせず、読み取り専用の状態にしかできないため、consult は agy に自身を登録しません(詳細)。consult のインストール後に agy をインストールした場合は、install を再実行して、サーバーの PATH に agy を含めてください。
常に最新の状態が保たれます。 ホストは npx -y consult-mcp@latest serve でサーバーを起動するため、新しいエージェントセッションでは毎回、最新リリースが実行されます。install は安全に再実行できます。古いバージョンが登録したものも含め、既存の登録を置き換えます。
削除するには:
npx -y consult-mcp@latest uninstall
要件:macOS、Linux、Windows では Node 22 以降、さらに claude、codex、grok のいずれかの CLI にサインインしていること。
Windows では、ライブセッションとセッションメッセージ以外はすべて動作します。これらは ps と lsof でセッションを検索し、POSIX シェルフック経由でメッセージを配信するため、Windows では無効になります。consult はアドバイザーの実行に cmd.exe を使いません。質問に含まれる & や % などの文字が解釈されてしまうためです。npm の .cmd シムとしてインストールされた CLI の場合は、そのシムが指すスクリプトまたはバイナリを直接実行します。
npx -y consult-mcp@latest doctor でセットアップを確認してください。各エージェント CLIとそのバージョン、consult が登録されているかどうか、設定、メッセージフック、agy の設定が読み取り専用かどうかを報告し、問題ごとに修正方法を示します。doctor --ask はさらに、各アドバイザーに一語の質問を送信します。これにより、その CLI にサインインしていて、回答できることを確認できます。
install による変更内容
- claude:
claude mcp add consult --scope user … - grok:
grok mcp add consult … - codex:
$CODEX_HOME/config.toml(デフォルトは~/.codex/config.toml)に[mcp_servers.consult]テーブルを追加します。Codex のデフォルトの 60 秒ではアドバイザーへの呼び出しに短すぎるため、tool_timeout_sec = 960を設定します。また、npxの初回起動はデフォルトの 10 秒より長くかかる場合があるため、startup_timeout_sec = 60を設定します。元のファイルはconfig.toml.bakとして保存されます。consult は、変更後の内容が正しく解析でき、ほかの設定がすべて変更されていない場合にのみファイルを書き込みます。それ以外の場合は処理を中止し、ファイルを手動で編集するよう求めます。
各エントリでは、起動コマンド(npx または node)とエージェント CLI があるディレクトリを PATH に設定します。一部のホストは、最小限の環境で MCP サーバーを起動するためです。
セッションメッセージが有効な場合、install は各 CLI 固有のフックファイル(~/.claude/settings.json、~/.codex/hooks.json、~/.grok/hooks/consult.json)にも consult のフックを追加します。これらのファイルにあるほかのフックはそのまま維持され、uninstall またはメッセージ機能を無効にすると consult のフックが削除されます。npx consult-mcp@latest 経由で起動したサーバーは、現在のリリースと異なる場合、consult 独自の Claude Code エントリも書き換えます。そのため、再インストールしなくてもフックの修正が反映されます。
install は、各 CLI のグローバルな指示ファイル(~/.claude/CLAUDE.md、~/.codex/AGENTS.md、~/.grok/AGENTS.md)にも短い consult セクションを追加します。これにより、エージェントはアドバイザーへの質問や、有効な場合にライブセッションへの質問とメッセージの送信、タスクの振り分けができることを把握できます。このセクションは と のコメントの間に置かれ、ファイルの残りの部分はそのまま維持されます。consult settings は選択した設定に合わせてこのセクションを更新し、サーバーは起動時に内容を更新します。uninstall を実行すると削除されます。
@latest を追従せず、特定のビルドに固定するには、npm i -g consult-mcp でグローバルにインストールしてから consult install を実行するか、チェックアウトしたリポジトリから node dist/cli.js install を実行してください。以降、ホストはそのスクリプトを起動します。
ask_agent {agent, question, model?, effort?, session_id?, cwd?} は {agent, answer, session_id, model?, duration_ms} を返します。
agent:claude、codex、grok、またはagy(Antigravity、Gemini モデル)を指定します。model:その CLI に渡されます(opus、gpt-6-astra、grok-4.7、gemini-3.1-pro-high、…)。省略すると、CLI のデフォルトが使用されます。effort:low、medium、またはhighを指定します。session_id:同じアドバイザーとの以前の会話を続けます。cwd:アドバイザーが読み取れるディレクトリです。デフォルトはホストエージェントがサーバーを起動したディレクトリで、通常はそのリポジトリです。
ask_agents {agents, question, effort?, cwd?} は複数のアドバイザーに同じ質問を並行して尋ね、{results: [...]} を返します。各エントリーは、独自の session_id を持つ回答か、エラーのいずれかです。あるアドバイザーで失敗しても、ほかのアドバイザーには影響しません。
review_changes {agents, base?, focus?, effort?, cwd?} は、各アドバイザーから cwd 内の git 変更に対するコードレビューを並行して受け取ります。変更をレビューするを参照してください。
list_agents は、インストール済みの CLI、そのバージョン、および各アカウントで使用できるモデル ID を表示します。
ライブセッションが有効な場合、list_sessions と ask_session {session_id, question, effort?} が表示されます。
セッションメッセージが有効な場合、send_message {session_id, message} が表示されます。
タスクのディスパッチが有効な場合、dispatch_task、task_status、cancel_task が表示されます。
アドバイザーが作業中は、サーバーから MCP 進捗通知(codex is thinking (40s))が送信されるため、進捗を表示するホストが応答停止中のように見えることはありません。
エージェントが相談するタイミング
ホストがエージェントのコンテキストに追加するサーバーの MCP 指示では、次の場合にセカンドオピニオンを求めるよう伝えます。
- バグに対して修正を2回試しても、どちらもうまくいかなかったとき。
- アーキテクチャ、データモデル、移行、その他元に戻すのが難しい決定をしようとしているとき。
- 作業完了とする前に、計画や差分のレビューを受けたいとき。
- 判断に迷っており、間違えた場合の損失が大きいとき。
また、指示では、異なるベンダーのアドバイザーを優先すること、自己完結した質問を書くこと(アドバイザーはリポジトリを読み取れますが、会話は読めません)、行動に移る前に助言をコードと照らし合わせて確認することも伝えます。
変更をレビューする
consult は差分を自動で収集し、レビューの指示とともに各アドバイザーに送信します。実際のバグ、リグレッション、セキュリティ上の問題、コードの他の部分との契約違反を見つけ、重大度、file:line、問題が発生するシナリオ、修正方法を示すよう求めます。スタイル上の細かな指摘は避け、修正すべき点がなければ、その旨を明確に伝えるよう求めます。アドバイザーは報告する前に周辺コードを読んで指摘を確認し、他のアドバイザーと同様に読み取り専用で動作します。
baseを指定しない場合、まだコミットしていない変更をすべてレビューします。HEADに対するステージ済みおよび未ステージの変更に加え、新しい未追跡ファイルの名前も対象となり、アドバイザーがファイルを直接読みます。base(例:main)を指定すると、ブランチがbaseから分岐して以降の変更を、未コミットの作業も含めてレビューします(git diff --merge-base main)。focusを指定すると、特に注目する箇所を追加できます。例:"error handling in the retry path"。
サブディレクトリから実行した場合でも、常にリポジトリ全体をレビューし、アドバイザーはリポジトリのルートで実行されます。質問は各 CLI にコマンドライン引数 1 つとして渡されるため、差分は収まるサイズに切り詰められます。上限は Linux で約 110 KB、macOS で 190 KB、コマンドラインの長さが最も短い Windows で 25 KB です。残りの変更ファイルも読むよう、アドバイザーに指示されます。外部 diff、textconv、fsmonitor、clean/process フィルターの各コマンドは無効になっているため、差分の収集では git 以外は実行されません。
シェルから consult review を実行すると、--agents codex,grok を渡さない限り、PATH 上のすべてのアドバイザー CLI が使用されます。
consult review --base main --focus "the new caching layer"
consult review --agents codex --effort high > review.md
consult review --pr 42
--pr <number> を指定すると、GitHub のプルリクエストをレビューします。gh pr view を使って PR の base および head コミットを取得します(GitHub CLI が必要で、サインイン済みである必要があります)。作業ツリーをアドバイザーが読むため、HEAD が PR の head コミットであること(先に gh pr checkout 42 を実行してください)、かつ追跡対象ファイルに未コミットの変更がないことを確認します。そのうえで、マージベース以降の PR のコミットをレビューします。対象は GitHub に表示される差分と同じで、未コミットの変更や未追跡ファイルは含まれません。gh を実行するのは consult だけです。アドバイザーには引き続き差分と、リポジトリへの読み取り専用アクセスが渡されます。
進捗は stderr に、レビュー結果は stdout に出力されます。レビュー結果はアドバイザーごとに 1 つのセクションに分かれ、各セクションには同じ会話で追加の質問をするためのコマンドが含まれます。すべてのアドバイザーが失敗した場合にのみ、コマンドは終了コード 1 で終了します。
ライブセッション
デフォルトではオフです。有効にすると、エージェントは新しいアドバイザーだけでなく、すでに実行中のエージェントセッションにも質問できます。たとえば、API に取り組んでいる Codex セッションから、クライアントを作成した Claude Code セッションに、変更内容を尋ねることができます。
list_sessionsは、ほかのライブセッションのエージェント、セッション ID、ディレクトリ、Git ブランチ、タイトル、ユーザーの最新のプロンプト(作業内容がわかるよう、先頭 200 文字)、開始時刻と最終アクティブ時刻を一覧表示します。会話のほかの内容は表示されません。ask_session{session_id, question, effort?}は、そのセッションの読み取り専用のコピーに質問します。consult は同じ制限のもとで、セッションをフォークします(claude --resume <id> --fork-session、codex exec fork <id>、grok --resume <id> --fork-session)。コピーはそのセッションがこれまでに見たものをすべて把握していますが、セッション自体は中断されず、質問を知ることもありません。追加の質問には、返信に含まれるsession_idとcwdをask_agentに渡してください。
インストール時、または後から有効にできます。
npx -y consult-mcp@latest install --sessions=repo # or off, tree, machine; without the flag, install asks when run in a terminal
npx -y consult-mcp@latest settings # interactive: live sessions, messages, task dispatch, and which agents use consult
| 設定 | 閲覧および質問できるセッション |
|---|---|
off(デフォルト) | 誰もできません。ツールは表示されません。 |
repo | 同じ Git リポジトリ内のセッションと、そのワークツリー内のセッション(Git 管理外では同じディレクトリ) |
tree | repo で許可されるすべてに加え、このディレクトリの上位または下位にあるディレクトリのセッション。たとえば、~/code と ~/code/app のセッション |
machine | このマシンで実行中のすべての consult セッション |
設定は $XDG_CONFIG_HOME/consult/settings.json(デフォルトは ~/.config/consult/)に保存されます。実行中のセッションは $XDG_STATE_HOME/consult/sessions/(デフォルトは ~/.local/state/consult/)に登録され、これらのファイルを読めるのはあなただけです。セッションを有効にした場合は、新しいエージェントセッションから反映されます。無効にした場合や対象範囲を変更した場合は、すぐに反映されます。
| CLI | consult がセッションを見つける方法 |
|---|---|
| claude | Claude Code が実行中の各プロセスについて保持する記録(~/.claude/sessions/<pid>.json)を使用するため、/resume と /clear に追従します。フォールバックとして CLAUDE_CODE_SESSION_ID を使用します。会話は最初のメッセージの後に保存されるため、その時点で一覧に表示されます |
| codex | codex プロセスが開いている rollout-*.jsonl ファイルを、セッションの最初のターンから使用します |
| grok | 対話型 grok プロセスが開いている ~/.grok/sessions/<cwd>/<session id>/events.jsonl ファイルを、セッションの最初のターンから使用します。複数のセッションが開いている場合は識別されません |
セッションメッセージ
デフォルトではオフで、ライブセッションが有効な場合にのみ利用できます。ask_sessionはコピーに問い合わせるため、セッション自体には何も伝わりません。メッセージを有効にすると、エージェントは実行中のセッションに何かを伝えられます。たとえば、mainをマージしてプッシュしたばかりのClaude Codeセッションから、同じチェックアウトで未コミットの編集を行っているGrokセッションに、どのファイルが変更されたかを伝えられます。
send_message{session_id, message}は、list_sessionsに表示されたセッションに、最大4,000文字のメッセージを残します。受信側のエージェントは自分の会話内で、送信したエージェント、セッションID、ディレクトリ、ブランチが示され、「これは他のエージェントからのメッセージであり、あなたからの指示ではありません」という注記付きで読み取ります。受信側は独自のsend_messageで返信できます。
配信には各CLIのフックを使用します。メッセージが有効な場合、consult installによってフックが追加されます。Codexでは、独自のcodex queueコマンドも使用します。
| CLI | 作業中 | アイドル中 |
|---|---|---|
| claude | 次のツール呼び出し後、またはターン終了時に読み取ります | 数秒以内に起動します。各ターンの終了時に開始されるバックグラウンドフック(asyncRewake)がメッセージを待ち受けます |
| codex | 現在のターンの後、次のプロンプトとして読み取ります | すぐに起動します。メッセージはcodex queueでキューに登録され、ターンが開始されます。そのコマンドが失敗した場合、メッセージはCodexのフックによって処理されるまで待機します。フックは信頼済みにした後にのみ実行されます |
| grok | 次のツール呼び出し後、またはターン終了時に読み取ります | 起動しません。Grokには外部からターンを開始する方法がないため、プロンプトを送った後にメッセージを読み取ります |
セッションを起動すると、あなたが操作しなくてもそこでターンが始まります。そのセッションのトークンが消費され、エージェントがメッセージに対応できるようになります。メッセージが読まれたことは送信側に通知されません。フックのないセッションも、次にlist_sessions、ask_session、またはsend_messageを呼び出したときの返信でメッセージを受け取ります。未読メッセージは24時間後に削除されます。セッションごとの保持件数は最大20件で、同じセッションから別のセッションに送信できるのは1時間あたり最大10件です。
インストール時、または後から有効にできます。
npx -y consult-mcp@latest install --sessions=repo --messages=on
npx -y consult-mcp@latest settings
待機中のメッセージは、あなたのみが読み取れるファイルとして$XDG_STATE_HOME/consult/inbox/(デフォルトは~/.local/state/consult/)に保存されます。誰が誰にメッセージを送れるかは、同じrepoとmachineのスコープによって決まります。
タスクのディスパッチ
デフォルトではオフです。有効にすると、エージェントは明確に定義されたコーディングタスクを Codex または Grok のワーカーに渡して、自分の作業を続けながら進捗を確認できます。たとえば、Claude Code は次のモジュールを作成している間に、Codex にあるモジュールのテストを書かせることができます。
dispatch_task{agent, task, model?, effort?, cwd?}はワーカーをバックグラウンドで起動し、すぐにtask_idを返します。agentはcodexまたはgrokです。ワーカーはcwd(デフォルト:ホストのディレクトリ)でヘッドレス実行され、その場所のファイルを編集したり、コマンドを実行したりできます。ホストとの会話を確認したり質問したりできないため、タスクは自己完結している必要があります。task_status{task_id?, wait_sec?, since?}はタスクの状態(running、succeeded、failed、cancelled)、最新の更新情報(実行したコマンド、編集したファイル、メッセージ)、および完了後のワーカーの最終報告を返します。wait_sec(最大600)はタスクの完了を待ち、更新が発生するたびに MCP の進捗通知として送信します。sinceを指定すると、以前の呼び出しのlast_seqより後の更新情報のみを返します(サーバーは直近200件を保持します。一部の更新情報を取得できなかった場合はearlier_updates_droppedで示されます)。task_idを指定しない場合は、すべてのタスクが一覧表示されます。cancel_task{task_id}はワーカーを停止します。すでに変更されたファイルは変更されたまま残ります。
タスクは consult サーバーのメモリ上に保存されます。タスクを開始したエージェントセッションが終了するとタスクも終了し、サーバーの終了時には実行中のタスクが停止されます。CONSULT_TASK_TIMEOUT_SEC(デフォルト3600)は各タスクの実行時間の上限を設定します。報告にはワーカーの session_id が含まれます。同じエージェントを指定して ask_agent に渡すと、作業について読み取り専用の追加質問ができます。
npx -y consult-mcp@latest settings で有効にすると、それ以降に開始されたエージェントセッションに適用されます。ワーカーはファイルを変更するため、その成果を基に作業を進める前に差分を確認し、同じファイルを複数のワーカーに割り当てないでください。
アドバイザーの制限方法
すべてのアドバイザーはヘッドレスかつ読み取り専用で実行され、MCP サーバーを持ちません。そのため、アドバイザーが consult を再度呼び出すことはできず、ループを防止できます。
| CLI | フラグ |
|---|---|
| claude | -p --restricted --tools Read,Grep,Glob --strict-mcp-config |
| codex | exec、sandbox_mode="read-only"、approval_policy="never"、プラグインはオフ、および有効になっているすべての MCP サーバーを名前で無効化(Codex は MCP ツールをサンドボックスの外で実行します) |
| grok | --tools read_file,grep,list_dir --disallowed-tools Agent,search_tool,use_tool(MCP ヘルパーツールはファイルを書き込むサーバーにアクセスできます) |
| agy | -p --output-format stream-json --disable-slash-commands。ただし、事前に agy 自身の設定を確認します(以下を参照) |
agy には、ツールを制限したり MCP サーバーをオフにしたりするフラグがありません(--mode plan と --sandbox を指定しても、書き込み、シェル、ブラウザー、MCP の各ツールは有効なままです)。そのため、呼び出しの前に consult は agy が使用する設定を確認し、次の条件を満たさない場合は実行を拒否します。
~/.gemini/antigravity-cli/settings.jsonのtoolPermissionがrequest-review(デフォルト)またはstrictであること。この場合、書き込み、シェルコマンド、URL の取得には承認が必要ですが、ヘッドレスモードでは承認を求められないため、agy はこれらを拒否します。always-proceedとproceed-in-sandboxは拒否されます。strictではファイルの読み取りも拒否されるため、agy はほとんどの質問に回答できません。- そのファイルの
permissions.allowが空であること。許可ルールがあると、承認なしでコマンドを実行できるためです。 agy mcp listに有効なサーバーが表示されず、agy plugin listにプラグインが表示されないこと(プラグインには独自の MCP サーバーが含まれます)。- フックやプラグインを読み込めないこと。
~/.gemini/config/hooks.jsonとplugins.jsonが存在しないか空であり、~/.gemini/config/plugins/と~/.gemini/antigravity-cli/plugins/が空で、さらにcwdからリポジトリのルートまでの間に.agents、.agent、_agents、_agentディレクトリが存在しないこと。フックはコマンドを実行し、ツール呼び出しを承認することもできるため、権限チェックを回避できてしまいます。 エラーには、変更すべき内容が示されています。agy にはファイルツールだけを使うよう指示されています。ツールの使用が拒否されると、回答せずにターンを終了し、その後 consult がどのツールの使用が拒否されたかを報告します。ウェブ検索ツールはブロックされていないため、検索クエリは、すでに質問を受け取っているのと同じプロバイダーである Google に送られます。agy はセッションをフォークできないため、ライブセッションもタスクのディスパッチもありません。session_idを使った再開は--conversation経由で動作しますが、agy は未知の ID が指定されると新しい会話を開始します。その場合、返信のsession_idは渡した ID とは異なります。
ask_session のコピーでは、同じフラグに加えて、--resume <id> --fork-session(claude、grok)または exec fork <id>(codex)を使用するため、ライブセッション自身のトランスクリプトは読み取りのみです。
consult は Grok のカーネルサンドボックス(--sandbox read-only)を使用しません。/var/run/docker.sock がシンボリックリンクになっているマシンでは起動を拒否するためです。Docker がインストールされた Mac では、よくある状態です。
各セッションの最初のメッセージでは、別のエージェントが相談していることもアドバイザーに伝えます。アドバイザーには、直接回答し、承認やブレインストーミングのワークフローを省略し、何も変更しないよう指示します。
タスクのディスパッチで起動するワーカーは、読み取り専用の唯一の例外です。ただし、明示的に有効にした場合に限ります。ワーカーはヘッドレスで、MCP サーバーを持たないため、consult を呼び出すこともできません。
| CLI | ワーカーのフラグ |
|---|---|
| codex | exec、sandbox_mode="workspace-write"。network_access=false と writable_roots=[] を指定します(書き込みは cwd と一時ディレクトリに限定され、ネットワークアクセスはありません)。さらに、approval_policy="never"、プラグインを無効にし、有効な MCP サーバーを名前で指定してすべて無効にします |
| grok | --tools read_file,grep,list_dir,search_replace,write_file,run_terminal_cmd --always-approve --disallowed-tools Agent,search_tool,use_tool。Grok のカーネルサンドボックス(上記参照)を使わない場合、シェルコマンドはネットワークアクセスを含め、ユーザー権限で制限なく実行されます。シェルから別のエージェント CLI を起動することもできるため、grok で「MCP サーバーなし」とするのは consult 経由のループを防ぐだけで、強制的な境界にはなりません |
最初のメッセージでは、別のエージェントからディスパッチされたこと、質問せずにタスクを完了すること、タスクとディレクトリの範囲内にとどまること、そしてタスクで指示されていない限りコミットやプッシュをしないことを伝えます。
アドバイザーは、読み取った内容をそれぞれのプロバイダーに送信します。読み取り範囲と脅威モデルについては、SECURITY.md を参照してください。
CLI
同じ呼び出しをシェルから実行することもでき、デバッグに便利です。
consult ask codex --model gpt-6-astra "Is the retry logic in src/sync.ts safe under concurrent calls?"
consult ask codex --resume <session_id> "What would you change first?"
consult ask grok - < question.md # long questions from a file or pipe
consult review --base main # every installed advisor reviews the branch
consult doctor --ask # check the setup and that each advisor answers
consult agents
consult settings # live sessions, messages, task dispatch, and which agents use consult
グローバルにインストールされていない場合は、npx -y consult-mcp@latest <command> を使用してください。ここでもアドバイザーは読み取り専用です。同じ制限フラグが適用されるため、ファイルを編集しないよう伝える必要はありません。実行中は、consult ask がタイムスタンプ付きの進捗を stderr に出力します(codex と grok では実行コマンドとメッセージ、どのエージェントでも 30 秒間静かな場合はハートビートを出力します)。stdout に出力されるのは回答のみです。
CONSULT_TIMEOUT_SEC(デフォルトは 900)は、各アドバイザー呼び出しの上限時間です。大きな質問で grok の実行に時間がかかる場合は、値を増やしてください。CONSULT_TASK_TIMEOUT_SEC(デフォルトは 3600)は、ディスパッチされた各タスクの上限時間です。
開発
npm install
npm run build
npm test # unit tests, no CLIs needed
npm run test:live # real calls to all three CLIs through the MCP server
node dist/cli.js install # register this checkout with your agents
リリースするには、package.json の version を更新し、一致するタグをプッシュします(git tag v0.3.0 && git push --tags)。リリースワークフローは、npm の信頼された公開を通じて来歴情報付きで npm に公開し、その後 GitHub リリースを作成します。@latest を使っているユーザーは、次回のエージェントセッションで更新を取得します。プレリリースサフィックス付きのタグ(v0.3.0-rc.1)は、latest ではなく next ディストタグに公開されます。
ランディングページは site/ にあり、Vercel で getconsult.dev にデプロイされます。以前のアドレス consult.n3el.dev からは、そこへリダイレクトされます。
バグの報告
npx -y consult-mcp@latest doctorを実行し、その出力をコピーしてください。consult のバージョン、お使いのプラットフォーム、各エージェント CLI、および設定に問題がある項目が表示されます。ホームディレクトリは~として表示されます。- バグ報告を作成し、コピーした内容を貼り付けてください。
セキュリティ上の問題は、代わりに非公開で脆弱性を報告してください(SECURITY.mdを参照)。
ライセンス
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。