シェア:
){kind=small}
Benjamin AronovはVonageの開発者支援者です。彼はRuby on Railsのバックグラウンドを持つ実績のあるコミュニティ・ビルダーです。Benjaminは故郷であるテルアビブのビーチを楽しんでいる。テルアビブを拠点に、世界最高のスタートアップの創設者たちと出会い、学ぶことができる。技術以外では、完璧なパン・オ・ショコラを求めて世界中を旅するのが好き。
MCPツールとVonage APIを使った4つの教訓
モデル・コンテキスト・プロトコル（MCP）の動きは早い。昨年3月の FOSSASIA 2025.まだ1年も経っていないとは信じがたいが、すでにプログラミングの世界ではユビキタスになっているように感じる。
早くからそのことは耳にしていたけれど、本当に飛び込んだのはここ数ヶ月のことだった。私は Vonageドキュメントと ツーリングMCPサーバー最初はローカルで、それからブログの投稿やデモを通して、そして最終的にはオープンソースのツーリング・サーバーを手伝ってきました。これはMCPの機能のまとめでもなければ、始めるためのガイドでもありません：ツールを実際に使えるようにしようとする中で見えてきた教訓の集合なのだ。
最初の本当の失敗は技術的なバグではなかった。メンタルモデルに欠陥があったのだ。
IDEをMCPサーバーに接続し、ツールが登録されていることを確認し、エージェントにWhatsAppメッセージの送信を依頼した。エージェントは既存のツールを呼び出す代わりに、新しいファイルを開き、Node.jsスクリプトを書き始めた。Vonage SDKをインポートし、認証を設定し、APIコールを直接行おうとした。
モデルは何も「間違って」いなかった。コードを書くことで問題を解決するという、訓練されたことを忠実に実行していたのだ。
問題は、私がどのようにシステムを構築したかにあった。エージェントは、オーケストレーションレイヤーとしてではなく、よりスマートなコードジェネレーターとして機能していた。ツールはすでに存在していた。エージェントは何も構築する必要はなく、利用可能なものを選択して呼び出すだけでよかった。
エージェントにプロンプトを出す方法を調整したら、物事はうまくいった。機能性を作るように求めるのではなく、機能性を使うように求めたのだ。
この変化は些細なことのように聞こえるが、実際には大きな精神的変化なのだ。
要点：MCPが最もうまくいくのは、スクリプトの観点から考えるのをやめて、ツールの観点から考え始めたときだ。もしエージェントが糊塗されたコードを書いているなら、それはたいてい上流の何かが正しく構造化されていないことを意味する。
メンタルモデルが修正されれば、残りの仕事は簡単だと思った。そうではなかった。
ローカル開発で最も時間がかかったのは、IDEをMCPサーバーに確実に接続させることだった。ほとんどの失敗は「ツールが表示されない」ように見えたので、サーバーが壊れていると考えるのは簡単だった。ほとんどの場合、設定が原因だった。
IDEによって、MCPのコンフィギュレーションは異なる場所にあります。例えば、WindsurfはVS Codeのように見えますが、VS Codeではありません。サーバーがそもそも起動しなかったので、存在しないバグを追いかけるのに認めたくないほど多くの時間を費やしました。
MCPコンフィグもシェルスクリプトのようには動作しない。クライアントが直接プロセスを起動します。そのため sh -c, cdや連鎖コマンドに頼ることはできない。絶対パスや明示的なコマンドを使わないと、失敗が無音になりがちだ。
すべてが正しく設定されると、最高の形で何事もなく体験できた。IDEを再起動し、プラグインパネルをリフレッシュすると、ツールが表示される。
要点：MCPはお馴染みのプログラミング・パターンに従っている。何かがうまくいかないときは、たいていコンフィギュレーションが原因です。いったんセットアップが完了すれば、MCPはあなたを羽ばたかせる！
MCPのデフォルトのstdioトランスポートはローカル開発に適しています。シンプルで速く、ポートや認証情報を公開する必要がありません。IDEベースのワークフローでは、まさにあなたが望むものを実現してくれる。そして、それこそが、私たちが ツーリング・サーバーに採用した理由です。私たちは、これを開発者の手に素早く、柔軟に届けたかったのです。
しかし、外部システムとの統合など、IDEの外で同じツールを使おうとすると、いくつかの制限が出てきます。stdinにHTTPリクエストはできない。セキュアにするエンドポイントもなければ、認証を付けるための明白な場所もない。
そのギャップを埋めるために、私は結局、他のシステムがMCPサーバーとやり取りできるように、stdio上のJSON-RPCをHTTPに変換する小さな翻訳レイヤーを構築した。それはうまくいったが、ローカルだけのセットアップには存在しない追加のインフラだった。
テストも厄介になった。エージェントがどこか他の場所からツールを呼び出している場合、「ローカルで動作する」ことはあまり意味がありません。現在のところ、完全なエージェントセッションをスピンアップせずに、MCPツールを単独で検証するためのクリーンなミドルグラウンドはありません。
要点：MCPはIDEのワークフローを簡単にする。ホスティングや認証の管理に慣れている開発者にとっては、このトレードオフは合理的だ。ローカルでの使用を超えると、stdioは認証、翻訳レイヤー、テストなどの課題をもたらします。これらは、MCPそのものというよりも、このサーバーがどこに位置するかという問題です。MCPの提供が拡大するにつれ、目が離せません。
この教訓は何かが壊れたからではない。ツーリングサーバーを見て、"もっと多くの人が貢献し始めたらどうなるだろう？もっと多くの人が貢献し始めたらどうなるだろう？"
について書きながら Vonage MCPツールの使用そして オープンソースへの貢献を奨励するレポの構造が成長するように設計されていないことが明らかになりました。すべてが1つのファイルに収められていた。それは初期には管理可能ですが、うまく拡張できません。人間にとっても、エージェントにとっても。
他のMCPサーバーがどのように成長を扱うかを見てみると、より重要な制約が浮かび上がってきた。
ツールスキーマは自由ではない。名前、パラメータ、説明はすべてシステムプロンプトに注入される。ツールの数が増えるにつれて、モデルがユーザーの実際のリクエストについて推論するためのスペースは徐々に減っていきます。
柔軟で多目的のツールを作りたくなるのは自然なことだ。 send_messageという単一の send_message で、あらゆるチャネルと動作を処理できる。APIの観点からは、それは整然としている。モデルの観点からは、それは曖昧で高価だ。
小さくて単一の目的の道具の方がうまくいく傾向がある。モデルが選択しやすく、記述コストが安く、推論が単純だからだ。内部的には、実装はまだ共有することができる。最も重要なのは、エージェントが何を見るかである。
現在のオープンソースのツールサーバーは、まだコンテキストを意識したロードを実装していません。しかし、これらの制約は、私たちがより製品化されたMCPサーバーについてどのように考えているかをすでに形成しています。
要点：MCPでは、パフォーマンスは実行速度だけではありません。コンテキストをどれだけ消費するかということでもある。
MCPと仕事をすることで、日々の仕事に対する考え方が変わりました。以前は手作業や反復的なものとして受け入れていたプロセスが、今では潜在的なツールとなった。一度そのようなシフトが起こると、あらゆるところにチャンスが見え始めます。そのために自動化するのではなく、実際の仕事を遅くしている場所の摩擦を取り除くのです。
MCPはまだ歴史が浅く、多くの荒削りな部分は理解できる。MCPベースのシステムが成功するかどうかは、選択するモデルだけでなく、ツールがいかに思慮深く設計されているかにかかっているのだ。明確な境界線、狭い責任、予測可能な動作は、巧妙な抽象化よりも重要である。これらの要素が整えば、システムは信頼しやすくなり、拡張しやすくなる。
私が最も興味深いと思うのは、MCPがソフトウェアというものを「使うもの」と考えるように促していることだ。 使われる人間だけでなく、エージェントによって使用されるものだと考えることをMCPが後押ししていることです。それによって、APIの書き方、ドキュメントの構成、何かが "完了 "したかどうかの評価方法が変わってくる。これはトレードオフの異なるセットであり、まだ形になっていないものだ。
今後数週間は、次のような他のMCPツールも試してみるつもりです。 Laravel Boostや MCP UIのような他のMCPツールも試してみるつもりです。もしあなたがMCPを使って仕事をしているなら、あるいはMCPについて考えているなら、あなたが何を作っているのか、そしてその過程で何を学んだのか、ぜひ聞かせてください。私に LinkedInのメッセージまたは Vonage開発者Slack.
