MCPのヤバすぎる闇を暴く！開発者が知っておくべき落とし穴とは？
引用元：https://news.ycombinator.com/item?id=43676771
この記事でリンクされてる認証RFCのコーディネーターだよ。プロトコルはまだ初期段階で、決めるべきことが山ほどあるんだ。でも、Anthropicがコミュニティの声に耳を傾けて、フィードバックに対応しようとしてるのは褒められるべき点だね。認証仕様RFCは、Microsoft、Arcade、Hellō、Auth0／Okta、Stytch、Descopeとかのセキュリティ専門家が協力して作ってるんだ。Anthropicのやつらが基礎を作って、みんながそれを発展させるのを歓迎してる。これからもっと良くなるよ。
このブログ記事[1]は分かりやすくて良いね。前に投稿[2]されたけど、あんまり注目されなかったみたい。[1]: https://aaronparecki.com/2025/04/03/15/oauth-for-model-conte… [2]: https://news.ycombinator.com/item?id=43620496
素晴らしいニュースだね。Aaronはさっき言ったRFCの重要なレビューアーであり貢献者なんだ。
やっぱり彼も関わってると思ったよ。投稿した後にpull requestで名前を見つけたんだ。彼の記事は本当に面白かったし、MCP以外でも役に立つことがいくつか学べたよ。
これだけの組織が協力して、こんなに早く進んでるのを見るのはすごいね（他のコンソーシアム系の仕様とかプロトコルに比べて）。みんなおめでとう。
マジですごいじゃん！お疲れ様。
俺は何もしてないよ。俺よりずっと賢い人たちが頑張ってるんだ。
著者の言ってることはもっともだけど、MCPに責任を負わせすぎな気がするな。俺が理解してるMCPは、LLMが外部リソースとやり取りするための「入り口」を提供するだけなんだよ。橋渡しみたいなもん。
＞機密データをうっかり公開しやすくする。
メールの「転送」ボタンも同じじゃん。システムが機密データをどう扱うか、もっと注意すべき。
＞MCPは強力なプロンプトインジェクションを可能にする。
これは、信頼できるサービスプロバイダーとだけ連携すべきっていう一般的な話だよね。
＞MCPにはコストの概念や制御がない。
自分で使用量を制限して監視しろよ。当たり前じゃん。道路がスピード違反を取り締まるわけじゃないだろ。
AIエージェントに委任することに慣れるべきってことだよね。開発者が責任を持って管理すべき問題だよ。APIにそんなに責任を負わせるべきじゃない。
またMCPの記事かよ。「速報：このナイフは鋭くて、人に振り回すと怪我するし、持ち方を間違えると自分も切っちゃうよ。小さい子には向かないよ」って感じだな。
ナイフは切るための道具なんだから当たり前だろ。人に振り回したら人を切るし、意図しないものまで切っちゃう。安全カミソリとか子供用のハサミと違って、汎用的な道具なんだから。
若い開発者はナイフとか、ローカルシステムでコードを実行できるリモートアクセスが危険だって知らないんだろうな。注意喚起するのは良いけど、道具のせいにするのは違うだろ。
プロンプトインジェクションはLLMの性質からくるものだから、モデルの性能を落とさずに取り除くことはできない。「帯域内シグナリング」が問題なんじゃなくて、「制御とデータ」の分離がないのが問題なんだよ。LLMが便利で汎用的なのはそのためだ。Remote MCP as a Serviceは良くないけど、プロトコルのせいじゃなくて、信用できない第三者に権限を与えるのが問題なんだ。MCP自体じゃなくて、MCPの周りにセキュリティを追加する必要がある。
えーとね、ナイフの例えを借りると、彼ら（私たち？）はめちゃくちゃなPRNG制御のルンバにダクトテープでナイフをくっつけたんだよね。で、アキレス腱を切られちゃう人が出てきた、と。技術的には全部意図通りだけど、このナイフはそういうルンバに取り付けるように設計されてて、誰もそれってどうなの？って思わなかったみたい。人がいるときは使うなとか、使うなら怪我しても自己責任、みたいな忠告は、まあ正しいんだけど、もっと根本的な問題を見逃してるよね。誰かがルンバに鋭いナイフを取り付けて、人がたくさんいる場所でブンブン振り回してるってことじゃん。木を切るテーブルソーには安全装置が付いてて、人間の肌に触れたらすぐに止まるんだよ。だから安全なナイフは作れるんだって。ただ、お金がかかるだけで、みんな人の健康や命を安く見てるから、そんなこと考えないんだよね。
全然関係ない話だけど、100%安全なナイフは無理だよね。だってナイフの使い道の一つに肉を切るってのがあるじゃん。（Sawstop社はデモでホットドッグを人間の指の代わりに使ってるらしいよ。）
そうそう。あと、テーブルソーはナイフじゃないってのも重要だよね。ナイフの汎用性が例えに使われた理由だし。
EDIT: あとね、君のコメントは全然ずれてないよ。むしろど真ん中で、ナイフが良い例えだってことを完璧に示してる。ナイフは道具としての汎用性の頂点にあるんだ。刃と柄が付いてるだけ。これ以上改良しようとすると、汎用性が損なわれちゃう。特に、安全性を高めようとすると、必ず汎用性が落ちる（刃に柄を付けたのが最後の改良点）。
Sawstopみたいなシステムは付けられない。なぜなら、君が言うように、あれは肉を検知するんだ。木より電気を通しやすいものを検知するんだよね。だから、セラミックみたいな素材で作れないし、生鮮食品や湿った木材にも使えない[2]。汎用ツールが特殊ツールになっちゃうんだ。でも、もっと良いものがあるじゃん、テーブルソーだよ！
ナイフを安全にするための他のアイデアも同じ。刃にカバーを付ける？もうあるよ、キッチンにたくさん。でも、工房では役に立たない。ナイフを格納式にして、生体認証ロックを付ける？他の人と共有できないし[3]、問題が多すぎる。
センサーと賢いAIがあれば、完璧に安全なナイフを作れると思うかもしれないけど、それって君自身のことじゃん。
長くなったけど、ナイフみたいに、LLMは汎用ツールとして設計されてる。機能を犠牲にすれば安全にできるけど、完全に汎用的にして安全にするのは無理。なぜなら、安全の意味自体が状況によって変わるから。もし危険すぎると思ったら、使わなければいい。木を切るならテーブルソー、髭を剃るなら安全カミソリ、信頼できないソフトウェアを扱うならコマンドラインと自分の頭脳を使えばいい。そうでなくても、ナイフやLLMのせいにするな。自分の責任で道具を選べ。それか、子供向けの道具を使えばいい。
つまり、MCPの問題は、企業が危険な使い方をさせようとしてること。気を付けて。君の不注意は君の損失、企業の利益になる。LLMとローカルコード実行と信頼できない第三者は相性が悪い（LLMがなくてもね）。
LLMを使ったシステムを安全にするには、ナイフをどう扱ってるか、組織をどう守ってるかを見るといい。対策は汎用的だけど危険な部分を中心に作られてて、技術的なものより法律的なものが多い。(つまり、LLMを騙す行為は人を騙すのと同じように扱うべき。場合によっては犯罪にすべき。)
[0] - 一般的な意味での「あなた」。
[1] - ‘dharmab
[2] - 濡れたものを切ると、保護システムが壊れて手首を痛めるかもしれない。
[3] - 緊急時や戦闘では致命的な問題になる可能性も。
ナイフは鋭いって議論は、汎用的すぎるんだよね。ほとんどの安全対策に当てはまるし。現代社会は事故率をほぼゼロにするようにできてる。だから安全カミソリみたいな特殊な道具があるんだよ。事故率を下げるにはどうすればいいかを考えるのが事後分析の目的で、ヒューマンエラーを責めるだけじゃなくて、システム的に改善しようとするんだ。
問題は、何が合理的な安全対策なのかってことで、そのためには詳細を検討する必要がある。
CaMeLの提案はどう思う？
＞https://simonwillison.net/2025/Apr/11/camel/#atom-everything”,
他の問題は重要度が低いかもしれないけど、たとえ「自己責任」を受け入れたとしても、記事を引用させて。
＞さっきのマルチエージェントシステムの投稿で書いたように、LLMの信頼性は、与える指示の量と反比例することが多い。ほとんどのユーザーは、AIの宣伝に騙されて、データを増やせば問題が解決すると思ってるけどね。サーバーが大きくなるにつれて、アシスタントの性能は低下すると思うよ。リクエストのコストも上がるし。アプリケーションは、ユーザーにツールを選ばせるようにするかもしれない。
もっと強く言うと、MCPはスケールしない。一定の閾値を超えてスケールできない。エージェントのコンテキストにツールを追加すると、エージェントの能力に悪影響が出るのは避けられない。これはMCP全体の根本的な問題で、認証の問題よりも重要だと思う。「MCPは昔は良かったけど…」みたいな投稿が増えると思うよ。ツール同士が干渉しあうんだ。これは普通のパッケージシステムとは全く違う。パッケージシステムでは、干渉しないことが基本的な性質だから。それがMCPの問題。アイデアとしては、人々が期待するものとは違うんだ。
これはUIで解決できると思うな。例えば、意図しないMCPやツールが実行されたら、UIで簡単にオフにしたり、ツールの説明を編集して、いつ使うべきか、いつ使うべきでないかを明確にできるようにすればいい。それに、コンテキストが大きくなるほど、パフォーマンスと実用性が向上すると思うよ。だから、反比例するってことには賛成できないな。でも、場合によってはそうなることもあるかもね。
それだけじゃ解決できないと思うな。
GeminiとAI Studioを使ってて、100万トークンのコンテキストウィンドウの大きさが分かってきたよ。会話の両側に複数段落のテキストがある大きな会話で、10万トークンくらい。会話をスクロールするだけでも大変で、LLMに何について話してたか聞く方が楽なんだよね。だから、複数のツールがあって、それぞれがクエリに1万以上のコンテキストを追加して、全部合理的なツール要求だとしても、それって「意図してない実行」じゃないってことを確認できないんだよね。ツールの失敗状態の曖昧な説明だし。リクエストごとに小説を読むようなことはできないよ。
ある程度の可視性があると便利だと思う。コンテキストが大きくなるほど非現実的になるけど。
＞例えば、意図しないMCPやツールが実行されたら、UIで簡単にオフにしたり、ツールの説明を編集して、いつ使うべきか、いつ使うべきでないかを明確にできるようにすればいい。
複数のAIサービスへの個別の呼び出しを、通常のアプリケーションソフトウェアで繋ぎ合わせることで、もっと簡単に実装できるんじゃない？
簡単だよ。LLMが選択に迷うなら、分割統治すればいい。ツールを選ぶためのツールを追加するんだ。別のLLMを呼んで、タスクに最適なツールのサブセットを選ばせて、親エージェントに返す。ツールを追加しすぎて、ツールマスターエージェントが選択肢に圧倒された？簡単だよ。ツールを分類するエージェントを追加するんだ。事前に分類してデータベースに入れて、RAGモジュールにする。
方法はたくさんあるよ。選択には安いモデルを使うとか、動的な分類とか、前のチャットで成功したツールを優先するとか。
とにかく、間接的なレイヤーを追加すればいいんだよ。
問題は、ツールがコンテキストにあるだけでモデルの出力が大きく変わるってことだよね。だから、エージェントがコンテキストに関連するツールを見るのは役立つ（RAGとかが良い例）。全部”get_tools”リクエストの裏に隠すのは逆効果。
どのクライアントで、どのLLM使ってるの？俺はClaude Desktopで使ってるけど、良い感じだよ。思考モードより全然マシ。でも、Cursorとか他のLLMではまだ試してないんだ。
＞エージェントのコンテキストに無制限のツールを追加すると、エージェントの能力に悪影響を与えるのは避けられない。 ＞呼び出された時だけコストがかかって、ユーザーコンテキストに影響がある？ Claude desktopとかCursorみたいなLLMチャットボットのメーカーは、LLMに何がプロモートされてるかを正確に公開する必要があると思うんだよね。LLMがMCPサーバーを見つけるには、プロンプトに情報が必要じゃん。でも、ソフトがその情報をどう公開してるか隠してる。メッセージの先頭？コンテキストの最初？もしそうなら、ツールの可用性がリアルタイムで変わると、コンテキスト全体が無効になるんじゃない？だから、コンテキストの最後に追加するのかな？誰も完璧には理解してない。生のデトークン化された入力と出力を見せてくれるLLMフロントエンドが必要。構造化とかいらないから。入力blobと出力blobを見せてくれ。 最近、カスタムMCPサーバーを書いたよ。 ＞オーバーヘッドは固定費で、セッション初期化時に一回だけ払うもの？ 君が言うように、クライアントが知ってるMCPサーバーは、それぞれ機能を持ってて、その機能には定義がある。そして、それらは全部LLMに提供されないと使えない、ってのはその通り。そして、LLMは汎用だから、MCPの詳細はトレーニングされてないし、組み込まれてない。だから、クライアントが提供する必要がある。そして、トークンを食いつぶすのも確かだ。でも、毎回リクエストに入れる必要はない！LLMとのやり取りは、ステートレスなリクエスト/レスポンスじゃない。セッションベースなんだ。だから、メタデータとか、ユーザー定義の好みとか、メモリとかは、セッション初期化の一部として送る。これは、一般的に理解されてる「prompt」の一部じゃない。 「prompt」って言葉のせいで誤解が生じてる気がする。ユーザーとしてOpenAIに送るpromptがある。そして、LLMに送られる”prompt”がある。会社でどう呼ばれてるか知らないけど、OpenAIはユーザーが送ったpromptに、いろいろ追加してる。例えば、独自のシステムメッセージとか、ユーザーのシステムメッセージとか。だから、＜OpenAIのシステムメッセージ＞＋＜ユーザーのシステムメッセージ＞＋＜ユーザーのprompt＞みたいになる。それがLLMに送られる「最終的なprompt」だ。これには同意してくれると思う。 MCPでは、最終的なプロンプトに＜ツールの説明＞も追加してるんだよね。そこは意見が一致してるみたいだね。 ＞その情報はセッションを通じたすべてのやり取りに適用される ＞LLMの「セッション」なんて存在しない MCPのアーキテクチャは、エージェントソフトウェアと統合だけでなく、それらすべての（n choose 2）の関係の間で、根本的に非常に高い信頼を置いているってことだと思うんだ。LLMでコードを直接アドレス空間にロードして実行するのと同じことをしてるんだよね。dlopenは信じられないほど強力だけど、MCPで解決しようとしている問題は、そこまでの信頼レベルじゃないんだ。実際の信頼レベルは、OAuthフローのようなもので、データプロバイダーがあらゆる統合を監視してる状態。プロトコルとその実装が変わらない限り、すべてのMCPサーバーが、メールで「LLMが何かをしようとしてるけど、リンクをクリックして承認して」みたいなサイドチャネル検証を始めると思う。その未来では、Appleの「自動化を実行するには通知をクリック」と同じように、エージェントの有用性が著しく低下するだろうね。 最初はそうかもね。でも、ユーザーが「常に許可する…」みたいなプロンプトを要求して、また同じ状況に戻るんだよね。何十ものエージェントが数万トークンのコンテキストで実行されてることを考えると、これらの問題は些細なことに思えるかも。これらのセキュリティ上の懸念を考慮したUIを想像できるよね。もし何百ものエージェントがそれぞれ1万以上のトークンを100万以上のコンテキストに注入すると、UIソリューションは崩壊すると思う。今日解決しようとしている問題は、LLMのサイズと複雑さが増し続けるにつれて通用しなくなるんだ。 ＞使用量を制限して監視しろよ。どうせやるべきなんだから。制限速度を守らせるのは道路の仕事じゃない。 その通り。APIが使用制限やレートを通知するのは普通だよね。適切なエラーコード（429）とバックオフ時間に関するドキュメントもあるし。サービスが受信するシグナルを尊重するように設計すれば、すべてがスムーズに進むんだ。そういったものをMCP仕様に組み込むか、少なくとも共通のルールを適用すれば非常に役立つと思う。データtaint追跡、認証、トレースなども同様だよね。優れたエコシステムがあれば、すべてがうまく連携するんだ。 道路のたとえを拡張すると、どこに行くかを制御して、誤ってか故意にか、逸脱しないようにする道路を作ることもできるよね。それはrailと呼ばれていて、安全性の保証と引き換えに汎用性が低下するんだ。 なんでそんな簡単にMCPで機密データを公開するのを受け入れる人がいるんだ？ 人は何かをするために多くのリスクを受け入れるんだ。LLMは非常に多くの可能性を提供してくれるから、みんな使ってみたくて試すだろうし、経験を通して欠点を軽減する方法を学べるんだ。 めっちゃわかるー。最終的にはMCPが全部解決してくれるなんて思ってないよ。そうじゃなくて、MCPってアプリ開発者とかユーザーが知っとくべき問題が起きやすい場所を作ってるってこと。 煽りっぽくて雑な感じ、最高じゃん！「道路がスピード制限する必要ない」って言うのと同じだよね。まるで、都市計画が下手な人が25mph制限の6車線道路作って、みんなが65mphで走るのを不思議がってるみたい。スピード違反取り締まって罰金取るか、見た目だけ取り繕うか、みたいな。 自分でレート制限とか使用状況を監視すべきだよね。どっちにしろ必要だし。＞スピード制限を守らせるのは道路の仕事じゃない”って言うけど、都市計画家はスピード制限を守らせるように道路を設計することもあるよ。Traffic calmingとか見るとわかる。 ＞スピード制限を守らせるのは道路の仕事じゃない” MCPはただの通信手段＋データ形式で、リクエスト/レスポンスのライフサイクルとツールレベルの認証があるだけ。一番の問題は、AIエージェントがツールを組み合わせて使えないこと。あと、そもそもMCPいらない説。LLMはOpenAPIで定義されてるAPIなら全部使えるじゃん。足りないのは認証だけ。MCPの一番の不満は、ツールの結果をストリーミングできないこと。ModexっていうClojureのMCPライブラリの作者です。 MCPについての過去の考えをまとめたよ。 PDDLって初めて聞いたけど、x.comのリンクを辿る手間を省くために引用するね。 MCPはプロトコルとして定義されてるんだけど。トランスポート層については何も言ってないし、stdioを強制してるわけでもない。 @kiitosさん、残念だけどあなたは騙されてますよ。 認証についてだけど、確かにMCPは認証について何も指定してないね（APIキーのための環境変数とかはあるけど、それはホスト固有のもの）。でも実際には、ホスト（例えばAnthropicのClaude Desktop）は、特定のMCPツールを呼び出す前に許可を求めてくる。これはMCPの仕様の一部じゃないけど、MCPが存在する大きな理由の一つは、モデルにHTTPアクセスを無制限に与えるのを避けるため。仕様に入れるべきだと思う。 だから俺はこれをEEEって呼んでるんだよね。Anthropicが認証付きのHTTP APIエンドポイントを追加するだけで、みんながコピーして、Anthropicは仕様をコントロールできなくなって、将来の競争相手を締め出せなくなるから。MCPの仕様は堀みたいなもんで、前にも見たことあるよ。使うけど、好きじゃないんだよね。つまり、MCPは存在すべきじゃないってこと。OpenAIがAPIエンドポイント＋認証をサポートするだけで、もっと強力になるのに。VCが資金提供してる企業は堀に抵抗できないんだよ。 OpenAPIを使ってないものなんてたくさんあるよ。ほとんどそうじゃない？たとえ全部OpenAPIだとしても、LLMがどうやってツールを呼び出すかのプロトコルが必要じゃん。それをやってるのがMCPなんだよ。完璧じゃないけど、始まりとしてはいいんじゃない？ AIはドキュメントとかSwaggerとかOpenAIとかREADMEを読めるから、MCPは何も追加してないと思うな。必要なのは、エンドポイント認証付きのHTTPクライアントだけ。例えば、Datomic MCPでは、モデルにdatomic.api/qを呼ぶように指示するだけで、正しいDatomic Datalogクエリを書いてくれる。AIはHTTPリクエストを知ってるから、HTTPクライアントがあれば十分。だからMCPはいらないと思う。IMO、MCPはAnthropicによるEmbrace、Extend（Extinguish？）戦略だよ。「HTTPレベルでの統合をやりたくない」っていうのは説得力がない。必要なのは、HTTPクライアント＋SSEサポート＋エンドポイント認証＋妥当なタイムアウトだけ。APIドキュメントが残りをやってくれるよ。 OpenAPIがすべてをカバーしてるわけじゃないっていうのは、その通りだよね。WSDLとかもそうだったし。でも、なんで新しいものを始める必要があるのかな？まずはOpenAPIから始めるのがいいんじゃない？ OpenAPIはMCPが解決する問題を解決できないからだよ。LLMとそのホストはどうやってツールを呼び出すの？ OpenAPIはそれを解決してくれないでしょ。 ローカルのgit CLI用のOpenAPIクライアントを作るの？すべてのツールにOpenAPI準拠のHTTPサーバーが必要になるの？AIにWebサーバーと通信させるのが目的ならわかるけど、もっと広い範囲が対象だよ。だから、より効果的なプロトコルが必要なんだよ。 ＞AIエージェントがツールを機能的に構成することを可能にしない。 OpenAIのツール呼び出し仕様は見てないけど、Erik Meijersが言ってるように、MCPには戻り値の型がないから、構成が難しいんだよね。型付きエンコーディングがないから、I/Oが避けられないし。MCPを削除して、関数レベルでevalが許可されたREPLをAIに与えるのが最終目標だと思う。だから、AIの時代には、Clojureみたいな動的言語が有利なんだよ。 マジでgRPCいらなくね？ ツールの呼び出し全部SSEとして扱えばストリーミングできるじゃん。HTTPはかなり使えるし。 HTTPのServer-Sent Events (SSE)って、バッチ処理のストリーミングとか、完了通知とか、ネイティブじゃサポートしてないんだよね。 この記事、MCP自体の批判っていうより、LLMがサービス上でアクション実行できるようにするプロトコル全般への批判って感じ。 MCPを使うと、ClaudeとかChatGPTとかCursorとかVSCodeみたいな、こっちがコントロールできないLLMクライアントがAPIを使えるようになるんだよ。じゃないと、自分でLLMのAPI使うカスタムクライアント作らなきゃいけないから、ChatGPTとかClaudeの月額20ドルのサブスクリプション使ってツール教える方がずっと安上がり。 LLMクライアントにAPIキーとAPIドキュメントのURL教えれば、自分でAPI使えるんじゃないの？ 全部のクライアントが対応してるわけじゃないんだよねー。今はChatGPTのカスタムGPTアクションくらい。標準じゃないんだ。 ある意味、MCPってAPIを文書化して、呼び出し方を記述する方法なんだよね。APIをラップするのにちょうどいい感じの抽象化で、複雑になりすぎない。余計なものがないから、ユーザーが自分で失敗する余地があるってのが記事の内容だね。 それもアリだけど、ツール使うたびにLLMにやり方説明しなきゃいけないじゃん？ ＞You could do that. But then you need to explain to the LLM how to do the work every time you want to use that tool 確かにそうだけど、毎回プロンプトに追加しなきゃいけないじゃん。LLMプロバイダーに「これ使えるツールだよ」ってAPIドキュメント付きで一回伝えれば、毎回言わなくても色んなチャットで使えるようにしてほしいよね。あと、デスクトップのLLMクライアントにローカルのプログラムへの接続方法を教えられたら最高じゃん？MCPはそういう問題を解決してくれるんだよね。 elektronユーザーだけど、マジ感謝😊 ChatGPTはまだMCPに対応してないんだよね。ここ数ヶ月でGoogleとかAnthropicにマジで置いてかれてる感じ。Gemini proはo1 proより全然いいし。 ＞なんでHTTP APIを使わないの？ イマイチ分かってないかも。LLMに外部リソース（プロバイダー）を接続するための標準APIってこと？それぞれがツールと状態を公開して、LLMがそれらのリソースと通信するためのクライアントサイドコネクターが必要…ネットワークコールとかローカル環境でのI/Oを処理するやつ。そんな感じ？ だいたい合ってるよ。LLMのツール呼び出しの「形」はMCPのツール呼び出しの「形」にすごく似てるんだ。ツールをエージェント（ひいてはLLM）に接続するためのシンプルな標準なんだよね。他にもリソースとかプロンプトとか色々あるけど、全部LLMとエージェントとツール/データの統合に関係してるんだ。 APIは持ってるんだけど、Claudeみたいなのが使いやすいようにMCPを構築したんだ。Claudeに特別なツールを与えるのはマジで大変だからね。 AIモデルに公開するFunction callingのスキーマと、実際に使うAPIの間にブリッジが必要なんだよね。 週末にMCPを触ってみたけど、マジでそれな。ユーザーのXを取得して、それを自分のエンドポイントに送って何かしたいだけなんだよね。そんな高度な抽象化はいらないって。 もしあなたがツールプロバイダーなら、AIエージェントのフロントエンドがあなたのツールに接続するための標準プロトコルが必要だよね。 その標準プロトコルがHTTPとOpenAPIじゃダメなの？ってことだよね、このコメント主は。 スタンドアロンAPIだけが必要な場合とか、どのAPIを呼ぶかハッキリしてるなら問題ないと思う。でも、ユーザーが質問したり、どのAPIを使うべきか分からなかったりする場合は、MCPが解決してくれるかも。過去のメッセージに基づいてリクエストを処理できるし。 APIだよ。生のリクエストライブラリを使えば、Pythonで全部スクラッチで実装できる。情報交換の標準化のアイデアで、特にClaude codeみたいなエージェント体験向け。 これって、システムをプロバイダー側にもっとコントロールさせようとしてるんじゃないかって気がする。数年後には、AnthropicとかGoogleとかがAPIをオフにし始めるかもね。 だよね。OpenAPIを使えば、エージェントは必要なAPI仕様のコンテキストを/openapi.jsonから取得できるし。 チャットで何か言いたいだけなのに、インプットデータを用意して、APIに送って、アウトプットをパースして答えを探して、それを毎回繰り返すの、マジ勘弁。もっとコメントを表示（1）
え？MCPサーバーはエージェントだけじゃなくて、MCPで話せるクライアント全部のためだぜ。MCPサーバーの機能はオンデマンドで、クライアントにしかコストがかからない。ユーザーコンテキストに影響があるのは、呼び出された時だけ。
調べてみなよ。クロスサーバーインジェクションの例とか。絶対に違うから。MCPサーバーってのは、LLMが使えるツールを提供するもの。ツール定義を追加することで実現する。ツール定義はLLMのプロンプトに入るコンテンツだ。それで動くんだよ。LLMがどうやってツールを使うか決めると思う？ツール定義がプロンプトにないと無理じゃん。APIが隠してるかもしれないけど、絶対こうなってるって。第三者のコンテンツをプロンプトに入れると、LLMの性能（とコスト）に影響が出る。MCPサーバーを有効にするほど、プロンプトがツール定義で汚染されて、結果が悪くなる。システムプロンプトに大量のゴミを流し込むのと同じ。最初は良いけど、スケールアップすると性能が下がる。参考資料：https://github.com/invariantlabs-ai/mcp-injection-experiment… https://docs.anthropic.com/en/docs/build-with-claude/tool-us…
もっと正確なコンテキスト編集と可視性が欲しい。そうすれば、モデルに何をプロンプトすべきか、もっと情報に基づいた選択ができる。
MCPツールのトークンコストは？LLMには名前、説明、パラメータが必要でしょ。ツールごとに最大100トークンくらい？大したことないけど、ゼロじゃない。
＞MCPサーバーってのは、LLMが使えるツールを提供するもの。
ツールは、MCPサーバーが呼び出し元に提供できる機能の一つ。「prompt」や「resource」もある。
＞ツール定義を追加することで実現する。ツール定義はLLMのプロンプトに入るコンテンツだ。それで動くんだよ。LLMがどうやってツールを使うか決めると思う？ツール定義がプロンプトにないと無理じゃん。
「prompt」の定義が広すぎない？ユーザーが提供する入力テキストだけじゃなくて、ユーザーやクライアント固有のメタデータも全部含んでるんでしょ。良いけど、明示的にしたいだけ。この前提で言えば、クライアントに追加されたMCPサーバーは、オーバーヘッドを追加するってのに同意する。でも、オーバーヘッドは固定費で、セッション初期化時に一回だけ払うものだよ。リクエスト/レスポンスごとに毎回じゃない。だから、ユーザーリクエストの処理コストに比べれば、統計的なノイズにしかならないと思う。
https://docs.anthropic.com/en/docs/build-with-claude/tool-us…
この「tool」の概念はMCPとは完全に無関係。
https://github.com/invariantlabs-ai/mcp-injection-experiment…
このリポジトリとその批判がよくわからない。著者は関連するブログ記事を書いている https://invariantlabs.ai/blog/whatsapp-mcp-exploited そこにはこう書いてある。
＞このブログ記事では、信頼できないMCPサーバーが…
でも、「信頼できないMCPサーバー」なんて存在しない。MCPサーバーはすべて信頼されてる前提だよ。
俺は基盤モデルのプロバイダーで働いてないけど、ツール定義がどうやってLLMに入ると思う？ツール定義でモデルをファインチューニングしてるわけじゃないでしょ？OpenAIのベースモデル（またはClaude、Geminiなど）を使ってるだけじゃん。だから、ツール定義はプロンプトに追加される必要がある。プロバイダーが自動的に追加してるんだよ。それはコンテキストウィンドウを食いつぶしてる。プロバイダーが予約してる部分をね。最終的なプロンプトの中で、あなたが見たり変更したりできない部分。
これらの会社で働いてないし、機能を実装してるわけじゃないけど、すべてのリクエストに追加しないと機能しないと思う。だから、スレッドの作者の主張は正しい。
MCPでは、＜ツールの説明＞もその「最終的なprompt」に追加される。これも同意してくれると思う。最後の議論点は、「最終的なprompt」（または正しい用語）が大きくなること。プロバイダーのシステムprompt、ユーザーのシステムprompt、ツールの説明、実際のユーザーpromptのサイズ。この「最終的なprompt」のコストを、リクエストごとに払う必要がある。もし、「最終的なprompt」のサイズがLLMの性能に影響を与えるなら、ツール定義をたくさん追加すると、LLMの性能が低下するってことになる。
LLMとのやり取りはセッションベースで、セッションを作成すると、そのセッションの一部として情報が一度だけ送信され、その情報がセッションを通じたすべてのやり取りに適用されるんだ。その初期データには、ユーザー設定やクライアントが指定したモデル構成、MCPサーバーの定義などのコンテキスト情報が含まれてる。何か入力してエンターキーを押すと、それはユーザープロンプトになり、送信前にいくつかのものが追加されるかもしれないけど、セッション開始時に提供された初期データは含まれないんだ。
マジか… llama.cppサーバーをデバッグモードで実行して、LLMに送られる内容を確認した方がいいかも。verboseフラグかOLLAMA_DEBUG=1（ollamaを使ってる場合）でできるよ。
言ってることと実際が違うんだよね。LLMの「セッション」なんて存在しないんだ。それはAPIの上に構築された高レベルの抽象概念で、サーバーがプロンプトの一部をキャッシュして、UIで入力した断片と組み合わせてからLLMに渡してるだけのこと。技術的な実装方法はどうでもいいんだよね。ツールを呼び出すリクエストは、最終的にツール定義を含む定義に変換されてLLMに渡されるってこと。ツールの定義が増えるほど、LLMのパフォーマンスに明確なコストがかかるんだ。その唯一の解決策は、有効にするツールの数を制限すること。それは十分に可能で合理的でもあるんだよね。ツールをどんどん追加してもスケールしないし、うまくいかないってこと。ツールが少ない場合にしか機能しないんだ。もし50個のMCPサーバーを有効にしてたら、リクエストの質は低下してるかもね。
Open AIでの動作と一致するね。会話に20～30の質問制限がある理由もこれで説明できる気がする。リクエストごとに送信する必要があるコンテキストがどんどん大きくなるからね。
もっといい例えは車だよね。速度を正確に表示し、速度を上げるには意図的な操作が必要になるように法律で義務付けられてるんだ。
道路を作る人は、速度制限を調査して明確に掲示する必要があるんだよ。
電車では得られない柔軟性が必要で車に乗ってきたのに、道路がrailじゃないって文句を言うなよ。
あと、MCPはAIエージェントの信頼性を高めるわけじゃない。ツールへのアクセスを増やすだけで、場合によっては信頼性を低下させることもあるよ。
https://medium.com/thoughts-on-machine-learning/mcp-is-mostl…もっとコメントを表示（2）
良い道路設計ならスピード出すのは無理じゃね？
・“MCPはスキーマであってプロトコルではない”
・“PDDLの方がMCPより面白い”
・“MCPについて知れば知るほど嫌いになる”
・“さらに考えると、MCPは存在すべきではない”
・“新しい言語やフレームワークには、有名になる方法がある”
＞このPDDLのプランニング例は、MCPがやろうとしてることよりずっと面白い。
モデル間の連携を可能にする標準的なプランニング言語を想像してみて。多分、俺が作るかも。
＞MCPの主な機能は認証”
MCPには認証機能ないよ。的外れだと思う。
1．MCPはstdio/stdoutとHTTP w/SSEの2つのトランスポート層を指定してる
2．MCPはJSON-RPCをデータ形式として指定してる
これは既存のRPCプロトコルの上にスキーマを載せただけで、新しいプロトコルじゃないと思う。ModexでstdioトランスポートとかJSON-RPCデータ形式とかツールのサポートを実装したよ。
OpenAIのツール呼び出し仕様には、それを妨げるような何かがあるのかな？
LLMが勝手に困るような行動起こすのが問題だって言ってるけど、LLMのアクションには、お任せでいいものと、確認が必要なものがあるよね。
＞ユーザーに確認を求めるのを拒否してるのは、ほとんどのツールが無害だから自動確認（YOLOモード）に陥りやすいからだって。
それって心理的な問題じゃね？技術的な問題じゃないっしょ。
俺はUSB経由でFM音源ハードウェアシンセに繋がるMCPサーバー作って、サウンドデザインやらせてるぜ：https://github.com/zerubeus/elektron-mcp 。もっとコメントを表示（3）
Anthropic、Google、OpenAIはMCPを共通プロトコルとして採用することに合意したらしいよ。これのおかげでClaudeとかChatGPTとかCursorみたいなLLMクライアント作りやすくなる。API使ってLLMにAPI使わせたいなら、APIキー渡すだけじゃ無理で、エージェント作らないと。
それに、APIがちょっと変だと、LLMが「正しく」使えないリスクもあるし。（情報が足りなかったりとか。）
説明とか毎回やるのって、トークン無駄遣いだし、時間もお金もかかる。
MCPは全部まとめて、LLMが使いやすいようにしてるんだよ。（他の人とツール共有もしやすいし。）
新しいAPI使う時にLLMに指示出して、MCP実装作らせれば、次回から簡単に再利用できるよ。
それってコンピュータとLLMの根本的な誤解な気がする。APIの記述を取得する方法ってあるじゃん、Open API specっていうの。MCPがツールスペック取得するのと同じように。
LLMがOpenAI spec ＋ keyをダウンロードしてコンテキストに入れられない理由なくね？ MCPがカスタムスキーマでやってるように。
ローカルのリソース（ファイルとか環境変数とかネットワークアクセスとか）をLLMにアクセスさせるためのものなんだよね。だからローカルで動かしてLLMがアクセスできるように設計されてる。
でも、MCPサーバーからHTTPコールするのを邪魔するものは何もないよ。実際、そういうユースケースのためのプロキシサーバーもいくつかあるし。
APIはそのままじゃ使えないから。MCPのコアはツールで、ツールはFunction callingに変換する必要がある。MCPはその変換をやってくれるんだ。
ツールはAPIでもいいけど、Function call ==> Toolの変換レイヤーが必要で、MCPがその役割を果たすんだ。
Fortitudeを開発中:
https://github.com/arthurcolle/fortitude
GmailでIMAP/SMTPを使うのが難しくなったみたいに。
