OpenAI erweitert Agents SDK um Unterstützung für MCP

 (openai.github.io)
8 Punkte von GN⁺ 2025-03-27 | 4 Kommentare | Auf WhatsApp teilen
  • MCP (Model Context Protocol) ist eine standardisierte Methode, um LLMs Werkzeuge und Kontext bereitzustellen
  • Wie ein USB-C-Port dient es als standardisierte Schnittstelle, die verschiedene Datenquellen oder Werkzeuge mit AI-Modellen verbindet
  • Das OpenAI Agents SDK unterstützt MCP und kann dadurch mit verschiedenen MCP-Servern integriert werden

MCP-Server

  • Die aktuelle MCP-Spezifikation definiert je nach verwendetem Übertragungsmechanismus zwei Arten von Servern:
    1. stdio-Server werden als Unterprozess einer Anwendung ausgeführt und können als „lokal“ laufend betrachtet werden.
    2. HTTP over SSE-Server laufen remote und werden über eine URL verbunden.
  • Mit den Klassen MCPServerStdio und MCPServerSse kann eine Verbindung zu diesen Servern hergestellt werden.
  • Zum Beispiel kann der offizielle MCP-Dateisystem-Server wie folgt verwendet werden: 
    async with MCPServerStdio(  
    params={  
        "command": "npx",  
        "args": ["-y", "@modelcontextprotocol/server-filesystem", samples_dir],  
    }  
) as server:  
    tools = await server.list_tools()

Caching

  • Bei jedem Lauf eines Agenten list_tools() auf dem MCP-Server aufzurufen, kann Latenz verursachen. Das gilt insbesondere dann, wenn es sich um einen Remote-Server handelt.
  • Um die Werkzeugliste automatisch zu cachen, kann an MCPServerStdio und MCPServerSse cache_tools_list=True übergeben werden. Dies sollte nur erfolgen, wenn sicher ist, dass sich die Werkzeugliste nicht ändern wird.
  • Um den Cache zu invalidieren, kann auf dem Server invalidate_tools_cache() aufgerufen werden.

Verwandte Beiträge

4 Kommentare

 
GN⁺ 2025-03-27
Hacker-News-Kommentare

  • Heute hat MCP Streamable HTTP hinzugefügt. Das ist ein großer Fortschritt, weil keine permanente Verbindung zu einem entfernten HTTP-Server mehr nötig ist

    • Wenn man sich jedoch die Spezifikation ansieht, bringt die Einführung eines LSP-ähnlichen Paradigmas für entfernte HTTP-Server viel Komplexität mit sich
    • Traditionell schickt man einfach { "location": "New York" } per HTTP-POST an /get_weather
    • Es wurde vorgeschlagen, die Komplexität zu reduzieren und zu traditionellen HTTP-Servern zurückzukehren. Sitzungen werden über den Authorization-Header ausgehandelt und es werden traditionelle Endpunkte verwendet
    • Das würde den Serverbau viel einfacher machen, und Web-Frameworks müssten nicht aktualisiert werden, um der Spezifikation zu entsprechen

  • Es gibt die Analogie, man solle sich MCP als den USB-C-Port für AI-Anwendungen vorstellen

    • Als Softwareentwickler hilft diese Analogie nicht weiter

  • Ich habe mich gefragt, ob OpenAI das offiziell unterstützen würde, aber jetzt habe ich die Antwort

    • MCP ist zum Industriestandard geworden, um LLMs mit externen Tools zu verbinden

  • Ich hatte auf Unterstützung für OpenAPI gehofft. Ich habe ein paar MCP-Server gebaut, aber es wirkt wie eine weniger flexible und schlechter dokumentierte API

    • Es ist schwer zu erkennen, worin MCP besser als OpenAPI sein soll. Der Code wird etwas kürzer, aber die Auswahlmöglichkeiten nehmen stark ab
    • Mit der Zeit wird Swagger wohl eingebaut werden

  • Es ist schwer zu verstehen, worin der Wert von MCP liegt. Inmitten des Chaos moderner AI-Technologien wirkt es wie eine weitere Ablenkung

    • MCP ist ein offenes Protokoll, das standardisiert, wie Anwendungen LLMs Kontext bereitstellen
    • Ich frage mich, was es da überhaupt zu standardisieren gibt. Wir benutzen Text-zu-Text-Transformatoren, die mit beliebigen tokenisierten Zeichenketten arbeiten
    • Auch Dinge wie Tool-/Function-Calling sind nur clevere Heuristiken auf einfachem Text

  • Ich habe eine Architektur gebaut, in der AI-Agenten lokal „Tools“ verwenden können. Sie funktioniert mit allen Arten von LLMs und LLM-Servern

    • Sie arbeitet als Middleware und läuft als Stream zwischen LLM-Servern und Chat-Clients
    • Es ist ein Open-Source-Projekt, aber das Repo wird nicht aktualisiert, weil niemand Interesse am Code zeigt

  • Es gibt zu wenige Videos darüber, wie man MCP tatsächlich verwendet. Für Programmierer fehlen greifbare Anwendungsfälle

  • Es gibt die Analogie, man solle sich MCP als den USB-C-Port für AI-Anwendungen vorstellen

    • Da ich viele Geschichten darüber gehört habe, wie schmerzhaft USB-Implementierungen sind, wäre eine andere Analogie wohl besser

  • Das scheint auf HTTP+SSE abzuzielen, also auf die ältere Version von MCP, nicht auf die neue Streaming-HTTP-Version

    • Es gibt auch Unterstützung für OAuth 2.1, JSON-RPC-Batching usw.

  • Wenn man MCP einfach ausprobieren möchte, wurde <a href="https://skeet.build/mcp" rel="nofollow">skeet.build/mcp</a> gebaut

    • Es wurde wegen der komplexen MCP-Einrichtung, mangelnder Unterstützung und der Schwierigkeit des Selbstaufbaus entwickelt
    • Es wird hauptsächlich für folgende Workflows verwendet
      • Beim Start einer PR eine Zusammenfassung schreiben
      • Eine Zusammenfassung in Slack oder als Kommentar in Linear/Jira posten
      • Issues aus Sentry holen und beheben
      • Bei entdeckten Bugs ein Linear-Issue erstellen
      • Ein Linear-Issue abrufen und einen ersten Durchgang machen
      • Notion-Dokumente und PRDs abrufen und daraus eine API-Referenz auf Codebasis erstellen
      • Postgres- oder MySQL-Schemata für schnelle Modellentwicklung
 
samchon 2025-03-27

Ich denke auch, dass OpenAPI Function Calling nicht besser wäre. Das noch einmal mit dem MCP-Protokoll neu aufzubauen, ist nämlich ebenfalls Aufwand.
 
mangoblue 2025-03-28

Ist das nicht eher der Unterschied zwischen Push und Poll? Es scheint für Dritte praktischer zu sein, die MCP-Spezifikation zu hosten und den Agenten per Poll darauf zugreifen zu lassen, statt je nach Modell oder Service jeweils Function Calling zu implementieren.