または少なくとも何が起こっているのかを説明する他のページへのリンクがある その著者の以前の投稿へのリンクがあって（最初の10語の中にさえ！）、探しているコンテキストが含まれてるよ。

MCPはモデルコンテキストプロトコルのことだよ、生きてる世界へようこそ。洞窟の電気は消しておいてね。:) 今はMCPが何を指すのかはかなり知られていると思うけど、他の何かを指しているわけじゃないよね…？

略語が分からないなら、それはあなたがターゲットオーディエンスじゃないってことかも。このブログ投稿は、複数のMCPサーバーを使っている人たちのために書かれていて、LLMの使い方を変えることを主張してるんだ。用語の説明が必要で、略語をグーグルで調べる気もないなら、そもそも言ってることに興味がないってことだよね。株式市場のニュースに出てくる略語が何を意味するのか全く分からないし、株の人たちもCLIとAPI、LLMの違いなんて分からないけど、それが記事が悪いってわけじゃないよ。

MCPのことを言ってるの？そうなら、最初の段落の最初の文でちゃんとフルスペルが書かれてるし、詳しい投稿へのリンクもあるよ。それで、君が言った3つの基準のうち2つは満たしてるね。

「MCP」が何の略か知らないなら、この文章はあなたには向いてないよ。読んでみて、ターゲットオーディエンスじゃないと気づいたら、次に進んでいいんだ。あるいは、自分の時間を使って調べてもいい。HTTPやAPIが説明されてないと文句を言うようなものだよ。

これをやりたい人のために言っておくと、初頭の略語を紹介する正しい方法は、最初にフルタームを使って、その後に略語をカッコ内に入れることだよ。その後は略語だけを使えばいい。常にオーディエンスを考慮するべきだけど、ほとんどの非カジュアルな文章では、いろんな理由からこれが良いデフォルトだよ。

「MCP」は新しい「webscale」だね。 LLMが産業システムの間接的に所有されているオントロジーをオーケストレーションすることについて、哲学的な論文を書くのに使えるよ。SCADAシステムも含めてね。 https://arxiv.org/html/2506.11180v1 SCADAシステムは、以前STUXNETにハッキングされる必要があったから有名になったんだ。未来では、ただ雰囲気でハッキングできるようになるかも。

定義を探してるなら、初心者向けの記事を読むべきだよ。上級者向けじゃなくて。

そうだね、現代の開発プラクティスはRCEを機能として導入して、それを基に資金調達をすることだよ。

LLMが既存のAPIエンドポイントに接続できるとき MCPの主な違いは、エンドポイントの発見が含まれていることだよ。LLMにMCPツールの一般的な場所を教えると、そのツールが提供する機能をすぐに把握できるんだ。そしてツールが更新されると、LLMはすぐにその更新された機能を再学習する。残りの部分は不必要に複雑だと思うし（私の意見では）、普通のHTTP APIで十分だと思う。これまで出会ったMCPサーバーは実際にそういうことをしていて、さまざまなSSE機能を使っている人は見たことがない。MCP v.01（現行）は、正しい方向への一歩（機能の発見）であり、簡単な部分（APIの構造自体）でのぎこちない誤りでもある。

なんでMCPサーバーが必要なのか分からない。LLMが既存のAPIエンドポイントに「ただ接続」できるじゃん。 LLMはAPIコールのための入力パラメータを生成できるけど、呼び出しコードを実装する必要があるんだよね。LLMに提供したいAPIごとに呼び出しコードを実装するのは、最低でもめんどくさいし、エラーが出やすい。MCPは一度書けば済む、一貫した呼び出し実装を提供してくれるんだ。

あなたが作ってるもの、すごく理解できるよ。MCPがよく使う通信の間接的な部分がちょっと気になるし、OpenAPI仕様のようなところでの労力の重複も気になるね。このリポジトリを注目しておくつもりだし、いつか試してみたいな（ただ、TypeScript版もあればいいのに）。

