MCPは、箱にラップされたCLIみたいなもんだよ。CLIは、より簡潔なフォーマットで同じAPIを提供してる。最低限、MCPにも同じくらいのコンテキストオーバーヘッドがあるけど、大体はもっと多い。だって箱のサイズがあるからね。CLIはセキュアにできるし、AWS CLIはちゃんと動いてるよ。ダイモンに秘密を隠したり、リモートで実行したりする簡単なトリックも使えるし、どれもMCPよりは小さいよ。

完全に同意だね。なんで人々がこれを「どちらか一方」って見てるのか理解できない。あと、有料のMCPプロバイダーの中には、実際に価値を提供してるところもあるってことも言っておきたい。確かに、curlや自己ホストのクローラーを使ってウェブ検索はできるけど、それが本当に苦労する価値があるのか？

それに、LLMが気分次第でスキルを無視したり、妨害したりすることができるけど、MCPサーバーレベルのポリシーはそのまま残るよ。

その通りで、もう一つ重要な層を付け加えたいんだけど、スレッドではほとんど触れられてないね：エージェントがローカルで動作するのではなく、クラウドにホストされているときにこの組み合わせが最も重要だよ。スキル + MCPはクラウドホストされたエージェントのアーキテクチャなんだ。スキルはエージェントにコンテキストとワークフローを与え、MCPツールはエージェントが資格情報やランタイム依存関係を管理せずに外部サービスにアクセスできるようにする。

こんにちは、著者です！あなたのコメントに完全に同意するし、まさにそれが私の投稿のポイントでもあるよ：異なるタスクに対して異なるツールがうまく機能する。もし何か言うなら、投稿はスキルとCLIをMCPのゼロサムの置き換えとして扱うことに反対する内容だし、MCPが死んでいる/時代遅れだと言っているわけじゃない。特に、スキルとCLIではポータビリティが実現できない（まだね）。私は、リモートMCPを通じて、電話、ウェブ、iPad、ChatGPT、Perplexity、Claude、Mistralなどで同じMCPサーバーを使えるけど、スキルではそれができない。

まあ、まだCLIにアクセスできない環境がたくさんあるよね。そういう状況では、APIにフックするためにCLIツールを呼ぶスキルは役に立たない。

CLIとMCPで秘密を安全に保存して使うことにいつも悩んでる。MCPを使えば、エージェントを実行する前にサーバーを立ち上げられるから、エージェントの環境にはキーが存在しないんだ。そうすれば、エージェントが間違ったnpmパッケージをインストールして、見つけた秘密を全部ダンプするようなことになっても、周りに置いておく可能性が低くなる。CLIでそれを保証する良い方法はまだ見つけてないよ。

俺はよく、スキルに直接curlコマンドを入れちゃうんだ。エージェントがそれを使って、カスタムAPIの統合が完璧に動くよ。エージェントはこういうことをするのに十分な能力があるし、LLMはほぼ何でも達成するために柔軟なツールセットを使うってことだね。

いいね、いいね。ただ、認証はどうするの？認証と認可。エージェントは常に自分自身であるべき？そうじゃないなら、すべてのAPIがキーをサポートしてるの？そうだとしたら、コンテキストが汚染されたエージェントがそのキーを漏らす心配はないの？MCP（サーバー）が提供するのは、エージェントのアクセスを制御するためのミドルウェア層なんだ。これが必要かどうかはユースケース次第だね。

この話はもう散々議論されてきたよ。MCPはエージェントと外界の分離を可能にする。基本的には、エージェントにトークンを渡さないとか、HTTPヘッダーを変更しないとか、パラメータを強制することだね。まあ、これらのことが常に必要なわけじゃないし、MCPの発明者がこのアイデアを考えていたかどうかは分からないけど、今こうなってる。

あなたが欲しいものと、実際に機能するものは全然違う場合があるよ。

会社内でMCPを作ったんだけど、Google Workspaceの認証を使って、Claudeを通じて特定のタスクをどうやって達成したいかのガイダンス（ツールに偽装して）を混ぜ込んでる。内部データをクエリしたり、小さなアプリを安全に内部展開するためのAPI的な機能も持ってる。今使ってるSSEのMCPエンドポイントからは離れたいな。Claudeのデスクトップアプリは切断に対してすごく気難しいから。代わりにスキルと一緒にCLIを配布することも考えたけど、MCPは新しいツールや指示を簡単に更新できるし、非技術系の人にもClaudeへの追加方法を説明しやすいんだ。会社の全員が最新のスキルやCLIを持ってるか確認するのは想像できないよ。

