まさにその通り。ClaudeやOpenAIにアプリを統合するのにとても効果的な方法だよね。以前は、Claudeコードのコンテキストをかなり消費してたから、MCPに反対だったこともあったけど、今はほとんど解決されたよ。私の視点からすると、エージェントが使うためのAPIをラップする素晴らしい方法だと思う。将来的には、すべての主要な商業サイトやサービスサイト（航空会社のサイトとか）が、エージェントがフライトの状態を確認したり、再予約したり、チェックインしたりできるMCPを持つ未来が見えるね。

公平に言うと、最近いくつかの展示会に行った後、これらの「寄生的」なLLMスタートアップはビジネスユースケースの観点からあまり説得力がないと感じた。（彼らは本当に寄生的ではなくて、むしろサメにくっついているレモラみたいなもんで、サメはOpenAIやAnthropicだね）。シカゴのIMTSでは、AIや純粋なAIスタートアップに対する訪問者の懐疑心が最高に達してた。何度も「そのAIブースに行ったけど、彼らは私のビジネスにどんな価値を加えるか説明できなかった」と聞いた。だからその意味では、MCPが「勝っている」一方で、AIの「バブル」の重要な部分とも見ている。特に、VCマネーに支えられた問題を探しているソリューションとして。

その通りだね。うちの会社でも、内部ツールとのやり取りを簡単にするMCPを作ったんだ。これで時間とトークンを節約できてる。確かに、エージェントに理想的じゃないAPIをいじらせることもできるけど、99%の時間、必要なものにすぐアクセスできるようにするのが理にかなってるよ。

エージェントがインターネットにアクセスできるとしても、毎回自分でAPIクライアントを再発見して再実装するのにトークンを無駄にするのは意味がないよね。

これらのことは、Open API仕様のプレーンなREST APIといくつかの標準的な認証オプションを使えば、十分に可能だよ。AIクライアントが「APIリクエストツール」を実装すれば（今のAIクライアントがMCPを実装してるのと同じように）、MCPの本当の価値は、企業が「AIをやってる！」と言えるようにしたことだと思う。単に「私たちのAPIを使って」って言うのは、あまりワクワクしないからね。違う名前をつけることで、非技術者がAPIでユーザーデータを開放したくない企業の政治を乗り越える助けにもなったんじゃないかな。

全く同感だよ。MCPはただのツール利用で、ターミナルエージェントにはWebSearchやBash、Grepなどの組み込みツールがあって、これらは別の名前のMCPに過ぎない。モデルによって呼び出されるCLIは、ただのBashツールの使用呼び出しだよ。Bashツールは、最もオープンで広範なMCPを公開できるもので、得られるのはコンテキストの膨張が少ないこと（専門的なツールの説明がないから、ただのBash）で、失うのはエージェントのコントロールだね。厳密な権限設定をBashツールに設定するまで。私はサンドボックス化されたClaude Codeのインスタンスをいくつか動かしていて、互いにファイルを共有してる。ファイルはAWSに保存されてるけど、彼らはAWSに全くアクセスできないし、アクセスキーも見えない。実際、彼らはファイルがAWSにあることすら知らないよ。代わりに、内部の仮想ファイルシステムからリストアップやアップロード、ダウンロードするためのMCPツールを持っていて、特別なURIハンドラー（例：agentfiles://somefile.json）を使ってる。Claude Codeのインスタンスの外部オーケストレーターがMCPリクエストを受け取り、実際のファイル操作をClaudeの代理で行ってる。LLMはこの奇妙で恣意的なファイルシステムにうまく適応してるみたいで、これらのエージェントを完全に区画化できてる。ツールリクエストログや外部オーケストレーターのログもあって、エージェントの完全な監査ができる。MCPはこういうことに本当に自然にフィットするね。

その通りだね。ここには「MCPはクソ。お前がやればMCPなんて必要ない」っていう返信がたくさんあるけど、まあそうだね。

フルブローンのターミナルエージェントを運用しているなら、MCPを使う理由はほとんどない。 それには反対だね。「https://mcp.linear.app/mcp」を追加して、すべてが（発見、使用、APIの更新など）ローカルで何もインストールしたり設定したりせずに行われるのは大きなことだよ。

要するに、MPCサーバーはサンドボックスみたいなもんだね。

MCPは特定の環境では確かに役立つよね。特定の制約のある問題には向いてるけど、Node.jsとfetchを使ってLLM APIにアクセスするだけで解決できるほど制約が強いわけじゃないし、AIエージェントが自由にウェブサービスを呼び出せるほどオープンでもない。curlにアクセスを与えると、そうなっちゃうんだよね。OPの意見には賛成だけど、MCPは使い道が多すぎて過剰に宣伝されてると思う。複雑なエージェントとシステムの統合問題は、AIエージェントとcurl、SKILL.mdだけで解決する方がいいことが多い。もっと柔軟だしね。これは「ファットクライアント/スリムサーバー vs スリムクライアント/ファットサーバー」の議論の別のバリエーションだよ。ある人は、LLMが裏で秘密に作業するような、堅牢でスリムな（例えばウェブベースの）フロントエンドを求めてる。一方で、他の人はLLMがユーザーの環境とやり取りできるような、ファットで多用途なフロントエンドを求めてる。俺はずっとファットクライアント派だし、今回も例外じゃない。制約のあるアプローチが画期的なイノベーションを生むとは思えない。企業もSKILL.mdとcurlをエージェントツール呼び出しのメインメカニズムとして扱ってほしいな、MCPじゃなくて。MCPはニッチだよ。