Skip to main content
Profound MCP は、MCP クライアントから直接 Profound Agents を構築、管理、実行するためのツールを AI アシスタントに提供します。MCP クライアントをホスト型サーバーに接続するには、接続ガイドを参照してください。
Profound Agents の詳細については、Profound ヘルプセンターをご覧ください。

​
ツールの連携のしくみ

​
Agent を実行する

1

Agent を探す

どの Agent があるかを尋ねます。アシスタントは list_agents で組織の Agents を、または list_agent_definition_templates で構築済みのテンプレートを参照します。
2

入力を確認する

Agent の実行に何が必要かを尋ねます。アシスタントは実行を開始する前に、get_agent で Agent の input_schema を読み取ります。
3

Agent を実行する

Agent の実行を依頼します。アシスタントは Agent の input_schema に合った入力を渡して、run_agent で実行を開始します。
4

結果を確認する

実行が完了したかどうかを尋ねます。アシスタントは get_agent_run で実行の状態を確認します。

​
Agent を構築する

1

ビルドセッションを開始する

Agent の構築を依頼します。アシスタントは start_agent_build_session でビルドセッションを開始し、返された agent_build_session_id を以降のすべてのビルド呼び出しに含めます。これにより、構築の試行全体が 1 つのセッションとして追跡されます。
2

構成要素を確認する

アシスタントは list_agent_node_types と get_agent_node_schema を使ってワークフローグラフを組み立てるか、list_agent_definition_templates でテンプレートから始めます。
3

接続済みアカウントを割り当てる

接続済みアカウント上で実行されるノードがグラフに含まれる場合、アシスタントは list_integrations から取得した ID をそのノードの integration_id に設定します。
4

下書きを作成または更新する

アシスタントは create_agent_definition または update_agent_definition でプランをプレビューし、確認後に下書きを保存します。
5

検証する

アシスタントは validate_agent_definition で Agent の構造の問題を早期に検出し、update_agent_definition で修正します。これは Agent を公開する前の簡易チェックです。
6

公開する

Agent を公開するよう依頼します。アシスタントは publish_agent_definition で公開プランをプレビューし、確認後に適用します。

​
Claude を使用する場合は自然言語で指示する

クライアントとして Claude を使用している場合は、さまざまなツールを手動で順に実行させなくても、自然言語でプロンプトを入力するだけで Agent を一度に構築できます。 以下は、プロンプトの例と、それを使って Claude が生成する可能性のある Agent の構造です。
上記のプロンプトで Claude が生成した Agent の構造を示す図の例

​
動作と安全性

Agents ツールは、Agent 定義の作成・更新や Agent の実行開始を行えます。作成、更新、公開のツールはデフォルトでプレビューモードになっており、アシスタントはまず変更のプランを受け取り、確認後に適用します。

​
Agents ツール

組織で定義されている Agents を一覧表示します。プロンプトの例:
  • 「公開済みの Agent はどれですか?」
  • 「下書きの Agent を表示して。」
入力
input_schema を含む、特定の Agent の詳細を取得します。アシスタントは run_agent を呼び出す前にこれを読み取り、Agent が必要とする入力を確認します。プロンプトの例:
  • 「記事作成 Agent にはどんな入力が必要ですか?」
  • 「週次レポート Agent は何を生成しますか?」
入力
Agent の実行を開始します。アシスタントが get_agent_run で使用できる実行 ID を返します。プロンプトの例:
  • 「記事作成 Agent を『AI search trends』というトピックで実行して。」
  • 「週次レポート Agent を開始して。」
入力注意事項:
  • inputs の各キーは、Agent の input_schema のプロパティ ID です。各プロパティの人間が読めるラベルは、そのプロパティの title に含まれています。
以前に開始した Agent の実行のステータスと出力を取得します。アシスタントは、実行が成功または失敗して終了するまで、これを繰り返し確認します。プロンプトの例:
  • 「あの Agent の実行は終わりましたか?」
  • 「記事作成 Agent は何を生成しましたか?」
入力
Agent のビルドセッションを開始します。これは Agent を構築または修正する前の最初のステップです。アシスタントは他のビルドツールより先にこれを呼び出し、返された agent_build_session_id を以降のすべてのビルド呼び出しに含めます。プロンプトの例:
  • 「引用データから AEO に最適化された記事の下書きを作成する Agent を構築して。」
  • 「週次レポート Agent を作り直そう。」
入力
Agent の構築に使用できるノードタイプを一覧表示します。各タイプの node_type 識別子、表示名、1 行の説明を返します。アシスタントは、ビルドセッションを開始した後、新しい Agent を組み立てる際にこれを呼び出します。プロンプトの例:
  • 「Agent ではどんな構成要素を使えますか?」
  • 「Web 検索を実行するノードはありますか?」