多くの人がひどく不安定なJIRAのMCPにやられた経験があると思う。acliを使ったスキルは実際に動くし、MCPの他の部分をその視点で見ることができる。初期のMCP実装はひどいものが多かったし、今もそうだよ。だから、評判を取り戻すのは大変だね。

これらのシステムをレガシーシステムとして考えるようになったよ。持ってるし、重要だし、データもたくさん入ってる。でも、もう最適じゃない。アクセスの仕方やデータの所在は基本的に最適化の問題なんだ。AIが最適なものを変えるし、データが人を遠ざけるように設計されたAPIのある囲いの中にあるのは、今や最適とは言えない。こういう配管の問題を解決するのは、エージェントツールを使って生産的なことをする上で大きな障害になってる。でも、これに対処する良い方法は、システム思考を適用して、これらのシステムが本当に必要かどうかを考えることだと思う。多くのものをシンプルでコーダーに優しい解決策に置き換え始めたよ。これらに対してコードを書くつもりはないけど、AIツールが私の代わりにそれをうまくやってくれるからね。データにアクセスするなら、そのデータがローカルに保存されていて、簡単にアクセスできる形になってる方がいい。SAASのためのMCPはいいけど、ローカルで動くSQLデータベースの方がもっといいし、アクセスも早い。データが保存されている近くで処理するのが最適だと思う。MCPについては、あまり重要じゃないと思う。ほとんどのエージェントコーディングツールはプロトコルや言語をスムーズに切り替えられるし。結局、MCPはただの別のRPCプロトコルに過ぎない。特に良いものでも最適なものでもないし。すでにAPIやCLIがあれば、MCPを追加するのはちょっと冗長だね。認証は確かに重要な課題だけど、まだ大部分が解決されてない。MCPがそれに対して新しい要素をあまり追加するとは思えない。

それか、何かをすぐに立ち上げることだね。Codex -> LiteLLM -> VLLM |____> MCP セットアップには数分かかるよ。

解決策としては、エージェントがCLIツールを使ってMCPサービスにアクセスすることだね。笑 それなら、なんでMCPが必要なの？普通のHTTPリクエストでよくない？

少なくともローカルのMCPサーバーで作業しているときは、mcpツールをメモリ内のキャッシュ/ストアにラップすることでこの問題を解決したよ。各ツールの出力はユニークなIDの下に保存され、そのIDがツールの出力と一緒に返される。エージェントはそのIDを渡すことで他のツールを呼び出せるから、すべての入力を生成する必要がない。属性アクセスを追加すると、かなり強力になる（例えば、tool_return_xyz.some.dataの下のコンテンツをパラメータbとしてツールAに渡す）。これでトークンコストを節約できて、かなり速くなる。確かに、ツール間で値を渡すだけにしか機能しないけど、ストレージ層にデータをパイプする追加のツールがあれば解決できると思う。

スレッドを始めるだけでMCPは深刻なコンテキストの膨張があるよ。こんにちは、著者です。「MCPは深刻なコンテキストの膨張がある」という問題は、ツール発見で既に解決されているよ。現代のハーネスは、すべてのツールとその説明をロード時にコンテキストに読み込むのではなく、必要なときにツールを遅延発見するためにツール検索を使うんだ。LLMにどのツールをロードするかを正確に指示することで、さらに制限できるし、残りは未ロードのまま/見えない状態になるよ。> でも、もっと悪い問題は、MCPの出力がどこか別の場所にパイプされるのではなく、エージェントのコンテキストに直接入ることだね。これは、エージェントやハーネスが賢くなるにつれて半分解決されている。例えば、Claude Codeはサブエージェントで発見を行うんだ。だから、コードベースや環境を探索するために、より安価なモデルのサブエージェントを生成して、親プロセスに要約を提供するんだ。そうすれば、親は生の出力ログに直面することはない。

それには賛成だよ（たぶん）。自分の組織をデジタル化するのは、同僚のエージェントが彼らの代わりに行動してくれると仮定できると、ずっと楽になる。ほとんどの人間を協力させるのは難しいけど、エージェントには信頼できることが多いからね。MCPはちょっと配線を隠してくれるから、そこが好きなんだ。

著者は、セキュリティと設定がスキルにとって面倒だという立場から来ているけど、未来はMCP、エージェント、スキルのミックスになると思う。もしかしたら、スキルの下にもっと細かく定義された単位、つまりコマンドができるかも。これらのコマンドはしっかり定義されて標準化されて、再利用性を確保するためにハッシュ値が使われるかもしれない（Dockerのレイヤーみたいに）。そうすると、例えばこんなスキルができるかもね：- github-review-slim:latest - github-review-security:8.0.2 MCPは、難しいモノリシックサービスや、メトリクスに記録されていない変なビジネスプロセスに対してはまだ重要だと思う。