MCPサーバーを書き始めた最初の数日で、APIをバインドするもの（DataBento、Buttplug.io）を作ったんだ。それが目的だと思ってた。私の即座の気づきは、1) 自動バインダー（例えばOpenAPI）か、UTCPのようなより良いバインディングシステムが必要だということ、2) システムやAPIのために安全なサンドボックスが必要だ（UAT環境のような）。MCPサーバーやツールを作り続けて、（1）が誤解だったことに気づいた。ほとんどのAPIはコンピュータのために作られていなくて、人間が他の人間と自分のコードをつなげるために作られているんだ。説明するのは難しいけど、エルゴノミクス的なことなんだ。データベースへのAPIはページングやフィルタリングのようなものがあるかもしれない。デザインはURLに収める必要があって、物事を簡素化したり隠したりしたい。LLMはそんなの気にしない。私の洞察はこの記事と似てる。LLMはデータセットへの可愛いAPIなんて必要ない。彼らはコードを書くことができるから、APIを与える必要はなくて、SQLエンドポイント（私の焦点）、Pythonの仮想環境、またはbashプロンプトを与えればいい。そうすれば、UTCPマニュアルのように、ユーザーとLLMがツールの説明やコードヘルパー（SQL、ビュー、ストアドプロシージャ）を開発して、必要なことをより上手くできるようになる。メインのツール説明があって、ユーザー特有の補足もあるかもしれない。だから、私はDuckDBを使ってデータをロードしてロックダウンし、DBテーブルをCSVで返す単一のSQLエンドポイントを提供する。そして、LLMと一緒にエージェントループでツールの説明やヘルパーを作っていく。だから、あなたたちがやっていることはクールだと思うけど、力はAPI接続そのものにはなくて、LLMがそれをどう使うかにあるんだ。でも、そのエージェントアシスト部分を製品に組み込むことができるし、誰かがそれを取り巻く何かを作ることもできるよ。

REST APIがあるのに、なんでGraphQLが必要なの？両方とも目的は違うけど、同じことを実現できるんだよね。

君の玩具を批判するつもりはないけど、開発者を嫌う言語を使わせる予測モデルを作るのは本当に運任せな結果になると思うよ。

それはガードレールじゃなくて、ガイダンスだよ。子供やインターンに「ここにあるものは全部使って、好きにやって」って教えるわけじゃない。フレームワークやプログラミング言語、あるいは一般的な方向性を与えるんだ。

人気のコーディングエージェントを使っているなら、彼らはbashでコマンドを実行できるから、ほぼ無限のツールにアクセスできるんだ。私自身が仕事をするために使っているツールにアクセスできるってこと。以前は自分でやっていたLinuxラップトップのトラブルシューティングにも使ってるけど、今は面倒でやりたくない。これが私が出会った最も共感できるAIの瞬間につながったんだ。「これはイライラする」って、Bluetoothヘッドセットを6回連続で動かそうとした後にClaude Codeが思ったことだよ。

MCPに伴うセキュリティ問題を考えると、MCPを「ガードレール/サンドボックス」と呼ぶのは悪いアイデアだと思う。それに、ターミナルで任意のコマンドを実行できるMCPサーバーもあるし、apt installやbrew installも含まれてるよ。 [1] https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

自分の経験から言うと、MCPはただのすごく構造化されたプロンプトに過ぎないと思う。 エージェントやモデルが使うツールを指示プロンプトで指定できるし、特定のプロジェクトに特に役立つ。Cursorで特定のファイルが変更されたときにトリガーされるワークフローを定義していて、だいたいモデルはしばらくの間、途切れずに動いてくれる。

ちゃんとコンテキストを与えるのが一番いいと思う。 LLMが調べ方を知らない情報（内部システムのステータスやログへのリンクなど）を与えたら、その調査を行うためのツールを渡してあげるといいよ。