入力注意事項:
  • third_party ノードは、WordPress や Slack など、組織が接続したアカウント上で実行されます。platform_key ノードは、Exa や Perplexity など、Profound が契約している外部のリサーチベンダー上で実行されるため、ユーザー側で接続する必要はありません。native ノードは Profound 独自のノードで、llm や code などの構造ノードと、Profound のデータを読み取る profound_* ノードが含まれます。
特定のノードタイプの設定スキーマと例を取得します。アシスタントは返されたスキーマを使用して、Agent の構築や編集時にノードの config を正しく設定します。プロンプトの例:
  • 「LLM ノードはどのように設定しますか?」
  • 「code ノードにはどんな設定がありますか?」
入力
組織が接続し、Agents で利用できるようにしたインテグレーションを一覧表示します。接続ごとに integration_id を返し、アシスタントは Agent を公開する前にこれをインテグレーションノードに使用します。プロンプトの例:
  • 「Agent で使えるインテグレーションはどれですか?」
  • 「WordPress は接続されていて、Agent から公開できますか?」
入力注意事項:
  • このツールはアクティブな接続のみを返します。
  • 各接続は integration_id、provider、account、label、status、level(org または user)を返します。
  • 同じインテグレーションプロバイダーの接続が複数ある場合(たとえば、ブログ用とドキュメント用の 2 つの異なる WordPress サイト)、account フィールドで接続を区別できます。
  • Google Docs、Google Slides、Google Sheets は組織の Google Drive 接続を使用するため、返された google_drive 接続は 3 つすべてのノードに対応します。Gmail と Google Search Console には、それぞれ独自の接続があります。
構築済みの Agent テンプレートの公開カタログを参照します。各テンプレートには、平易な言葉で書かれた目標、必要な入力、生成されるもの、出発点として使用できるワークフローの骨組みが含まれます。アシスタントは、新しい Agent をゼロから構築する前にこれを呼び出します。プロンプトの例:
  • 「どの Agent テンプレートから始められますか?」
  • 「コンテンツ更新ワークフロー用のテンプレートはありますか?」
入力: なし。
create_agent_definition と update_agent_definition が受け付けるのと同じ形式で、Agent の定義グラフを読み取ります。アシスタントは、既存の Agent をコピーする場合や、複製したいノードタイプを調べる場合にこれを使用します。プロンプトの例:
  • 「記事作成 Agent がどのように構築されているか見せて。」
  • 「週次レポート Agent をコピーして、新しい Agent の出発点にして。」
入力
新しい Agent 定義の下書きを作成します。プレビューでは何も保存せずに、平易な言葉によるプランとワークフロー図を返し、確認後にアシスタントが下書きを保存します。プロンプトの例:
  • 「そのワークフローを下書きの Agent として保存して。」
  • 「今設計した Agent を作成して。」
入力
既存の Agent 定義の下書きを更新します。アシスタントは、create_agent_definition の後に検証の問題を修正したり、保存済みの下書きを反復的に改善したりするためにこのツールを使用します。最初にプレビューを表示し、確認後に適用します。プロンプトの例:
  • 「検証の問題を修正して下書きを更新して。」
  • 「下書きの Agent に Web 検索のステップを追加して。」
入力
保存済みの Agent 定義の下書きが有効かどうかを確認します。valid(ブール値)、issues(対処可能なエラーの一覧)、および下書きが公開可能な場合は、公開後に Agent が公開する input_schema と output_schema を返します。プロンプトの例:
  • 「下書きの Agent が公開可能か確認して。」
  • 「公開する前に、Agent に問題はありますか?」
入力注意事項:
  • 下書きの Agent は実行できないため、公開前に利用できるチェックはこれだけです。
  • このチェックは Agent の構造のみを対象とするため、合格した下書きでも公開時に拒否される場合があります。公開時にはより厳格なチェックが適用されます。
  • このチェックでは、設定されているが使用できない必須フィールドも報告されます。たとえば、接続済みアカウント上で実行されるノードの integration_id が空の場合や、Profound のデータを読み取るノードに data.category_id がない場合です。公開時にはどちらも許可されるため、いずれかが未解決のまま公開された Agent は実行時に失敗します。
  • チェックで問題が見つかった場合、アシスタントは update_agent_definition で修正します。
Agent 定義を公開して稼働させ、組織全体で表示できるようにします。最初にプレビューを表示し、確認後に適用します。プロンプトの例:
  • 「チームが使えるように Agent を公開して。」
  • 「記事作成 Agent を稼働させて。」
入力注意事項:
  • 公開時には、変更が行われる前に Agent の構造と出力の接続がチェックされるため、構造上の問題がある下書きは拒否され、下書きのまま残ります。このチェックは validate_agent_definition が実行するチェックよりも厳格です。
  • 公開時には、Agent の実行に必要なものはチェックされません。ノードの integration_id または data.category_id が欠けている Agent は公開できますが、実行時に失敗するため、公開前に両方を解決してください。

​
リソース

Profound MCP は、Agents のリファレンス資料を読み取り専用の MCP リソースとして提供します。