MCPの何が問題なのか？
引用元：https://news.ycombinator.com/item?id=43945993
MCPの仕様書、これLLMが作ったせいでマジでダメダメじゃん。人間がちゃんと考えてないのがバレバレ。仕様書作るのって、最終文書よりその思考プロセスが超大事なのにさ。エッジケースとか全部洗い出して、ちゃんと質問に答えられるまで練り上げるのが普通でしょ？なのにこれ、内容がバラバラだったり、箇条書きばっかだったり、無個性だったりするのはまだしも、最大の証拠は「人間がほとんど考えてない」ってことだよ。主要な仕様書としては考えられないレベル。
DeepSeekのドキュメントは別の問題ね。スペルミスとか変な言い回しだらけなのよ。「We will try out best」とかさ。まぁ、だいたい読めるからいいんだけど、超不気味なんだよね。考えてみて？言語扱う専門の会社でしょ？世界最高の英語モデルまで一時期持ってたのに、なんでプロっぽいドキュメント作れないわけ？スペルミスとか文法ミスなしでさ。
何が問題？引用した部分の具体的にどこを変えたいか教えてよ？
君、英語ネイティブ？ DeepSeekドキュメントの引用部分、具体的にどこが変か教えてあげるね。「rate limit」とか「try our best」とか、非ネイティブっぽい言い回しばかりなんだよ。DeepSeek本体の英語はうまいから、これはLLMじゃなく人間（非ネイティブ）が書いたっぽいね。
CCP関連の地方政府機関の文書見たことあるけどさ、国際銀行向けの融資申請とかの詳しいやつね。 DeepSeekのドキュメント、あれに比べたら雲泥の差でマシだよ。あれは政府機関から国際機関への公式文書なのにね。
Amazon製品の説明文の英語、昔から変なのばっかで気になってたんだよね。「OPTIMUM GIFT」とか「INTIMATE SERVICE」とかさ。LLMを使えばタダで完璧に翻訳できるはずなのに、なぜか質の低いまま放置されてるのが謎なんだよね。なんで中国はLLMを使わないって決めたんだろう？
口語の英語なら、俺の言い回し（”response times may be slower”）は全然OKだよ。もちろんlongerでもいいけどさ。実際に使われてる例、いっぱいあるし。
英語ネイティブじゃない人（特に東アジアのエンジニア）が、自然な英語を書くのはすごく難しいんだよ。英語を世界の基準だと思ってるネイティブが多いけど、それは違う。DeepSeekの英語も、多少変でも意味は通じるでしょ？自然な英語を書く能力って、それ自体が超高価なスキルなんだから、簡単にできることじゃないんだよ。
ポストの意図がわかんないなー。DeepSeekが良い英語翻訳できるのに、それがないフリしてるの？なんでそんなフリすんのさ？
ネイティブだけど、awkwardって主張にはちょっと異論あるよ。”when our servers are under high traffic pressure”は最後がちょい変だけど、”when our servers are under pressure from high traffic”なら良い感じ。”high traffic”って表現は面白いと思う。技術文書の英語ってすごく標準化されてるけど、それって英語の狭い使い方なんだよね。そこから抜け出したからって、別に変ってわけじゃないと思うな。
改善について話すとき、普通「上」が良い意味で「下」が悪い意味だよね。”response times will be higher”って言うと、一瞬改善したみたいに聞こえちゃう。すぐ逆だって気づくけどさ。だからグラフとかに”lower is better”って注釈つけるんだよ。俺はネイティブだけど、”slower”とか”faster”って言葉を使うようにしてるな。意味がわかりやすいから。
誰かClaudeがOpenAPI使えるようにMCPのアダプター作ってくれるっしょ。そしたらMCPのことなんて忘れられるよ。
外国語の技術文書を別の人に書いてもらうのが簡単な問題じゃないってフリはやめようぜ！中国人ネイティブじゃない人に全部書き直せってのは、無理な要求だよ。多くのHNerの連中は普遍文法理論を信じすぎてて、言語なんてただの出力フォーマットでヘッダーが違うだけ、みたいに見てるけどそれは違う。言語は少なくともCODECなんだ。元の話に戻ると、違うCODECの間で翻訳すれば損失や劣化が出るってのは、別に変な話じゃないと思うんだ。
中国で完璧に英語ができる人を見つけるのって、そんな簡単じゃないんだよね。例えば、LC SignsのTonyってめちゃバズった人のskit以外の英語も、結構中国語っぽい感じだよ。友達の元カノで、Oxbridge出てた中国人の子も、強い中国語訛りがあったし、書くときも文法ミスが結構あったなー。イギリス人はその子のこと流暢って言ってたけどさ。
それは甘い解釈だね。Mandarinは知らないけど、あれは母語から英語への文法構造の転移じゃないかな。Dutchの人が”make a picture”とか”the house of my parents”って言うのと一緒で、linguistic flairじゃなくてawkwardって分類するのが妥当だと思う。もし自分の文章を誰かが編集してて、母語（Portuguese）由来の文法ミスを”flair加えてるね”って言われたら、なんか見下されてる気分になると思うな。スタイルの選択じゃないんだから。
DeepSeekが中国で完璧に英語できる奴だよ。
これ、5年前なら良い議論になっただろうね。今じゃ意味ないよ。DeepSeek自身がきれいにして完璧な英語を出力できるんだから。
ADHDなのか、コンテンツのせいなのかわかんないけど、面白い文学は何時間でも読めるのに、LLMが書いたくだらない文章は数単語でダメになるんだよ。RedditでボットがAITAみたいな定型的な荒らし投稿してるの見るとヤバいなって思うけど、それと同じLLMを技術仕様に使うのって恐ろしいよな。だって作者が知らないクソみたいなことを大量に言っちゃう可能性があるんだぜ。作者は文字読めないレベルで、それが普通、みたいな状況だから…。心配だよ。
A/Bテストしたのかもね。みんな”INTIMATE SERVICE”って表現の方が好きなのかも…。
AIコーディングベンダーは、人間には理解できないけどAIにだけ分かるコードを意図的に作り、囲い込みを狙ってるんじゃないか。これプログラミング史上最大の”ロックイン”かもね。もしAIが数年でプログラマーを完全に置き換えられないなら、この戦略は失敗して自分たちの市場を壊すことになるんじゃないか。顧客がサービスを使ったせいでね。
この文章、ネイティブスピーカーのバージョンの方がひどい例だね（この場合は、親コメントが指摘したように、ただ意味不明だから）。
”response times will be higher”ってすぐに改善されたって感じがするよね。低いより高い方がいいってこと？僕には全く意味が分からないな。
うん、これ僕には読めないわ。
技術ネタについてLLMの駄文を投稿するトレンドがあるけど、あれマジで腹立つんだよね。なんで人の時間をあんな風に無駄にしたいのか意味不明。
さらにひどいことに、デベロッパー向け情報サイトを装って、全く間違った情報ばっかのAI駄文サイトに出くわしたこともあるよ。
日常会話の英語では、僕の表現は問題ないよ、たぶんね。
でも、僕の意見では、誤解の余地が全くないように書くのが一番良いと思うな。
日本で英語の文書（メニューとか）を読むと、同じ文書内で同じ単語のスペルがよく違うんだ（例: ”curbside”が”crubside”とか）。
機械翻訳っぽいのに、どうして？たぶん、機械翻訳の出力結果を人が手で打ち直してるんじゃないかと思うんだけど、不思議だよ。
効率重視の僕らPCオタクは、そうじゃない人たちがコンピュータをどんな変な風に使ってるか想像つかないんだよね。
元の仕様書がAIアシスタンスで書かれたかは言えないけど、コミット履歴[0]をざっと見た感じでは、彼らがただ露骨にドキュメントを自動生成してるわけじゃないみたいだね。gitの履歴を見ると、彼らは仕様について考えてて、仕様変更に合わせて手動でドキュメントを更新してるのが分かるよ。[0] https://github.com/modelcontextprotocol/modelcontextprotocol…
だってA/Bテストっていつもハッピーエンドだもんね。
俺の経験だとね、AIスタートアップってAIマキシマリストなんだわ。何でもかんでもAI使うの。会議の議事録、検索（Perplexity）、コードや契約書、SEO、人材採用とかね。だからAIで仕様書書くのもマジでありえると思うよ。
暗号資産界隈が速攻で学んだみたいに、LLM界隈は今”ソフトウェアの作り方”を速攻で学んでるね。リモート機能の公開ってコンセプトは、DLLとかgRPCとかに既存例いっぱいあるのに、学んでないみたい。でも、数ヶ月でもっと成熟するかもね。
1750への返信ね。
それか初期Pythonみたいに、間違いが下の層で固まっちゃうパターンね。上位ツールが依存しちゃうから。
でもAI界隈は言い訳できないよ、だって同じ間違いの既存例があるんだから。
もっとコメントを表示（1）
うん、プロトコル自体は問題ないと思うな。問題はHTTP側のトランスポート部分が最悪みたいだってこと。
この記事、WebSockets知ってる人がSSE学びたくないみたい。
WebSocketsやめたのは賛成、SSEはHTTPだし。
でも、ローカルでHTTPサーバー動かせばいいのに、なんで”stdio”トランスポートがあるのかは謎。
static関数（lenとかmap、filterとか）が、オブジェクトのメソッドであるべきだったってこと。
昔の開発言語は決定的だったけど、今はLLMが関わってるから確率的になったんだよね。
JSONが好まれるのは、複雑さを増やすからだと思うな。
昔は決定性が大事にされてたのに、今は逆に遅く感じるなんてすごいよね。てか、LLMエージェントのテストケースってどう書くの？結果が「まあまあOK」か「ダメ」かを別のLLMに判定させるのかな？
HTTP呼び出しは内部でもFWにブロックされることがあるし、stdioアプリのためだけにhttpエンドポイントを公開させるのはやりすぎでしょ。例えば、MCPクライアントがstdioなしでgitコマンドにどうアクセスするの？ラッパーサーバー動かすか、stdio使うかだよね。
経験者がXMLの方がうまくいくって言ってるのは、冗長だからってことらしいね。
JSON-RPC知ってるなら：これはAI向けに公開されたJSON-RPCラッパーで、検出もできるよ。RESTとかhttpリクエスト知ってるなら：単一エンドポイントで、”type”か”method”パラメータで分割／ルーティングされてて、AI向けにちょっと仕様が違う感じだよ。
JSONがうまくいくのは、冗長で各レコードに何が入ってるか分かりやすいからだと思うな。
そもそもRESTのポイントってランタイム検出性じゃなかったっけ？もちろん、実際のRESTは検出性がイマイチなJSON－RPCみたいに見えるけど、それはSwaggerとかで無理やり付けてるだけっぽい。でもさ、MCPは（ちゃんと実装された）RESTにできないことを何してるの？
＞ 例えば、MCPクライアントがstdioなしでgitコマンドにどうアクセスするの？
MCPクライアントはコマンドにはアクセスしないよ。MCPサーバーが公開するツールにアクセスするんだ。
この観点から見ると、XMLはそれ全部に加えて名前付きの括弧も提供してるよね。
ねえ、なんか人間が理解したり関わったりするのを最小限にしようとしてるっぽい業界に、読み書きとか理解力とか期待するのは無理ありすぎじゃね？
はっきり言って、こんなのが問題ならAIが全部解決すんじゃん、アホくさ．/s
冗長性？それとも、LLMって言語を扱うんだから、マークアップの方が自然に注釈つけられるから？マジで気になってるけど、答えは知らないんだよね．
直感だけど、JSONはデータ転送のペイロードとしては読みやすくて良いけど、テキストの特定部分にリッチなコンテキストを持たせるなら、XMLの方が得意そうじゃん？
そうそう、しかもリクエストごとにループでやんなきゃいけないんだって．冗談抜きでマジ．それ”LLM as judge”って呼ばれてるんだよ．
確かにね．インライン属性があればもっと良いかも．
”old timer”コメントには首をかしげるね．SSEはWebSocketsより古いし、俺は1999年からSSEっぽいことやってたよ．根本的な問題はSSEじゃなくて、statelessなはずのJSON-RPCをstatefulに使ったことだ．これが全ての mess の原因．stateをちゃんと分離して扱えば、transport の問題だって起きなかったはずだね．
俺が使ってるカスタムのMCPツールのコードを見せるね．コマンド実行してstdoutやstderrをパースするやつだよ．
（コード省略）
厳密にはNodeが実行してるんだけど、俺にとってはこれもMCPクライアントみたいなもんだね．
きっとGraphQLを手本にしたんだな、間違いないね．
冗談だって言うけど、適切なプロンプトさえあれば、LLMがMCPよりずっと良い仕様書を書いただろうってほぼ確信してるよ．他の人も言ってたけど、MCPがやろうとしてることの参考にできるプロトコルはたくさんあるんだから、LLMならどうやるべきか”知ってる”はずだ．．．ってか、SSEと別に”write”エンドポイント使うのは絶対違うだろ．
ちょっとLSPを思い出すな．あれも似たような突貫工事で、元のアプリのローカルな部分だったはずの前提が山盛り詰め込まれてる感じ．．．それが今や標準として出回ってる．そうそう、明らかにそのモデルを真似しようって意図的な選択っぽいね．
こんなの使わせようとするなんて、マジでヤバいビジネスだな．そこそこの結果得るために、金払って買ったLLMを、さらに金払って別のLLMで監視させるなんて、悪魔的な天才だよ．誰かに嫌われる覚悟で言うけど、まるでモルモン教の天才みたいだ．こんなビジネスモデル、俺には考えつかないくらい賢くて大胆だよ．
根本原因は何なんだ？Pythonの機能セマンティクスをダメにしてるよな。内包表記だけじゃ足りないし。
記事ほぼ全部同意だよ。あとMCPのサイト見に行ったけど、中身全然なくて俺と同じくらい困惑してた人がいたって聞いて嬉しい。RFCs読むのめんどくさいけど、”とりあえず俺たちのSDKライブラリ使って”より全然マシだよね。
同意…これ大事なブログだよ。みんなMCPの採用は一旦待つべきだね…業界標準になるには、技術的な基礎が全然しっかりしてない設計だから。みんなLangChainとか他の多くのプロジェクトみたいにこれに熱狂してるけど、実際に実装に入り込んだら、求めてたものと違うってだんだんわかると思う。要は数人が適当に作ったハックで、怪しい決定が山ほどあるんだ。websocketsも大きな失敗の一例だよ。
正直Langchainのリポジトリ、ソース読んだら笑えるくらいひどいよ。あんなクソみたいなコードで資金調達できたなんて信じられない。場所とタイミングが良かったんだろうね。
うん、同意。Langchainのリポジトリが登場した頃に数時間かけて見てみたけど、正直どんな価値があるのか全然理解できなかった。当時はただのラッパーと、いくつか適当に考えられたデータ構造の集まりだった。実際のビジネスロジックはほとんど見つけられなかったよ。
不必要なoopのごみとプロジェクトをくっつけることで、むしろ負の価値を提供してるんだよ笑
aws bedrockで”bedrock”って代わりに”bedrock-runtime”を使おうとしてエラーになった時、Langchainはネイティブみたいにエラー返さずKeyErrorになったんだ。共通のエラー型とかなくて驚いた。よくある設定ミスなのに対応がひどい。
もっとコメントを表示（2）
こういうのって結局、ブルーオーシャンでみんながfomo（乗り遅れまいと焦ってる）ってことなんじゃないの？
ソフトウェアの質なんてどうでもいいんだよ！
仕様書が分かりにくいってのが問題みたいだね。公式サイトには明確な仕様がないし、まるでSonnetの出力みたい。GraphQLの仕様書はもっと分かりやすいのにさ。
リンク見るまで信じられなかったけど、マジでひどいね。中身全然ないじゃん。学生の頃に書いたアイデアメモみたいだ。驚きだよ、ホント。
俺だけじゃなかったんだ。最初 hype がすごくて読みにいったけど、結局 MCP が何なのか全然分かんなかったよ。
JSON-RPC 2 に特定のライフサイクルとかイベントを加えたものらしいよ。前に説明してるサイト見たけど、公式ドキュメントは見当たらないんだ。SDKをリバースエンジニアリングするしかないかもね。
SDKのコード読んでも、コードの品質とか構成とか、既存ツール使ってないとか、混乱する一方なんだ。まるで5つのJSONスキーマがトレンチコート着てるみたいな仕様だろ？マジでひどいよ。
MCP はツール連携の仕様としては有望だけど、認証とかストリーミングとかエッジケースが多くて、リモートサーバーだと結局 REST API と何が違うのか分かりにくいんだよね。REST API の方がずっと楽だし。もし大手ベンダーが採用しても、仕様外の UI とかやりたいだろうし、素性の分からないツール連携でユーザーに変なことされたり情報盗まれたりするのも嫌だろうから、なかなか難しいと思うよ。
追記だけど、 incentive structure がおかしいと思うんだ。Anthropic が主導してるけどトラフィック少ないし、OpenAI と Google がいつまで任せるか。ユーザーは ChatGPT Plugins で失敗してるし、あれエンジニアリングじゃなくてユーザー体験の問題だったのに、OpenAI がまた他の会社に主導させるのは理解できないな。コミュニティに期待するしかないかもね。
OpenAI は後ろで様子見して、なんか安定して使えるのが出てきて流行ったら、それ乗っ取るまで待つんじゃない？他社に失敗させて、そっからうまい汁吸うっていう、昔からのやり方だよ。
”REST API と MCP の違いが分からない”って？違いはないよ。”REST の方が楽”って？MCP の最大の利点は、メソッドディスカバリが組み込まれてること。LLM に使い方を教えなくても、コード書けば自動で理解してくれる。その点はめちゃパワフル。それ以外は普通だけどね。
つまりさあ、MCPはRESTful（HATEOAS持ってる的な意味で）だけど、”REST”は違うんだよ。
みんながこの見方に集まってるの見てめっちゃ嬉しいわ。正直、なんでこんな騒がれてんのか分かんなくてちょっとおかしいのかと思ってたんだよね。まあ、LLMsをツールとかと繋ぐ標準的な方法が必要なのは分かるけどさ、今のMCPは全然解決策になってないよ。
ブログ記事出したらさ、俺も先日似たようなことやったんだよね。
https：//github.com/modelcontextprotocol/modelcontextprotocol…
君のissue読んでると、あまり期待できないな。
これ、失敗するにはあまりにも重要すぎる気がするんだ。
まだ初期段階だけど、MCPは可能性があるから貢献したいね。久しぶりに草の根的な動きもあるし。でも市場の原理で良いものが勝つから、MCPが良いものなら自然と改善されていくだろうね。😊
MCPは最初からステートレスなHTTPであるべきだったんだよ。俺が見てきたほとんどのサーバーが、リクエスト／セッションレベルでステートフルである正当な理由なんてないんだ。サーバーが状態をグローバルに持つか、何らかのセッションidentifierでうまくいくかのどっちかだろ。
MCPのlogisticsが分かんないんだけどさ。誰かステートレスじゃない理由を説明してくれない？なんでconnectionを維持する必要があるの？
LLMからのsampling機能は双方向streamに合うかもだけど、誰も使ってない（過剰設計）。MCPの今の主要な利点はツール発見＆invokeの標準化だね。これは普通のHTTPで十分だったはずだし、実装もずっと簡単になったはずだよ。
Samplingは俺から見るとすごくpromisingなaspectだよ。実装が遅れてるのは、これまでのツール利用のmental modelから離れすぎてるからかもしれないね。もしサーバー側のDXを良くするなら、client側にburdenがかかっても全然構わないよ。実際、clientよりサーバーの方がずっと多くなるだろうから。
＞普通のHTTPベースのprotocolで十分だったはず
普通のHTTPでもさ、chunking機能を使えばrequestもresponseも簡単に”stream”できるんだよ。HTTP／1のfeatureね。なんでみんな”streaming”にWS（とかマジでSSE）が必要だと思ってんのか分からんわ。俺HTTP／1.1とchunkingでchat実装したけど、LLMsにもかなり合うuse caseだよ。
まあ、ポイントはcontextを提供することだよ、それはサーバーがstateを持ってる方が簡単にできるんだ。例えばMCP client（amazon q cliとか）を持ってて、SSH越しにcommand実行するMCPサーバーがあるとしよう。connection維持されてれば、MCPサーバーはSSH connectionをaliveにできるんだ。SSH serverをstateを持つ他の何か、例えばbrowserにreplaceしてみて（これで君のAI assistantも500個open tabs持てるぞ）。
