Model Context Protocol(MCP)は、Anthropicが開発したオープンソースのプロトコルであり、大規模言語モデルに外部コンテキストを提供する普遍的な接続規格である。従来は各アプリケーションが個別にツール連携を実装する必要があったが、MCPによって一度構築すればあらゆる場所で設定可能な統一されたインターフェースが実現された。オープンソース化以降、史上最速で成長したプロトコルとなり、GitHub、Asana、Slackなど多数の企業が公式MCPサーバーを提供している。リモートMCPサポートやレジストリの導入により、エンドユーザーの設定プロセスが大幅に簡素化され、開発者はMCP SDKまたはClaude APIのネイティブMCPコネクター機能を利用して容易に統合できる。MCPサーバーの設計においては、ツール名や説明文が実質的にプロンプトとして機能するため、適切な命名と詳細な説明が重要である。今後はMCPサーバーの品質がベンダー選定の基準となり、AI統合の標準インフラとして成熟していくことが期待される。
MCPとClaude APIによる構築
私はあなたのSlackのステータス更新を読んでいるということですか?それらは全てClaudeが生成したものなんですか?
ええ、私はもう実際には何も書いていません。全部Claudeです。
ずっとあなたがClaudeを読んでいただけだったんですね。了解しました。
マークです。
こんにちは、私はAlexです。AnthropicでClaude Relationsを率いています。今日はMCPとClaude APIについてお話しします。同僚と一緒に来ています。
こんにちは、Michaelです。AnthropicのAPIチームのエンジニアです。
私はJohnで、AnthropicのModel Context Protocolチームで働いています。
今日の始めに、MCPとは何かという高レベルの概要を本当にお伝えしたいと思います。
MCPはModel Context Protocolの略で、モデルに外部コンテキストを提供する方法です。チャットボットがあって会話をしている場合、会話の履歴がコンテキストになります。そしてモデルは、あなたが入力した全てを見る能力しか持っていません。これは、この問題を解決するのを手伝ってくださいとか、これを書いてくださいといった、ある種のタスクには本当に便利です。
しかし時にはClaudeはその箱の外にあるものへのアクセスが必要になります。例えばインターネットと話せる必要があったり、旅行代理店に連絡してフライトを予約する必要があったりします。それがまさにMCPが登場する場面です。MCPはこれらの外部コンテキストをClaudeに提供するので、Claudeがあなたの代わりに外の世界であなたのためにアクションを取ることができるのです。
そうですね。過去にMCPは、アプリケーションとモデルの間の普遍的な接続装置のようなものだという良いアナロジーを聞いたことがあります。つまり、Claudeを他の全てのもの、アクセスが必要かもしれない他の全てのデータソースやツール、全てのものに結び付ける方法なんです。
ええ、確かに。
基本的にインターネット上にあるものですね。なぜ私たちはこれを構築したのでしょうか?意図は何だったのでしょうか?つまり、これらの接続があることは便利に思えますが、なぜ私たちが特別にそれを引き受けたのか、そしてなぜそれを普遍的な標準プロトコルにしたのでしょうか?
ツール使用においてどんどん先に進んでいき、Claudeの能力が向上するにつれて、私たちは様々な異なるコンテキストで同じ能力の多くを再実装していることに気づき始めていたと思います。
私のコーディングエディタにあったアシスタントには、ウェブ検索ツールを関連付ける必要がありましたが、claude.aiも同様でしたし、Claudeが外の世界とやり取りできるようにしたい他の全てのサービスも同様でした。そして私たちは、一度機能セットを実装してどこにでも持っていける、単一の統一されたプロトコルを持つのが良いだろうと考えました。
つまり一度構築してどこでも設定できるということですね。Claude Codeで得られる同じウェブ検索機能が、claude.aiで得られるウェブ検索機能と同じになるわけです。
なるほど、それは理にかなっています。基本的に普遍的な互換性を作り出すということですね。これらの同じ接続を必要とするかもしれない大量のアプリケーションがある場合に。
さて、MCPに対する私たちのアプローチ、特にオープンソース化については、当時他の企業が進んでいた他の多くの統合パスとはかなり異なっていたと思います。なぜ私たちはそれをオープンソース化しようと考えたのでしょうか?その背後にある原動力は何だったのでしょうか?
エンジニア、企業、個人の広範なネットワークが何かの周りにエコシステムを構築できるようにするために、オープンスタンダードには多くの価値があると思います。
私たちはClaude App Connectorを作って、Claudeに物事を結び付けることもできたかもしれませんが、そうすると複数のモデルを使用している場合に本当に悪いユーザー体験になってしまいます。もし私がAsanaのような会社で接続したい場合、Claudeコネクターを実装して、OpenAIコネクターを実装して、Grokコネクターを実装して、Geminiコネクターを実装しなければならないのでしょうか?それは悪夢のようになってしまいます。
そして私たちが気づいたことの一つは、モデルが外部コンテキストにアクセスできることは、誰にとっても良いことだということです。満潮時には全ての船が浮くようなタイプの状況です。そして私たちには、モデルのやり取りを標準化するための本当に価値のある内部プロトコルがありました。それで私たちはそれをオープンソース化し、「ねえ、私たちはこれが便利だと思ったんだけど、もしかしたら世界も便利だと思うかもしれない」という感じでした。
そしてそれは信じられないほど人気になり、信じられないほど速くなりました。多くの人々が同じ種類のニーズを持っていたことが判明し、飛びついて、ただハッキングし始めました。最小限のサポートでさえ、人々は本当に素晴らしい開発環境をハッキングし始めました。そしてそれは一種のブーストのようなものでした。歴史上最も速く成長したオープンソースプロトコルだったと思います。
すごい。
本当に一種の成層圏的な成長がそこにあり、それに対する大きなニーズがあります。ええ、それで私たちはそれをオープンソース化しました。そしてこれが離陸して以来、この小さな仕様をリリースした時の私たちの最も大胆な夢を本当に超えています。そしてこれがAnthropicがそのモデルにコンテキストを取得するための、Anthropicのプロジェクトのための巧妙な方法から、業界を定義する標準のようなエコシステムへと移行し始めているので、私たちは多くの作業を行ってきました。
私たちはそれを適切なオープンソース財団に移行し、他の全てのプロバイダーと協力し、MCPを耐久性があり長期的に存在するものにするために多くの作業を行ってきました。
実際にMCPの現状はどうなっているのでしょうか?オープンソースコミュニティの観点と、技術仕様自体の両方の観点から。最初に発表してから約1年、1年弱だと思います。
多くの人々が今年初めや2025年初頭頃のMCPの状態に基づいた直感を持っているように感じます。しかしプロトコルは非常に速く動いており、物事は変化しています。あなたたちの考えでは、MCPの現状はどうですか?
少なくとも私にとって大きなひらめきの瞬間だったと感じるのは、リモートMCPサポートをリリースした時です。
プロトコルの初期の特異性のいくつかは、効果的に全てを自分自身で実行しなければならないということでした。これはAsanaのようなMCPサーバーのプロバイダーが、非常に迅速にアクセスできる独自のサーバーをホストできるようにすることを妨げていました。そしてそれはセットアッププロセスを非常に、非常にぎこちないものにしました。そして私の意見では、リモートでホストされたMCPサーバーに対するファーストクラスのサポートを提供した時が、非常に大きなステップチェンジだったと思います。それはセットアッププロセスを劇的に削減し、エンドユーザーがかなり迅速に始められるようになりました。
そして今では、これらのサーバーのレジストリがあるので、人々は実際にこれらをレジストリにアップロードでき、そして私たちはそれらを承認したり、承認したりして…
ええ、完全に。オープンソースプロジェクトには、MCPサーバーの中央レジストリがあります。オープンソースの精神に沿って、Model Contact Protocol組織サイトでホストされているレジストリと、他の組織がレジストリを拡張し、その情報を取り込むことを可能にする標準の両方があります。
そして私たちはMCPの大規模な成長を見てきました。GitHub MCP、Asana MCP、多くの企業がこれらのエンドポイントを構築してデプロイしています。そしてそれは、過去にはもしGitHubとやり取りしたければ、GitHubコネクターをハックした無作為の開発者を探して、その人のNode.jsのインストールをあなたのコンピューター上で信頼しなければならなかったのが、より簡単になっています。
そして今では、公式のGitHubサイトにアクセスするだけでいいのです。mcp.github.comだと思いますが、それをClaude CodeやClaude.aiに入れれば、ClaudeをGitHubとやり取りする能力で拡張できます。だから本当にクールな方法で成熟しているんです。
それはかなりクールですね。そして私もClaude Codeで物事にGitHub MCPを使っていますが、そのオールインワンのエンドポイントをプラグインするだけでいいのは素晴らしいです。
現在レジストリ内またはレジストリ外に、あなたたちが見た面白くてユニークなMCPはありますか?
私が見ていて本当に、本当に興味深いと思うものの一つは、Context 7と呼ばれるものです。大規模言語モデルの最大の制限の一つは、通常数ヶ月遅れている知識カットオフがあることです。つまり、ソフトウェア開発者として最新かつ最高のパッケージで作業することが、LLMでは時々難しいということです。なぜならLLMは古い情報を提供するだけだからです。
そしてContext 7が行うことは、Next.jsのウェブサイトや私たち自身のAPIのウェブサイトのようなウェブサイトからドキュメントを取得し、それらを最新の状態に保つことです。そしてあなたがする必要があるのは、MCP接続を一度設定するだけで、Claudeはあなたが開発している対象の最新情報にアクセスできるようになります。
なるほど。ええ、それについて聞いたことがあると思います。つまり基本的に最新のドキュメント、全てを取り込んでいるわけですね。そして今、多くの人々が自分たちのドキュメントを完全に生のテキストにしてLLMからアクセスできるようにする移行期にあることを知っています。だからこれは同じ種類の情報から取得していると推測しています。
ええ、これはllms.txt形式のようなもので、テクノロジー業界全体で多くの採用を見てきました。それを見るのは非常にエキサイティングでした。
それはクールですね。Johnさん、あなたからは何かありますか?
私の側からは、ソフトウェア開発者としての仕事から、MCPサーバーとしてのPlaywrightが本当に好きだということがわかりました。これはClaudeがユーザーがクリックしているかのようにブラウザとやり取りすることを可能にします。
ウェブサイトで作業している場合、ClaudeはあなたのCSSを全て読み、HTMLを読むことができますが、実際にはあなたのウェブページを見ることはできません。しかしPlaywright MCPサーバーをインストールすれば、Claudeにあなたのウェブページを見てもらい、それをより美しくする方法やアライメントの問題を修正する方法についてアドバイスをもらうことができます。
つまり実際にスクリーンショットを撮るということですか?
ええ、実際にブラウザでロードして、Playwrightを使って閲覧しています。これはリモートブラウザ駆動を可能にするMicrosoftのプロジェクトです。
それをClaude Codeのようなものでループに入れるとどうなりますか?
ああ、自己改善ループが得られます。
Claude Codeにヘッダーのアライメント問題を修正するように言えば、HTMLにいくつかの変更を加え、CSSにいくつかの変更を加え、必要に応じてページをリロードし、それから再び見て、「ああ、全てが良く見える」と言ったり、「それは直らなかった」と言ったりできます。そしてそれは変更を見て、実際にウェブサイトのスクリーンショットを撮って、「ああ、このCSS変更のセットは実際に私が意図しなかったこの効果をもたらした」と言うコンテキストを持っています。
それをロールバックして別の方法を試してみます。
うーん、それは異なるタイプのアライメント問題ですね。
ええ、CSSのアライメント問題は、もしかしたらさらに難しい問題かもしれません。少し話題を変えて、もし私が開発者でClaude APIを使いたい場合、Claude APIやClaudeモデルでMCPをどのように使用できますか?
それは素晴らしい質問ですね。
これを行う標準的な正規の方法は、MCP SDKをインストールし、独自のループを設定し、Claude Codeで言及したように、接続する必要があるMCPサーバーへの接続を処理することです。しかし基本的にソフトウェア開発者としてのあなたの責任は、全ての接着作業をまとめることです。これは素晴らしいし、機能します。
しかし私たちが最近APIにネイティブ機能として直接リリースしたものは、MCPコネクター機能です。これはmcp.github.comのようなリモートMCPがどこにあるかを指定するだけで、必要な承認情報を提供すれば、ツールを実行し、結果をモデルにフィードバックする呼び出しループを私たちが処理できます。
だからあなたが本当にしなければならないのは、最新のプルリクエストをくださいと言う単一のAPI呼び出しを送信することだけで、それがあなたのためにそれを処理してくれます。
それは素晴らしいですね。ええ、多くの開発者から、大量のコードを削除できるようになったと聞いています。なぜならそれがあるので、自分たちでそのやり取りを全て処理する必要がなくなったからです。URLをエンドポイントに渡すだけで、基本的に準備完了です。
MCPを使用する開発者のための他のヒントはありますか?
私が話す時に開発者に与えようとする主なものは、MCPサーバーとツールは本質的にはプロンプトだということです。そして私たちは、AI駆動アプリケーションを書いている場合、モデルにプロンプトする時に使用する言語について注意深く正確であることが本当に重要だということを学んできました。
これはMCPサーバーを定義することの全てに及びます。ツール名を適切に定義し、説明を与えることです。おそらくあなたの説明には、使い方のいくつかの短い例が説明の中にあるかもしれません。適切なパラメータ名を与えることです。これら全ては、MCPサーバーとやり取りする時のモデルの動作に影響を与えるものです。
私が持っていた例は、画像生成サーバーを作っていた時で、Generate Imageというツールがあり、Descriptionというフィールドがあり、それだけでした。そしてClaudeに「ねえ、かわいい子犬の画像を生成して」と言うと、Claudeは続けてツールを呼び出し、「説明、かわいい子犬」と言います。
素晴らしい。それを変更して、「このツールはXXX拡散モデルのバージョンYを呼び出し、最良の結果を得るためにはこのスタイルでプロンプトする必要があります」と言えば、この種の記述的な言語を使用し、これら全てを行います。Claudeはこれらのシステムとやり取りする方法についての情報を持っており、それを伝えられる必要があるだけです。「ああ素晴らしい、今私は拡散モデルと話していることがわかった、言語を変えよう、このプロンプトで使おうとしていることを変えよう」となり、かわいい子犬を求める代わりに、はるかに良い結果を与えるはるかに詳細な拡散モデルプロンプトを提供します。説明やプロンプト名のいくつかの単語を変えるだけで、MCPサーバーからはるかに良い結果が得られます。プルリクエストを書いたり、Claudeで何らかの知識作業を行ったりするのと同じように、それらを調整することでより良い結果が得られるのと同じです。
私自身、これを常に忘れています。何らかのAIアプリの新機能に取り組んでいる時に、ツールや何らかの説明を孤立して扱っている時、それは全て同じプロンプトに引き戻されるんですよね?そして結局のところ、それは全て、各リクエストでモデルに供給される一つのテキスト文字列のようなものなんです。
そしてそう、それは良いアドバイスですね。ねえ、それもプロンプトの一部なんだということです。コードのどこかのJSONで書いている説明は、依然としてリクエストでClaudeに送られる同じプロンプトに引き込まれるのです。コンテキスト管理についても少しお話ししましょう。多くのツールや多くの結果を扱うことについてです。
つまり、これは現在LLMにとって大きな問題です。コンテキストを汚染するという点で。MCPで開発者がそれについてどう考えるべきか、何か考えはありますか?
ええ、私たちが多くの開発者が犯すのを見てきた大きなアンチパターンは、MCPサーバーやMCPサーバーを使ったAPIリクエストに大量のツールや大量のMCPサーバーを詰め込むことです。これは追加する一つ一つに対してトークンを生成するだけなので高価になるだけでなく、モデルを混乱させる傾向もあります。
例は、同じリクエストでLinearとAsanaのタスク管理MCPサーバーの両方を接続する場合、それらの両方にGet Project StatusというMCPツールがあるかもしれず、モデルはどのコンテキストでどちらを使用すべきかについての暗黙的な情報を持っていません。しかしそれを超えて、あなたは基本的に、潜在的に矛盾する情報を与えることでモデルを混乱させているだけです。
だからどのツールを追加するかについて非常に、非常に注意深く決定論的であり、それらの周りのエルゴノミクスも意味をなし、もしあなた自身がそれらを使うことになったらそれらのツールを使うことが自然に感じられることを確認してください。しかしそれを超えて、ええ、現在のユーザープロンプトのターンを助けるのに必ずしも必要ではないかもしれない情報を含めないようにしてください。
だから時々、会話の古い部分が、あなたが知っている、今日の天気はどうですかのような非常に導入的な情報を含んでいるかもしれません。会話のずっと後で、最新のニュースやモデルから必要な他の情報に移動している時には、それほど関連性がないかもしれません。
うーん、よく聞かれるのは、Claudeにいくつのツールを渡せますか?または一度にいくつのMCPサーバーを接続できますか?ということです。そしてそれは数の問題というよりも、ツールが互いにどれだけ異なっているか、どれだけよく定義され範囲が決められているかということのようです。それは正しいですか?それともMCPの絶対数のようなものもありますか?
絶対数にもなると思います。コンテキストウィンドウがXトークンの場合、各サーバーは多数の関数定義を取り込みます。それぞれがそれを食いつぶします。
だからただ始まるのです。LLMにより多くの情報を与えると、良い決定を下すことが難しくなります。そしてたくさんのサーバーに接続すればおそらく機能しますが、Claudeが見ているタスクに関連するサブセットを与えることができれば、おそらくより良く機能するでしょう。Michaelが言っていることから出てくるもう一つのポイントは、MCPサーバーを設計している場合、一般的にサーバーに1つか2つのツールを持つことができれば、15か20のツールを持つよりもモデルに大いに役立つということです。
そしてMCPインターフェース開発は、私たちがこれらをLLMに供給しているAPI開発とは少し異なることがあります。そしてツールに自然言語を受け取る説明を与えるか、パラメータを埋める一部として、モデルがいくつかの決定を下し、いくつかのテキストを生成する場合、おそらくGet Projects、Get Posts、Get UsersのようなものになるAPIの代わりに逃げることができるかもしれません。
おそらくGet Infoツールだけを持つかもしれません。なぜなら呼び出し元のLLMがあなたの説明を見て、必要な情報を何でも埋めることができるからです。そしてそうすることで、はるかに小さなツールセットを提供でき、他のMCPサーバーとよりうまく連携し、サーバーがより効率的に適切に呼び出されることを保証します。
そうですね、それは常に一対一の変換ではないということですね。適用できる異なる抽象化レベルがあり、おそらくAPI仕様はモデルが取り込むのに最も適切に定義されたものでもないかもしれません。あなたたちは基本的に毎日終日MCPと共に生きています。仕事でも家でもサイドプロジェクトでも何でも、あなたたちはそれをどのように使っていますか?Playwrightの例は知っていますが、あなたたちが他にサイドでMCPを実験している方法はありますか?
個人的に見つけた最大のユースケースの一つは、Anthropicはしばしば情報ハイウェイだということです。Slackやドキュメントやコードベースの至る所に非常に多くの情報があり、現在取り組んでいるプロジェクトの最新ステータスを理解することは、単一のソースからだけでは非常に、非常に簡単ではありません。だから私が習慣にしているのは、Claude.aiまたはClaude Codeのいずれかで、これらの様々な場所に接続するようにMCPサーバーを設定し、「ねえ、これが私が自分で書いた過去のプロジェクト更新のいくつかの例です。先週からの情報を見つけて、全く同じ形式を使用してステータス更新を生成できますか?」と尋ねるだけです。そしてその成功率は、私が元々考えていたよりもはるかに、はるかに高いと言えます。
それでは、私はあなたのSlackであなたのステータス更新を読んでいて、それらは全てClaude生成なのですか?
ええ、私はもう実際には何も書いていません。全部Claudeです。
ずっとあなたがClaudeを読んでいただけだったんですね。了解しました。Johnさんはどうですか?
自宅のハードウェアをいじることからいくつかの角度を見つけました。自宅のネットワークで実行されているいくつかのMCPサーバーがあり、家の周りのものをコントロールできます。そして私はClaudeとの会話の中で、「ねえ、今朝ドアの鍵をかけ忘れましたか?」と言うことができ、Claudeは「ええ、あなたのドアは現在施錠されていません。施錠しましょうか?」と言うことができます。そして戻ってきて「ええ、それは素晴らしいです」と言えます。
そういった類のことは本当に便利で、それで遊ぶのは一種の楽しいです。未来の世界がどのようなものになるかのスニークピークのような感じがします。MCPサーバーには一種の魔法のような感覚があります。なぜならそれらを追加することで、予想しないかもしれない創発的な特性が得られるからです。この例は、私たちがMCPサーバーで遊び始めた最初の時で、私はここAnthropicの同僚たちと知識グラフサーバーを構築しました。
この場合の知識グラフとは?
知識グラフというのは、Claudeに記憶を取り、記憶間の接続を形成する能力を与えたかったということです。それで2つのツールを持つMCPサーバーでした。Create Memoryツールと、Connect Memory to Other Memoryツールで、最もシンプルなインターフェースでした。
そして私たちはこれをClaudeに接続し、突然Claudeとの会話をすると、Claudeは調査ジャーナリストモードに入りました。私が「ピアノを弾きます」と言うと、Claudeは「それは素晴らしいですね、何を弾くのが好きですか?」と言いました。そして私は「ラフマニノフを弾くのが好きです」と言います。そしてClaudeは「そこで何かお気に入りはありますか?」と言います。そして私は知識グラフを見ると、Claudeが行って書き留めていて「ユーザーは洗練されたクラシック音楽の趣味を持っている」と言っており、楽器に熟練していることを見つけようとしていました。そしてそれはあなたが提供したそのような小さな変化から来たものです。
MCPをプロトコルとして持つことで本当にクールなことの一つは、Gmailサーバーとホームオートメーションサーバーを接続すれば、Claudeがあなたがそれに尋ねる問題を解決する何らかの方法を見つけることができ、あなたが決して考えもしなかったそれら2つを接続することによってです。
そうですね、ええ、これらの全てが一緒に接続された時、その間に一種のファジーなものがあり、それをClaudeの一種の一般知能と組み合わせると、興味深いことが起こる可能性があります。
そしてそれはMCPと伝統的な構造化されたAPIの間の核心的な違いの一つです。全てが非常にファジーで、LLMがそれをただ一緒にくっつけるのに十分賢いので、契約についてはるかに気にしなくなります。
Gmailとやり取りするためのMCPサーバーを持っていて、それからいくつかのevalを行い、Gmailとやり取りするためのより良いツールと説明のセットを見つけ、それが一連の説明を持つ15のツールから、もう一方を持つ2つのツールに変更された場合、そのためにAPIの新しいバージョンをロールアウトする必要がないという興味深い特性があります。
そのような大規模な方法でAPIを変更している場合は…
破壊的変更に対処しなければなりません。
破壊的変更、ユーザーと話すこと、これら全てを行うこと、MCPでは、私はそれをただロールアウトでき、MCPの意図がClaudeがGmailとやり取りできるようにすることなので、Read EmailsツールとWrite Emailツールを提供するようなことはありません。
だから本当にクールです。
ええ、それは特定の技術的な詳細よりも、より高いレベルの意図とアクションについてのことです。
ええ、ええ。
それは本当にクールですね。それでこれは全てどこに向かっているのでしょうか?MCPは6ヶ月後、12ヶ月後、1年以上経ったらどこにいるでしょうか?
それは興味深い質問です。なぜなら私は常に、あなたが知っているように、Johnが言ったように、MCPはプロトコルなので、プロトコルの人気を見るのは非常に興味深いと考えてきました。もしMCPが成功し、私たちと統合する全ての人が正しく仕事をすれば、MCPが内部で起こっていることを私たちは決して知るべきではありません。それはただあなたが使っているプログラムやアプリを使っているだけで、MCPは内部で起こっていて、全てを接着し、LLMが全てを設定して、あなたはそれに必要な腕と脚を与えているだけであるべきです。
しかしええ、MCPを巡る誇大宣伝を見るのは私にとって常に興味深いことでした。
そうですね、それは続くと思いますか?ここには高原のようなものがあるのでしょうか、それともプロトコルの観点から実際にはどのように見えるのでしょうか?MCPを判断するために見ることができる何らかの前例はありますか?
私たちがいるAIの世界の何かに前例を適用することは難しいと思いますが、JohnとMCPチームの彼の同僚たちが行っていることの多くは、非常にエキサイティングだと私は確実に見ています。
そしてそれは私にとって、大小の企業がテーブルに来て、どのようにそれを普及させ、インターネットと同じように、どこにでもあるユビキタスなものにできるかについて話し合うのを見るのは素晴らしいことでした。
私にとって今後本当にエキサイティングなことの一つ。今、多くの人々がMCPの価値に気づき、これらのサーバーを書き始めていると思います。しかしプロンプトとしてのMCPサーバーのアナロジーの観点からは、私たちはまだ非常に初期段階にいます。
だから私は、人々が今これらのサーバーを構築し始めたので、それらがどのように機能するかを評価し、それらをより良くし始めることに本当に興奮しています。そして私は、それがあなたの仕事のベンダーを評価する指標になり始めることに興奮しています。例えば、もし私が誰かにログ解析をするために支払っている場合、彼らのログ解析MCPサーバーを私のClaudeに接続するだけで、「ねえ、私のサイトがダウンしています、何が起こっているのですか?」と言えたら本当にクールで、私にとって本当に価値があります。
そして彼らがClaudeに彼らのサービスとやり取りし、それらの答えを見つけるために必要なツールを与える本当に素晴らしいMCPサーバーを設計し開発していれば、それはエンジニアとしての私にとって大きなセールスポイントです。なぜなら私はこの機能に頼ることができるからです。私はそれを構築する必要がありません。そしてこれがより成熟し始め、MCPサーバーを出荷したことがエキサイティングであることから脱却し始めるのを見ることに私は興奮しています。
人々が「私たちは最高のMCPサーバーを持っています」と競争し始めるのを見始めています。これはあなたの人生をはるかに簡単にするでしょう。あなたは私たちを使うべきです。なぜなら私たちはこの方法でClaudeとやり取りするからです。
まあ、私もその未来にワクワクしています。来てくれてありがとうございました。これは素晴らしかったです。
ありがとうございました。
本当にありがとうございました。
コメント