ooligo
mcp-server

MCP server exposing LeanData routing decisions to Claude, read-only

Difficulty
上級
Setup time
60min
For
revops · gtm-engineer
RevOps

Stack

LeanData のルーティング監査ログに対する 5 つの読み取り専用ツールを Claude に与える Model Context Protocol サーバーです。これにより、誰も LeanData の画面を開かずに、エージェントが「なぜこのリードがこの担当者に割り当てられたのか」に答えられます。LeanData はデプロイ済みルーティンググラフを 1 回通過するたびに、レコードごとに LeanData__Log__c の行を 1 件書き込みます。本サーバーはそのオブジェクトを Salesforce の REST API 経由で照会します。どこにも書き込みは行いません。スキャフォールドは apps/web/public/artifacts/mcp-server-leandata-routing/ にあり、README.mdpyproject.toml、そしてクライアント・フィールドリゾルバ・5 つのツールを収めた src/leandata_routing_mcp/server.py で構成されます。インストールは pip install -e . です。

まず次のセクションを読んでください。LeanData はすでに MCP サーバーを公開していますが、それは本サーバーではありません。

これを使うべき場面

LeanData の Q2-2026 リリースは、日程調整を担う公式サーバー BookIt MCP を投入しました。読み取り側では空き状況のプレビュー、ミーティングログの照会、ユーザーとプールの検索、ミーティングタイプの検索、カウントとキャリブレーション、予約リンクを提供し、書き込み側では BookIt for Forms のルーティングと予約、キャンセル、再調整、再割り当て、クレジット申請を提供します。認証は Salesforce OAuth 経由で、管理者スコープとユーザースコープはサインインした人物の permission set から導出されます。組織内に Salesforce 認証情報を持たない外部エージェント向けには、ワンタイムコードによる認証も用意されています。問いがミーティングに関するものであれば、そちらが正解であり、このスキャフォールドは無駄な作業です。

同じリリースでは Audit Logs もクラウドインフラ上に作り直され、ルーティングに関する質問に自然言語で答え、ノードパスと評価された条件を引用する AI アシスタントが組み込まれました。管理者が 1 件のリードを対話的にデバッグするなら、このアシスタントは標準で含まれ、コードも不要で、自作するどんなものよりも優れています。

したがって、本サーバーが埋める隙間は狭く具体的です。自分のエージェント自身が実行できるルーティングの原因究明を、GTM スタックの残りと同じ会話の中で行うことです。次の 3 つのケースであれば 1 時間の価値があります。

問いが複数のシステムをまたぐ場合。「先週のエンタープライズリードのうち、すでにキャパシティを超えていた担当者にルーティングされたのはどれで、その後どう処理されたか」という問いには、ルーティングログと CRM の活動履歴の突き合わせが必要です。アプリ内アシスタントはルーティングについて答えます。本サーバーと CRM ツールを併せ持つエージェントは、問い全体に答えます。

**呼び出し元が人ではなくジョブである場合。**BookIt MCP のスコープは、サインインしたユーザーの permission set に由来します。06:00 に起動してルーティング失敗の有無を確認する監視ジョブには、「なりうる人物」が存在しません。ここで用いる client-credentials フローはサーバーに固有の ID を与え、Salesforce の Run As ユーザーが権限を担います。

**判断根拠を transcript に残す必要がある場合。**LeanData の画面内で返されたアシスタントの回答は成果物になりません。会話の中のツール出力なら、インシデントレビューに貼り付けられます。

これを使うべきでない場面

  • **ミーティングに関わるすべて。**前述のとおりです。BookIt MCP は予約・キャンセル・再割り当てを行い、その際に BookIt の permission set を適用します。本サーバーに追加すべき書き込み経路はなく、今後も持たせるべきではありません。
  • **管理者による単一リードの対話的デバッグ。**Audit Logs の AI アシスタントがすぐそこにあり、ノードパスを把握しています。
  • **ルーティングログの個人情報を LLM に渡せない場合。**ログ行は Lead と Contact を参照し、組織のカスタム項目によっては氏名・メールアドレス・テリトリー属性を含みます。返されたすべての項目は会話に入り、transcript に残ります。Salesforce の項目レベルで参照権限を外せばその範囲は狭まりますが、なくなりはしません。
  • **ルーティングそのものを変更したい場合。**本サーバーはグラフもプールも割り当ても編集しません。ある判断がなぜ起きたかを読むことと、別の判断を下すことは、影響範囲の異なる別の仕事です。

公開されるツール

src/leandata_routing_mcp/server.py に定義された 5 つのツールで、すべて読み取り専用です。

  • describe_routing_log() — この組織が公開している項目インベントリを、各項目が担う役割(グラフ、トリガー、結果、owner、突合レコード、エラー、ノードパス)ごとにグループ化して返します。ツールの説明文で、これを最初に実行するようエージェントに指示しています。
  • get_routing_history(record_id, limit) — Salesforce レコード 1 件のルーティング通過履歴を新しい順に返します。「このレコードはどうやってこの owner に届いたのか」に答えます。
  • explain_assignment(log_id) — ログ 1 行の値が入ったすべての項目を返します。単一行はコンテキスト消費が限定的なので、このツールはすべてを射影します。
  • find_routing_errors(since, until, limit) — 指定した期間内で、エラー系の項目に値が入っている行を返します。グラフに入ったのに正常にルーティングされなかったレコードを捕捉します。
  • get_routing_throughput(since, until) — 組織のグラフ項目でグループ化した行数と、LeanData の処理キューオブジェクトの現在の滞留数を返します。「ルーティングが遅い」と「ルーティングが動いていない」を切り分けます。

