630+ ツールの MCP でも、AI のコンテキストウィンドウはいっぱいになりません。最新の Claude や ChatGPT のコンテキストウィンドウは 200K から 1M トークンです。PaidSync のカタログ全体は、説明で約 76K トークンです。MCP はスキーマを遅延読み込みするので、AI が実際に呼び出したツールだけが、タスクごとに完全なスキーマのコストを負担します。それでも絞り込みたい場合は、ツールのフィルタリングが使えます。代替案の、プラットフォームごとの小さな MCP を寄せ集める方法は、各サーバーがスキーマのオーバーヘッドと認証メタデータを持ち込むため、たいていコンテキストを節約せず、むしろ多く使います。
懸念はもっともです。AI のコンテキストウィンドウには限りがあります。クライアントに 五つの MCP サーバーを読み込み、その一つが巨大なら、トークンの膨張や遅延、モデルの混乱を心配するかもしれません。その直感は妥当です。
実際には、MCP プロトコルはまさにこの制約を前提に設計されており、最新の AI クライアントは大きなカタログを難なく扱います。恐れは、LLM のコンテキストに対する直感から来ています。数字は違う実態を示します。この記事では、実際の計算、実際のプロトコルの挙動、そして PaidSync を他のツールと並べて運用した実際の経験を順に見ていきます。
要点まとめ。
1.2026 年のコンテキストウィンドウは 200K から 1M トークンです。PaidSync のツール一覧は、説明ごとに約 200 トークンで、約 76K トークンです。余裕で収まります。
2.MCP は接続時にツールの説明を一覧し、完全なスキーマはタスクごとに遅延読み込みします。カタログのコストは一度きり、スキーマのコストは呼び出しごとです。
3.小さな MCP は、たいてい安くなりません。それぞれがスキーマのオーバーヘッド、認証メタデータ、ツール命名規則を重複して持つためです。
4.必要なら PaidSync を絞り込めます。プラットフォームやカテゴリ別のツールのフィルタリングは、Claude Desktop、Cursor、ほとんどの MCP クライアントで利用できます。
実際のコンテキストの計算
恐れは、「630+ のツールはコンテキストウィンドウを大量に使うに違いない」というものです。計算してみると、恐れより地味な結果になります。
PaidSync のツール説明の平均は、名前、短い要約、プラットフォームタグ、使いどころのヒントを含めて、約 200 トークンです。これは多めの見積もりです。短い説明も多く、複雑なパラメータを持つツールでは長いものも一部あります。
カタログ全体のトークンコストは、おおよそ 630+ ツール × 説明ごとに 200 トークンで、ツール一覧だけで約 62K トークンになります。この数字は Claude Sonnet 4.5 の 200K ウィンドウに収まり、会話そのもの、システムプロンプト、ユーザーが持ち込むその他のコンテキストのために 138K の余裕が残ります。1M のコンテキストを持つ Claude Opus 4.7 では、カタログは利用可能な余地の 7% 未満です。
Claude Sonnet 4.5 の 38% という数字について、正直に言います。確かにウィンドウのかなりの部分です。ただし、残りの 124K は、通常のオペレーターとの会話には十分すぎる量です。長い検索語句レポートは 5K から 20K トークン。アカウント監査の全体要約は 10K から 30K。AI には十分な作業の余地があります。
すべてのトークンが必要な長時間のリサーチ作業と並行して PaidSync を動かす場合は、ツールのフィルタリングで絞り込んでください。ほとんどのオペレーターは、その必要はありません。
MCP のツールスキーマは遅延読み込みされる
プロトコルの仕組みが重要です。MCP は、接続した瞬間にすべてのツールの完全な入力スキーマを AI のコンテキストに流し込むことはありません。接続時には説明を送り、AI が特定のツールを呼び出すと決めた時点で、そのツールの入力スキーマを取得します。
実際の効果です。カタログのオーバーヘッドは説明だけで、説明は短いものです。ツールの完全なスキーマは、パラメータの複雑さによって 500 から 2000 トークンになることがありますが、そのコストが発生するのは AI がそのツールを呼び出したときで、カタログを読み込んだときではありません。
一般的な 10 タスクのオペレーターとの会話では、スキーマの読み込みコストは 10 ツール分の完全なスキーマで、セッション全体に分散して約 5K から 20K トークンです。これは小さな量です。事前コストの大半はカタログそのもので、その上限を決めるのはパラメータの複雑さではなく説明の長さです。
小さな MCP が安くなるとは限らない理由
「大きな MCP はコンテキストを使う」への直感的な解決策は、「小さなものを使えばいい」です。この計算は、実際にはたいてい成り立ちません。
AI クライアントに接続する MCP サーバーは、それぞれ独自のオーバーヘッドを伴います。サーバー自体のスキーマメタデータ。サーバーの認証コンテキスト。AI が別々に覚えなければならないツール命名規則。似た操作を MCP ごとに違う名前で呼ぶため、やり取りのパターンも変わります。
630+ ツールの PaidSync MCP をひとつ使う代わりに、Google Ads、Meta Ads、LinkedIn Ads を別々にカバーする小さな MCP を三つ使うと、スキーマのオーバーヘッドが 三つ分、認証コンテキストが三つ、AI が把握すべきツール命名規則が 三セットになります。重複するメタデータのせいで、たいてい PaidSync の単一カタログのコストを下回らず、上回ります。
より適切な比較は、「適切に絞られた大きな MCP」対「ばらばらの小さな MCP」です。有料広告では、適切に絞られた大きな MCP のほうが、全体のコンテキストでたいてい有利です。
最新の AI はカタログをキャッシュ
もう一つ、実務上の細かい点があります。Claude Desktop、Cursor、主要な MCP クライアントは、セッション中ツールカタログをキャッシュします。カタログは会話を始めたときに一度だけ読み込まれます。それ以降、AI が目にするすべてのプロンプトには、ツール一覧がすでにキャッシュされたコンテキストとして含まれています。Anthropic のプロンプトキャッシュの TTL は数分で、通常のやり取りを繰り返す作業セッションなら、カタログの読み込みコストを二度払うことはありません。
セッション最初のプロンプトは、76K のカタログトークンのコストを負担します。次の 20 のプロンプトでは、カタログ側のコストはほぼゼロです。呼び出しを連続して行うオペレーターにとって、これは大きな意味があります。カタログのコストは、会話全体で償却されます。
どうしても規模を小さくしたい場合
計算したうえでなお小さなカタログを望む技術志向の購入者のために、プロトコルは対応しています。ほとんどの MCP クライアントでは、設定時にツールを名前のパターン、プラットフォームタグ、カテゴリで絞り込めます。PaidSync の MCP はプラットフォームタグを公開しているので、必要なときに単一のプラットフォームに絞れます。
最も簡単な絞り込みのパターンです。Google だけを運用するなら、Google Ads のみに絞ります。監査だけが必要なら、読み取り専用のツールに絞ります。作業が限られているなら、「audit」や「reporting」などの特定のカテゴリに絞ります。必要なときには PaidSync の MCP 全体を使え、必要ないときには絞った版を使えます。
ほとんどのオペレーターは、わざわざ絞り込みません。カタログ全体が収まり、作業は進み、AI が同じ会話の中で Google Ads、Meta Ads、LinkedIn Ads、TikTok Ads、Snapchat Ads、Reddit Ads、Pinterest Ads、Microsoft Ads を比較した瞬間に、プラットフォームをまたぐツールがコンテキストのコストに見合う働きをするからです。
深いカタログが正しい設計である理由
根本的な主張はこうです。有料広告は奥の深い領域です。Google Ads や Meta Ads でオペレーターが行う作業は、「キャンペーンを一覧して一つ一時停止する」ことではありません。n-gram による検索語句の分析、パフォーマンス最大化のインサイト抽出、無駄な広告費の検出、クライアントアカウントをまたぐ MCC のルーティング、コンバージョン値ルールの編集、オーディエンス構築のフローです。これらはどれも、きちんとした入力スキーマと出力構造があってこそ生きる、本物のツールです。
20 個の汎用ツールだけの薄い MCP を出して、AI にそれらを組み合わせて深いワークフローを作らせることもできます。実際には、プロンプトが壊れやすく、結果も安定しません。AI は、名前が適切で範囲が明確なツールを呼び出すほうが、六つの汎用操作を組み合わせて同じ結果を出すより、はるかに得意です。
630+ のツールは、仕事を正しく行うためのコストです。各ツールは、AI が 一手で呼び出せるワークフローです。この深さがあるからこそ、PaidSync は、タスクごとに独自のプロンプトエンジニアリングを必要とせず、Claude や ChatGPT で予測可能な結果を出せます。
率直な見解
「大きな MCP はコンテキストを埋め尽くす」というのはもっともな直感ですが、数字には耐えられません。カタログは、200K から 1M のウィンドウの中の 76K トークンです。スキーマは遅延読み込みです。キャッシュで償却されます。小さな MCP を寄せ集める代替案は、たいてい安くならず、むしろ高くつきます。
深いカタログこそが、MCP サーバーが AI クライアントの中で存在意義を持つ理由のすべてです。AI が実際に作業をするために呼び出す、ワークフローの面です。AI に汎用的な操作を組み合わせさせる浅い MCP が欲しいなら、その代替案はあります。AI に有料広告を運用させたいオペレーターにとっては、深さこそが価値です。
ChatGPT に追加：ChatGPT のプラグインディレクトリで PaidSync.ai を開き、インストールしてからサインインします。
Claude に追加：Claude のコネクタディレクトリで PaidSync.ai を開き、「接続」をクリックしてからサインインします。
よくある質問
PaidSync の 630+ のツールカタログで、Claude や ChatGPT のコンテキストウィンドウはいっぱいになりますか？
いいえ。最新の AI のコンテキストウィンドウは 200K トークン以上です（Claude Sonnet 4.5 は 200K、Claude Opus 4.7 は 1M）。PaidSync のツールカタログ全体は、説明ごとに一般的に 200 トークンとして、約 76K トークンです。小さいウィンドウでも余裕で収まります。大きいウィンドウなら、ツール一覧は誤差の範囲です。
MCP のツールスキーマは遅延読み込みですか、それとも一括ですか？
MCP は AI クライアントが接続した時点でツールの説明を一覧し、AI が呼び出すと決めた特定のツールについてのみ、完全な入力スキーマを取得します。カタログのオーバーヘッドは説明だけです。ツールごとの完全なスキーマのコストは、セッションごとではなく呼び出しごとに発生します。
一般的な MCP ツールの説明の実際のトークンコストはどれくらいですか？
PaidSync のツール説明は、平均で約 200 トークンです。これには、短い要約、プラットフォームタグ、ツールの使いどころのヒントが含まれます。630+ ツールで 200 トークンなら、カタログのオーバーヘッドは約 62K トークンです。特定のツールの実際のスキーマ本体が読み込まれるのは、AI がそのツールを呼び出したときだけです。
PaidSync の規模を小さくしたい場合、ツールを絞り込めますか？
はい。MCP はクライアント側でのツールのフィルタリングに対応しています。Claude Desktop、Cursor などのクライアントでは、名前のパターンで特定のツールを許可または禁止できます。表面を小さくしたければ、PaidSync を単一のプラットフォーム（Google Ads のみ、Meta のみ）や単一のカテゴリ（監査のみ、書き込み操作のみ）に絞れます。ほとんどのオペレーターは、その必要はありません。
小さな MCP を多数組み合わせる方が、大きな一つよりコンテキストの節約になりますか？
たいていは、いいえ。接続する MCP サーバーごとに、独自のスキーマのオーバーヘッド、独自のツール命名規則、独自の認証コンテキストが加わります。三つの小さな MCP（Google、Meta、LinkedIn）は、通常、三つすべてをカバーする適切に絞られた一つの MCP より多くのコンテキストを使います。サーバー間で重複するメタデータが、見えにくいコストです。
MCP のカタログが大きいと、Claude や ChatGPT は遅くなりますか？
モデルのレイテンシは、カタログのサイズでは変わりません。最初の MCP ツール一覧の読み込みには、一度だけわずかなコストがかかります。その後の AI の呼び出しごとの性能は、呼び出し自体で決まり、カタログのサイズには左右されません。最新の AI クライアントは、セッション中ツール一覧をキャッシュします。
七つの広告プラットフォーム、630+ のツール、本物の深さ、本物のワークフロー。無料で始められ、カード不要です。