OpenAI、Agents SDKにMCPサポートを追加

 (openai.github.io)
8 ポイント 投稿者 GN⁺ 2025-03-27 | 4件のコメント | WhatsAppで共有
  • MCP(Model Context Protocol) は、LLMにツールとコンテキストを提供するための標準化された方式
  • USB-Cポートのように、さまざまなデータソースやツールとAIモデルを接続する標準インターフェースとして機能
  • OpenAI Agents SDKはMCPをサポートし、さまざまなMCPサーバーと統合可能

MCPサーバー

  • 現在のMCP仕様では、使用する転送メカニズムに応じて2種類のサーバーを定義している:
    1. stdio サーバーはアプリケーションのサブプロセスとして実行され、「ローカル」で実行されるものと考えられる。
    2. HTTP over SSE サーバーはリモートで実行され、URLを通じて接続する。
  • MCPServerStdio と MCPServerSse クラスを使用して、これらのサーバーに接続できる。
  • たとえば、公式のMCPファイルシステムサーバーを使用する方法は次のとおり: 
    async with MCPServerStdio(  
    params={  
        "command": "npx",  
        "args": ["-y", "@modelcontextprotocol/server-filesystem", samples_dir],  
    }  
) as server:  
    tools = await server.list_tools()

キャッシュ

  • エージェントの実行ごとにMCPサーバーの list_tools() を呼び出すと、レイテンシが発生する可能性がある。特にサーバーがリモートサーバーである場合はなおさら。
  • ツール一覧を自動的にキャッシュするには、MCPServerStdio と MCPServerSse に cache_tools_list=True を渡すことができる。これは、ツール一覧が変更されないと確信できる場合にのみ行うべき。
  • キャッシュを無効化するには、サーバーで invalidate_tools_cache() を呼び出せる。

関連記事

4件のコメント

 
GN⁺ 2025-03-27
Hacker Newsの意見

  • 今日、MCP に Streamable HTTP が追加された。これは、リモート HTTP サーバーに常時接続しておく必要がないという点で大きな前進だ

    • ただし仕様を見ると、LSP スタイルのパラダイムをリモート HTTP サーバーに持ち込むことで、多くの複雑さが追加されている
    • 従来は /get_weather に { "location": "New York" } を HTTP POST で送る方式だった
    • 複雑さを減らし、従来の HTTP サーバーに戻そうという提案をした。セッションは Authorization ヘッダーでネゴシエーションし、従来のエンドポイントを使う
    • サーバー構築ははるかに簡単になり、Web フレームワークが仕様に合わせて更新される必要もなくなるはずだ

  • MCP を AI アプリケーションの USB-C ポートだと考えろ、というたとえがある

    • ソフトウェアエンジニアとしては、そのたとえは役に立たない

  • OpenAI がこれを公式に支持するのか気になっていたが、これで答えが出た

    • MCP は LLM を外部ツールに接続するための業界標準になった

  • OpenAPI をサポートしてほしかった。MCP サーバーをいくつか作ったが、より柔軟性が低く、ドキュメント化も不十分な API に感じる

    • MCP が OpenAPI より優れている点を見つけるのは難しい。コードは少し減るが、選択肢は大幅に減る
    • いずれ Swagger が組み込まれるだろう

  • MCP の価値が何なのか理解しづらい。現代の AI 技術の混乱の中で、また別の気を散らす要素のように感じる

    • MCP は、アプリケーションが LLM にコンテキストを提供する方法を標準化するオープンプロトコルだ
    • 何を標準化する必要があるのか疑問だ。私たちは任意のトークン化された文字列で動くテキストからテキストへの変換器を使っている
    • ツール/関数呼び出しのようなものも、単なるテキストの上に成り立つ巧妙なヒューリスティクスにすぎない

  • AI エージェントがローカルで「ツール」を使えるアーキテクチャを作った。あらゆる種類の LLM および LLM サーバーで動作する

    • ミドルウェアとして動作し、LLM サーバーとチャットクライアントの間でストリームとして機能する
    • オープンソースプロジェクトだが、コードに関心を示す人がいないため、リポジトリは更新されていない

  • MCP を実際にどう使うのかについての動画が不足している。プログラマー向けの実用的なユースケースが足りない

  • MCP を AI アプリケーションの USB-C ポートだと考えろ、というたとえがある

    • USB 実装には多くの苦労が伴うという話をよく聞くので、別のたとえを探したほうがよいだろう

  • これは MCP の旧バージョンである HTTP+SSE を対象にしているように見える。新しい Streaming HTTP バージョンではない

    • OAuth 2.1 サポートや JSON-RPC バッチ処理などもある

  • MCP を手軽に試してみたいなら、<a href="https://skeet.build/mcp" rel="nofollow">skeet.build/mcp</a> を作った

    • 複雑な MCP 設定、サポート不足、自前構築の難しさがあるため作った
    • 主に次のようなワークフローに使われる
      • PR 開始時に要約を作成
      • Linear/Jira に要約を投稿し、Slack またはコメントを付ける
      • Sentry からイシューを取得して修正
      • バグを見つけたら Linear イシューを作成
      • Linear イシューを取得して最初のパスを行う
      • Notion ドキュメントと PRD を取得し、コードベースから API リファレンスを生成
      • 迅速なモデル開発のための Postgres または MySQL スキーマ
    • 使いやすさ、実用的な開発者ワークフロー、高品質な MCP サーバーに重点を置いている
 
samchon 2025-03-27

私も OpenAPI の function calling のほうがいいのではないかと思います。これを MCP プロトコルで作り直すのも手間なんですよね。
 
mangoblue 2025-03-28

push と poll の違いではないでしょうか。モデルやサービスごとに function calling するより、MCP の仕様をホスティングしてエージェントが poll していく方式のほうが、3rd party にとっては便利な気がします