#jsonrpc

最初に思ったのは、こういう説明ページはありがたいけれど、同時にかなり勇気がいる作りだな、ということだった。MCP は「AIアプリとツールをつなぐ共通規格」くらいの説明で止まることが多い。そこを、メッセージの流れや transport、認証、tool の呼び出しまで、わりと泥臭いところに踏み込んで見せている。しかも「spec を読む」だけではなく、実際の wire 上で何が飛ぶかを追えるようにしているのがいい。抽象論だけだとすぐ雰囲気で終わるので、ここを見える化する価値は大きいと思う。 特に引っかかったのは、「Model は server に直接話さない」という整理のしかただった。言われてみれば当たり前なのに、実装を考えるとここはすぐ曖昧になる。ユーザー、host になる AI アプリ、server、そして model の役割が分かれていて、model はあくまで「何を使うか決める側」だという線引きがはっきりしている。AI が何でも自分で勝手に取りに行く世界ではなく、アプリが間に立って権限や文脈を握る。地味だけど、この分離があるからこそ、安全性や拡張性の話が成立するんだろうと思う。 それ

この記事を読んでまず思ったのは、「AI相手に試すのは、やっぱり遅いし曖昧すぎる」という、かなり当たり前だけど見落としがちな感覚でした。MCPサーバーを本当に壊したいときは、自然言語でモデルに話しかける前に、まずJSON-RPCをそのまま叩け、という話なのですが、これは地味に効きます。モデルが悪いのか、ツール定義が悪いのか、サーバー実装が悪いのかが混ざると、切り分けが一気に難しくなる。そこでAIをいったん脇に置く、という順番が筋が通っています。 特に刺さったのは、Inspectorを「便利な可視化ツール」として扱いながらも、テストの本体にはしない、とはっきり線を引いているところです。GUIでツール一覧を眺めたり、手で1回再現したりするのは楽です。でも、それを回帰テストの代わりにすると途端に弱くなる。クリック操作は再現性が低いし、CIにも載らない。ここをはっきり分けているのがよかったです。現場だと「とりあえずInspectorで見えるからOK」に流れがちなので、そこへの釘刺しに見えました。 もうひとつ面白かったのは、tool descriptions までコードと同じ目線でテストしろ、とい

いちばん引っかかったのは、MCPそのものより「ちゃんと運用すると、急に話が現実になる」という空気でした。プロトコルのきれいさを褒める記事かと思いきや、実際には「3日で壊れた」「2AMにSlackで知った」みたいな、かなり泥臭い失敗談から入ってくる。そこがよかったです。AIまわりの話って、デモの気持ちよさに寄りがちですが、この記事は最初から“壊れる前提”で読ませにきている。 特に腑に落ちたのは、MCPをUSB-Cにたとえる話が、単なる比喩ではなく「N×Mの組み合わせ地獄を減らす」という運用上の痛みと直結している点です。LLMとツールの接続が増えるほど、個別実装の継ぎはぎは本当にきつくなる。ここでJSON-RPCという共通の会話形式に寄せるのは、地味だけどかなり強い発想だと思います。派手な機能より、まず“壊れにくい共通語”を作る。AI時代のインフラっぽさがある。 一方で、読んでいて少し身構えたのは、この記事が「MCPはこう作ればいい」と言うだけでなく、「でもここを雑にすると普通に事故る」と何度も釘を刺してくるところです。特にOAuth 2.1やstateless scalingの話は、きれ