I Dont use MCP Prove me Wrong
誤解しないでください。本当に私が使うケースはいくつもあります。たとえば、CloudコードのChrome拡張は優れています。ローカルとVS CodeのIDE、MCPの拡張連携。あと、VS CodeのDiagnosticsや、それに類するもの。そういったものを実行するのには使います。私はマルチエージェントOSを構築していて、分かったことは、MCPをマルチエージェントのワークフローや、あなたの一般的なシステムに統合しようとしても、基本的にはうまく機能しないということです。そしてコンテキストコストが、結局「そのコストを払う価値がない」ってだけなんです。
やるべきことを特定すれば、コストの数分の1で作れてしまう。さらに、これらのツールやシステムの多くは、純粋なコードだけで構築できるので、完了までに必要なのが単一のコマンド一行程度（実質ゼロコスト）で済む場合があります。
私が見ている限り、MCPは実際の作業の多くをLLMに任せることに依存しています。もちろん、Puppeteerのようなものは時々とても良い動きをします。というのも、私の仕事の大部分はAI開発で、アプリ作成やWebデザイン、Excelのチャートなどのような、他のMCPにまで踏み込んだところまでは到達していないからです。もちろん、オーケストレーションに関しては、私の側では必要ないので別にそうです。
それが私が実際に作っているものです。もちろん、それについても調べています。MCPに関して、あなたの見解はどうですか？私は、クラウドやMCPのクロスプラットフォームに依存しない、アグノスティックなシステムを構築しています。というか、システムに組み込む形で。GPT、Claude、Gemini—ローカルのものも、技術的には問題なくシステムに組み込めるはずです。
今のところ、Claude Codeが私の第一候補です。理由は、そのフック（hooks）システムがかなり良いからです。GBTやGeminiもこの方向に取り組んでいて、現時点でもフック用の基本モデルは用意されていると思います。どこまで高度になっているかは100%確信がありませんが。彼らがその段階に到達したら、その時点でプロジェクトに完全に実装します。可能なら、それをつなぐラッパー（ラッパー）も検討します。また、必要なら、got（？）やGemini、Codexのソースコードも扱える状態にしておくつもりです。私のシステムでは、他のエージェント/LLMがCloudコードとまったく同じように動くのが理想ですが、結局のところ一般論として「YesかNoか」。私は本当に見逃しているのでしょうか。私は過去にたくさん使ってきましたが、いつも結局のところ、どれも私の直近のニーズを解決してくれませんでした。中には役立つものもありましたが、それでも結局、完成したパッケージを得るにはいろいろ要る、という感覚になってしまったんです。
それなら、トークンをシステムプロンプトに使いたいです。システム内でAIの作業を導くために。私は、既存のシステムを置き換えたいわけではなく、裏で動くより賢いレイヤーを追加したいだけです。
[link] [comments]
