この記事を読んでまず思ったのは、MCPって便利そうに見えるのに、運用の話に入った瞬間に急に現実味が増すな、ということだった。
「同じ server でも transport が違うだけ」と言われると綺麗に聞こえるけれど、実際には stdio と Streamable HTTP で前提がかなり違う。ここを同列に扱うと、あとでしんどくなる、という筆者の感覚はかなり実務っぽい。
特に腑に落ちたのは、stdio が“子プロセス”であることの強さだ。ローカルのファイル、git repo、個人の DB を触るなら、わざわざ hosted にする理由は薄い。秘密情報を外に出さない、環境ごとに分離しやすい、起動も停止も単純。こういう素朴な強みは、クラウド前提の設計に慣れていると見落としやすい。MCP を「まず動かす」だけなら stdio から入るべき、という主張はかなり自然だと思う。
一方で、HTTP に乗せた途端に話が“サービス運用”になる、という指摘も重い。共有アクセス、監査ログ、レート制限、OAuth、TLS、稼働率。ここまで来ると、もはや「ツールを呼ぶ」より「社内向け API を持つ」のに近い。便利になる分、責任も増える。しかも、MCP の文脈だとこの切り替えをつい軽く考えがちなので、記事がそこをはっきり分けているのはありがたい。
あと面白かったのは、同じ server を両方の transport で mount できる、という話だ。これができるなら、ローカル用と hosted 用で別物を作る必要はない。設計の芯を tool handler に置いて、transport は外側の薄い殻として扱う。これはかなり気持ちがいい。逆に言うと、ここを最初から分けておかないと、後で「ローカル版だけ妙に特殊」「HTTP 版だけ認証が別実装」といった泥沼になりそうだ。
読後感としては、MCP の transport 選びは技術選定というより、どこまでを個人の作業環境に閉じ、どこからを共有インフラにするかの判断なんだと思った。単に「どっちが新しいか」ではなく、誰が使うか、どこで動くか、失敗したとき誰が困るか。その境界線を先に引いておかないと、あとで設計が崩れる。この記事はその線引きをかなり実感のある言葉で示していて、そこが一番印象に残った。
参考: MCP stdio vs Remote Transports: Run It Locally or Host It?