自分のコーディングエージェントは、以下の機能にアクセスできるよ： ask> どんなツールがあるの？ 以下のツールにアクセスできるよ： 1 code_search: ripgrepを使ってコードベース内のパターンを検索。 2 extract_code: 行範囲に基づいてファイルからコードの一部を抽出。 3 file_operations: ls、tree、find、diff、date、mkdir、create_fileなどのさまざまなファイル操作を実行。 4 find_all_references: ASTインデックスからシンボル（関数、クラスなど）へのすべての参照を見つける。 5 get_definition: ASTインデックスからシンボル（関数、クラスなど）の定義を取得。 6 get_library_docs: 一意のIDを使ってライブラリのドキュメントを取得。 7 rename_symbol: VS Codeを使ってシンボルの名前を変更。 8 resolve_library_id: ライブラリ名を一意のライブラリIDに解決。 MCPや他のエージェントは何のために必要なの？これでほとんどの問題は解決してるんだけど。

こんなに超人的な知能があるのに、「CALL MOM」デモがまだ解決できてないのは変だよね。

codexやclaudeのコードがプロジェクト内の何十ものファイルを手動で読み込むのは変だよね。「使用箇所を探す」ってエディターに簡単に頼める方法がないからなんだろうけど。CLIツールを効率的に使えばトークンの消費はそれほどひどくならないかもしれないけど、モデルはコメントやREADME、メソッドのオーバーロードについて考えるのに余計な労力を使わなきゃいけない。

構造化された出力はパフォーマンスを向上させるから、同意するよ。特に、文脈自由文法のための広範な構造化出力サポートが見たいな。たまにvLLMみたいなのがあるけど、ほとんどのLLMサービスはJSON出力しかサポートしてなくて、これは何もないよりはマシだけど、このケースには全く対応してない。意味解析を伴う出力、スコープに基づいた出力があれば最高だけど、技術的には可能でも、すぐには実現しそうにないね。でも、製品の差別化のチャンスかも。

現在のツールの使い方は非効率的に見えるのには同意するよ。でも、構文木ではなくコードで操作する理由はしっかりあるんだ。* トレーニングセットにははるかに多くのコードがある。* コードはほとんどいつもより簡潔な表現だからね。過去にはASTのエッジ情報を取得するためにグラフニューラルネットワークやトランスフォーマーをトレーニングする研究もあったけど、そのアプローチが先行するLLMを超える可能性があるには、何らかのブレイクスルー（と大量の資金）が必要だと思う。実験的にエージェントがast-grepを使うのは結構うまくいってるみたい。だから、すべてをコードとして表現しつつ、構文を意識した検索置換ツールを使ってる感じだね。

文字列は依存関係のないユニバーサルインターフェースだよ。どんな言語でも、どんな数のファイルでも何でもできる。他の抽象化は達成できることを大幅に制限しちゃう。あと、LLMはASTでトレーニングされてるんじゃなくて、文字列でトレーニングされてるんだ。プログラマーと同じようにね。

ASTは全体の一部に過ぎないよ。重要なのはセマンティクス（つまり、抽象機械が行うアクション）なんだ。コードが助けるのはパターンを特定することで、それがコード生成（defmacroやAPIサービスの生成）に役立つから、主なインターフェースになるんだよ。ASTは実装の詳細に過ぎない。

LSPサーバーと統合するエージェントがいくつかあるけど、オープンコードが思い浮かぶね。ただ、まだgrepやsedを多用する傾向があるけど。

まさにその通りだと思う。数ヶ月前にAIに頼んだタスクが思ったよりも上手くできて驚いたけど、特定のコーディングスタンダードに合わせて変数名を変更するためにコードをリファクタリングさせたら、すごく下手だったのが面白かった。良いジュニア開発者が数日かかるような作業をした後に、リファクタリングで大失敗して、高校1年生レベルの結果だったよ。

LSPが公開しているAPIを見れば、その理由がわかるよ。LSPをエディタの外で使うのはすごく難しいんだ。なぜなら、多くが「ファイルXのY行で、この2つのカラムの間でシンボルがどこで使われているか」だから。

あなたが探しているのはSerenaだよ: https://github.com/oraios/serena