**項目の API 名はハードコードせず、実行時に解決します。**LeanData は managed package を配布しており、顧客は Log オブジェクトに独自の項目を付与するため、インベントリは組織ごとに異なります。各ツールは Salesforce の describe を呼び出し、項目名とラベルを _ROLE_HINTS の役割ヒントと照合し、プロセスの生存期間キャッシュします。項目リストをハードコードしたスキャフォールドは、それが書かれた組織でだけ動き、ほかのどこでも動きません。

既定の射影はすべてを選択せず、40 項目に制限しています。組織は Log オブジェクトに数十のカスタム項目を付与しており、その 1 つ 1 つが返却行ごとにコンテキストを消費します。

コストとスループット

ここに呼び出し単位の課金はありません。コストは Salesforce の API 割り当てであり、組織内の他のすべての連携と共有されます。Enterprise と Professional エディションは 24 時間あたり 100,000 リクエストに加えて Salesforce ライセンス 1 件あたり 1,000、Unlimited と Performance は 100,000 に加えてライセンス 1 件あたり 5,000、Developer Edition は 15,000 です(Salesforce のプラットフォーム制限ドキュメント)。ツール 1 回の呼び出しで消費するのは 1 〜 2 リクエストで、初回以降キャッシュされる describe と、クエリ 1 件です。

効いてくる制約は割り当てではなく、保持期間です。監査ログの既定の保持期間は 90 日で、LeanData の Admin → Settings → Reporting で設定でき、日次ジョブが期間を超えたものを削除します。Q2-2026 のクラウド版では保存が 24 か月に延び、15 分間隔で同期されます。どちらが回答の範囲を決めるかは組織がどちらの版を使っているかによりますが、いずれにせよ過去に関するすべての問いの範囲を、黙って制限します。

セットアップは約 1 時間で、その大半は Salesforce で Connected App を作成し、Run As ユーザーが実際に何を読めるかを確認する作業に費やされます。

失敗モードとガード

**実際は「ログが期限切れになった」のに、エージェントが「該当行なし」と報告する。**前四半期にルーティングされたリードについての問いは、90 日の保持期間に対して空で返り、その空は「そんなことは起きなかった」と読まれます。ガード: _get_routing_history の空結果の分岐は、2 つの可能性(デプロイ済みグラフに一度も入らなかった、または設定された保持期間を超えて消えた)を明示的に示します。これによりモデルは、曖昧さを誤って解消せず、回答まで持ち越さざるを得なくなります。

役割ヒントが組織の命名規則と合わず、ツールが黙って劣化する。_ROLE_HINTSgraphoutcomeerror といった部分文字列で照合します。命名が特殊な組織では、ある役割に対して (none matched) が返ります。ガード: 該当するツールは、穴の空いたクエリを実行するのではなく、何が見つからなかったかを名指しして describe_routing_log を案内するメッセージを返します。これは README の本番投入前チェックリスト 8 項目のうち 2 番目です。

**find_routing_errors が誤った項目を推論する。**エラー系のテキスト項目を名前で選ぶため、別の意味で命名された項目でも error を含めば対象になり、逆に LeanData__Disposition__c という正真正銘の失敗項目は対象から漏れます。ガード: このツールはヘッダーに、どの項目を検査したかを出力します。監査できない回答は、回答がないことより悪いからです。

**ループに陥ったエージェントが、組織全体にとって迷惑な隣人になる。**Salesforce の日次割り当ては組織単位なので、暴走したエージェントは誰かが気づく前に他のすべての連携を劣化させます。ガード: LD_MAX_ROWS(既定 200)が各ツールを制限し、SalesforceClient.query は意図的に nextRecordsUrl を追わず、常に 1 回の呼び出しにつき 1 ページだけを返します。API 呼び出しのカウンターはまだありません。これが 7 番目の制限であり、無人運用の前に用意すべきものです。

**会話由来のレコード ID が SOQL に到達する。**ガード: ID は ^[a-zA-Z0-9]{15}(?:[a-zA-Z0-9]{3})?$ と、日付は ISO-8601 のパターンと照合されてから、どちらもクエリ文字列に入ります。照合に失敗した時点で、SOQL が組み立てられる前に例外が送出されます。

代替手段との比較

LeanData__Log__c に対する Salesforce 標準レポートは LeanData 自身が文書化している回答であり、ルーティングの健全性を毎週見る定型ダッシュボードにはこちらが適します。ただしレポートは、エージェントが知っている他の何とも組み合わせられません。それこそが、このスキャフォールドを作る理由のすべてです。

BookIt MCP は、日程調整に関するあらゆる問いについて、工数・サポート・スコープの正しさで勝ります。LeanData 自身の permission set を適用するため、書き込みも安全に行えます。一方で、監査ログを用いたルーティング判断の原因究明は公開しておらず、それが本サーバーの唯一の存在理由です。

Chili Piper は、まだ選定中のチームのために挙げておく価値があります。すでに運用しているものを計装するのではなくルーティングプラットフォームを評価している段階なら、その判断が固まるまで何も作らないことです。

スタック

GTM システム全体で読み取り専用の MCP アクセスを標準化するチームには、ApolloAttioZoomInfo の各サーバーと組み合わせて使えます。ルーティングの原因究明は、そのルーティング判断を生んだデータと同じ会話の中にあるときに最も役立ちます。

Files in this artifact

Download all (.zip)