MCPの話は色々なことが混ざりすぎてて、みんなの前提が必ずしも正しいわけじゃない気がする。根本的な問題は、一回限りのアクセスとセッションを通じた持続的なアクセスの違いだね。- ローカルアプリと一回限りのセッションでやり取りする必要があるなら、CLIを使えばいい。- オンラインサービスと一回限りのセッションでやり取りするなら、そのAPIを使えばいい。- ローカルアプリと持続的にやり取りする必要があって、そのアプリがMCPサーバーを提供しているなら、それを使う。- オンラインサービスと持続的にやり取りする必要があって、そのアプリがMCPサーバーを提供しているなら、それを使う。MCPサーバーがうまく実装されているかどうかはまた別の問題。適切に設定されたMCPは、エージェントに過剰なコンテキストを持たせずに使い方を説明するんだ。持続的なアクセスのために適切なMCPを使わずに、自分でスキルファイルでやり取りを説明しようとするのは全然意味がない。MCPの所有者は、エージェントが効果的に使えるようにプロンプトを最適化すべきだよ。MCPは、外部ツールをエージェントセッションに統合するための最も良い方法だと思うけど、その意見に反対する理由がわからない。

好きなことに焦点を当てないで：それは重要じゃない。LLMが最も良い方法で仕事をするために必要なツールに焦点を当てて。LLMは、接続されたMCPがあってもデフォルトでCLIを使う傾向があることに気づいた。おそらく、a) トレーニングデータにCLIが過剰に含まれているから b) それらが設計上、より組み合わせやすく、検査しやすいから、ツール選択においてより良い選択肢なんだろう。

MCPは摩擦を生む、平均的なMCPサーバーを使って自分で作業することを想像してみて。なんで人々はMCPとスキルが補完的な概念だって理解しないんだろう？ MCP対スキルで議論する人たちは、どちらも深く理解してないってことだよね。

コンテキストの使い方はクライアントの問題だよ。プログレッシブディスclosureは、仕様変更なしで実装できる（例えば、Claude/codeにはこれが組み込まれてる）。とはいえ、クライアントを作るための例は、もっとたくさん展開できるはずだよ。

同意する、そもそもこの議論がよくわからない。全然別のことだし、実際にはうまく組み合わせて機能するよね。

この地球上の大多数のユーザーはそんな風にAIエージェントを使っていない ソースは？

あんまり君の考えが理解できてるか自信ないけど、そうなるとAPIが欲しいってことじゃないの？「ローカルアプリのためのMCP」って、アプリの内部動作を公開するAPIに過ぎないし、「MixpanelのためのMCP」もAuthの裏にあるMixpanel APIを公開するだけだよ。どのユーザーにとっても特別なものじゃない。MCPが「人気になった」だけなんだよね。同じタイプのユーザーのために、MCPサーバーを使わずに、ツールと純粋なAPIだけで、もっと良くてスムーズなソリューションを作ったこともあるし。ツールのスタンダードDXを定義すれば、君のLLMがこれらのツールを作れるし、どこかにサーバーを立てる必要もない。著者もここを勘違いしてるみたいで、CLIは必要ないんだよ。CLIは、DXが良くて、既存のbashツールと簡単に組み合わせられるから使われてるだけ。スキルを使ってAPIを使うなら、.envファイルも必要ないよ。スキルにはスクリプトやツールの言及が含まれることもあって、それをコントロールするのは君なんだから。全体的に、「MCP対スキル」の議論は、LLMやその動作、ハーネスやAPIの一般的な仕組みについての根本的な誤解に基づいてることが多いし、関係ないコーディング経験のない人たちがYouTubeやTwitterで「コンテンツクリエイター」として騒いでるのが原因だと思う。MPCに対するいくつかの反論は、ユーザーが誰であれ： - MCPはAPIやIPC（まあ、IPCの裏にあるAPI）の周りにあるノイズの多いハッキーなラッパーに過ぎない。 - MCPはLLMにとって長期的には役に立たないくらいノイズが多くて、サーバーが必要。 - MCPは必要なくて、機械が必要なコンテキストや意思決定を最小限に使える簡単にアクセスできるAPIが必要。 - スキルはMCPよりも優れていて、基本的にAPIのドキュメントやコンテキストをLLMに優しい形でエンコードしてる。サーバーを立てる必要もなく、システムプロンプトにテキストを押し込むだけでいい。

より農業的ってことは、クソみたいなことだよね？ ergonomicって言いたかったんだろうけど、面白いタイプミスだね。