MCP-Spezifikation – Änderungen in der Version vom 2025-06-18

 (modelcontextprotocol.io)
1 Punkte von GN⁺ 2025-06-20 | 2 Kommentare | Auf WhatsApp teilen
  • Das neue Update der MCP-Spezifikation legt den Schwerpunkt auf strukturierte Metadaten und Kontextverwaltung. Ziel sind eine bessere Erweiterbarkeit und stärkere Interoperabilität zwischen verschiedenen Systemen
  • Es werden neue Datenfelder hinzugefügt, und bestehende Pflichtfelder werden genauer definiert. Durch die Hierarchisierung der Metadatenstruktur werden systemspezifische Erweiterungsansätze unterstützt
  • Es werden klare Regeln für Kontextverfolgung und Attributaktualisierung festgelegt; im Vergleich zu früher wird die Funktion für eine konsistente Verwaltung von Statusinformationen stärker betont
  • Rechtemanagement und Datenvalidierung werden in der Protokollspezifikation ausdrücklich festgelegt. Einige neu hinzugefügte Felder wurden mit Blick auf die Kompatibilität mit zukünftigen Protokollversionen aufgenommen
  • Unterstützung für plattformübergreifende Integration: Es wird eine Grundlage geschaffen, um Kontextdaten auch über verschiedene AI-Plattformen und Cloud-Service-Umgebungen hinweg auf konsistente Weise auszutauschen
  • MCP(Model Context Protocol) ist ein Protokoll für den Austausch von Kontext-Metadaten zwischen verschiedenen AI-Systemen wie Machine-Learning-Modellen oder großen Sprachmodellen

Major changes

  1. Unterstützung für JSON-RPC-Batching entfernt (PR #416)
  2. Unterstützung für structured tool output hinzugefügt (PR #371)
  3. MCP-Server als OAuth-Resource-Server klassifiziert; geschützte Ressourcen-Metadaten hinzugefügt, damit der zugehörige Authorization-Server gefunden werden kann (PR #338)
  4. MCP-Clients müssen den Resource Indicator aus RFC 8707 implementieren (um zu verhindern, dass bösartige Server Zugriffstoken erhalten) (PR #734)
  5. Security Considerations und Best Practices in der Authorization-Spezifikation präzisiert, zusätzlich wurde eine eigene Seite zum Sicherheitsleitfaden hinzugefügt
  6. Elicitation-Funktion hinzugefügt, damit Server zusätzliche Informationen vom Benutzer anfordern können (PR #382)
  7. Unterstützung für Resource Links hinzugefügt, sodass Ergebnisse von Tool-Aufrufen Ressourcen-Links enthalten können (PR #603)
  8. Bei der Aushandlung der Protokollversion ist unter HTTP der Header MCP-Protocol-Version verpflichtend (PR #548)
  9. SHOULD bei Lifecycle Operation in MUST geändert (Referenz)

Other schema changes

  1. Das Feld _meta wurde zu weiteren Interface-Typen hinzugefügt (PR #710), korrekte Verwendung dokumentiert
  2. Feld context zu CompletionRequest hinzugefügt, kann zuvor aufgelöste Variablen enthalten (PR #598)
  3. Feld title für eine benutzerfreundliche Anzeige zusätzlich zu programmbezogenen Identifikatoren hinzugefügt (name für Code-Identifikatoren, title für die Anzeige) (PR #663)

Verwandte Beiträge

2 Kommentare

 
kernel00 2025-06-20

Der Kommentar auf Hacker News ist etwas enttäuschend. Anscheinend haben sie sich nur stdio angesehen, obwohl gerade überall Remote-MCP-Server und Registries entstehen, die diese vermitteln....
 
GN⁺ 2025-06-20
Hacker-News-Kommentare
  • Das Wichtigste, was ich durch den MCP- (Machine Context Protocol-)Boom gelernt habe, ist, dass man MCP in der Backend-Softwareentwicklung nicht unbedingt braucht. Architektonisch passt es an manchen Stellen einfach nicht. Gerade in Umgebungen wie Elixir gilt das meiner Meinung nach umso mehr. Wenn man für jede API einen eigenen Server aufsetzt, bedeutet das bei 500 APIs letztlich 500 Microservices. Erst nachdem ich selbst rund 20 verschiedene MCP-Server ausprobiert hatte, wurde mir klar, dass MCP am Ende nur ein Mantel um Function Calling ist. Jede API muss kein Server sein, ein separates Modul reicht völlig aus. Es gibt keinen Grund, zwanghaft der neuesten MCP-Spezifikation zu folgen oder bei jeder Spezifikationsänderung Hunderte von Microservices zu aktualisieren. Mein Fazit: einfach unnötige Komplexität
    • Solange der Client nicht ohne Gateway oder BFF direkt mit jedem Microservice verbunden wird, kann man MCP einfach vor den gesamten Service setzen und Funktionen wie bisher über API, GraphQL, RPC usw. bereitstellen. Es wirkt im Grunde wie eine auf LLMs spezialisierte Schnittstelle. Auch Tool Calls auf Basis der OpenAPI-Spezifikation sind völlig ausreichend. Dass am Ende alle Microservices nur noch über MCP miteinander kommunizieren, ist jedenfalls eine viel zu extreme Vorstellung
    • Ich habe MCP eher als eine pluginartige Integrationslösung gesehen, die Function Calls wie bei Claude ohne API-Kosten ermöglicht. Wenn du ohnehin APIs nutzt und es nicht eilig hast, ist es keine Option, die du unbedingt brauchst
    • Eigentlich ist MCP meiner Meinung nach ein Standardprotokoll, das Client und Modell verbindet. Es ist nicht einfach nur ein Behälter, der Tool-Aufrufe umschließt
    • Genau, ein eigener MCP-Server pro API skaliert nicht. Mit etwas wie nango.dev kann ein einzelner Server mehr als 400 APIs abdecken. Es bietet Authentifizierungsabwicklung, bessere Transparenz und verschiedene Interfaces für direkte Tool Calls. (Zur Transparenz: Ich bin der Gründer.)
    • Ich gehe noch einen Schritt weiter und halte schon die ganze Kultur, LLMs zu JSON-Ausgaben zu zwingen, für töricht. Es kostet zu viel Zeit und Mühe, sie in ein kompliziertes Format zu pressen, das sie von Natur aus nicht mögen. Ein deutlich stärker eingeschränktes textbasiertes DSL war für mich eine viel bessere Alternative. Schon zu GPT 3.5-Zeiten konnte man mit ein paar einfachen Beispielen im Prompt ein englischbasiertes DSL zuverlässig erzeugen lassen. Gleichzeitig gibt es selbst bei den neuesten Modellen noch den Hinweis, dass Teile eines JSON-Schemas gelegentlich ignoriert werden. Es fühlt sich an, als würde man einen runden Zapfen mit Gewalt in ein eckiges Loch schlagen. Ich wünschte, die Leute würden damit aufhören
  • Ich freue mich wirklich sehr, dass es jetzt einen einfachen Weg zu authentifizierten MCP-Servern gibt. Der MCP-Community und dem Anthropic-Team möchte ich dafür aufrichtig danken
    • Ich verstehe nicht so recht, warum man überhaupt einen MCP-Server braucht. Wenn ein Agent RPC machen will, warum verwendet er dann nicht einfach RPC?
  • Ich finde es wirklich bemerkenswert, dass die Kernspezifikation in TypeScript statt in OpenAPI oder etwas anderem geschrieben ist. Es wird sicher gute Gründe dafür geben, aber überraschend ist es trotzdem
    • Mich würde interessieren, warum das überraschend ist. Ich nutze auch viel TypeScript, aber aus dieser Perspektive habe ich das noch nie betrachtet, deshalb würde mich interessieren, welche Entscheidungen im Sprachdesign dahinterstehen
  • Ich freue mich sehr über die Einführung der WWW-Authenticate-Challenge. Jetzt ist klar umrissen, dass ein MCP-Server den Client in den OAuth-Flow des Ressourcenanbieters schicken und dann einfach nur den Header Authorization: Bearer ... entgegennehmen muss
  • Ich denke, dass es <i>größtenteils</i> tatsächlich unnötige Komplexität ist, aber die Batch-Ausführung fehlt mir. Es hat Spaß gemacht, etwas in der Art von „Erledige all diese Aufgaben und gib die Ergebnisse gesammelt in einer Antwort zurück“ zu implementieren. Natürlich kann auch der Client Batch-Antworten selbst bündeln, aber es macht trotzdem Spaß
    • Stimmt. Die JSON-RPC-Batch-Funktion war für mich wirklich so ein „Wow, das ist ja cool“-Moment. Schade, dass sie aus der Spezifikation verschwindet, aber ich verstehe es auch, weil sie letztlich zusätzliche Komplexität bringt
  • Ich denke, elicitation (promptgesteuerte Interaktion auf Basis von Rückfragen) ist ein großer Gewinn. Einer meiner liebsten MCP-Server ist ein selbst gebauter SSH-Server. Damit kann ich 90 % meiner gesamten Serverarbeit automatisieren. Die Authentifizierung verwalte ich über eine Konfigurationsdatei, aber wenn ich mich mit einem neuen Server verbinden muss, muss ich sie jedes Mal manuell anpassen, was etwas umständlich ist
    • In so einem Fall könnte man auch etwas wie fabfile.org verwenden. Wenn das Gespräch nicht unbedingt ein LLM braucht, ist es meiner Meinung nach besser, es privat zu halten
  • Ich habe in den letzten Tagen etwas mit MCP herumgespielt und einen Dataset-Wrapper gebaut
  1. Für mich ist das einer der spannendsten Ansätze im LLM-Bereich. Natürlich könnte man Ähnliches auch mit bestehenden APIs und Tool Calls machen, aber selbst einem technisch nicht besonders versierten Freund einfach eine MCP-URL für Claude zu schicken und ihn das mit ein paar Klicks ausprobieren zu lassen, fand ich sehr beeindruckend
  2. Ich nutze das csharp SDK, und die Authentifizierungsfunktion liegt derzeit noch nur in einem Branch, also ist alles noch sehr früh. 95 % meiner Zeit bei der MCP-Integration gingen in die Implementierung der Authentifizierung (außer bei einem lokalen Build ist sie unverzichtbar). Das wird sicher besser, sobald mehr Dokumentation da ist, aber im Moment ist es noch ziemlich aufwendig
  3. Es fehlt auch an der Sichtbarkeit für Entwickler-Logs. Ich würde mir wünschen, dass Claude im Web (nicht auf dem Desktop) im Entwicklermodus Request-/Response-Logs anzeigt, also was tatsächlich ausgetauscht wird und wo Fehler auftreten. Ich habe lange mit Problemen bei der Erneuerung der Authentifizierung gekämpft und erst spät gemerkt, dass ich den falschen Endpoint geloggt hatte. Mit besserem MCP-Logging wäre das in ein paar Minuten erledigt gewesen. Auf dem Desktop und im MCP Inspector funktioniert es gut
  4. Mein größtes Problem ist die Verarbeitung lang laufender Aufgaben. Die Datasets, die ich bereitstelle, bestehen aus mehreren PDF-Dokumenten. Claude scheint PDFs nicht selbst verarbeiten zu können (falls doch jemand einen Weg kennt, bitte her damit!), deshalb lasse ich sie derzeit erst durch gemini in Text umwandeln und reiche sie dann über MCP weiter. Bei einfachen Dokumenten klappt das gut, bei langen Dokumenten dauert die Verarbeitung aber entsprechend lange. Im Moment sende ich nur den Hinweis „Verarbeitung läuft, bitte später noch einmal versuchen“. Es gibt zwar eine Progress-API, aber dafür muss die Verbindung zum Server dauerhaft offen bleiben (über Cloudflare wird sie nach einer gewissen Zeit getrennt), was ihre praktische Nutzbarkeit begrenzt. Es wäre großartig, wenn das LLM angewiesen werden könnte, nach x Sekunden erneut nachzusehen und bis dahin andere Aufgaben zu erledigen, also eine Art „Ausführung vorübergehend pausieren“, bis der Timer abgelaufen ist. Aktuell führt das Offenhalten der Verbindung entweder dazu, dass das LLM nichts anderes tun kann und nur wartet, oder dass man eine Job-ID zurückgibt und dann oft nur eine unvollständige Antwort herauskommt, bei der der Gesamtkontext fehlt. Für Aufgaben, die mehr als 10 Minuten dauern, könnte das ein großes Hindernis sein
  • Lang laufende Aufgaben werden derzeit noch öffentlich diskutiert. Soweit ich weiß, will MCP das in Zukunft lösen. Es gibt verschiedene Vorschläge, und da man nicht immer weiß, ob eine Aufgabe lange dauern wird, ist eine separate API für Langläufer allein keine ausreichende Lösung. Ich habe dazu auch einen Vorschlag gemacht, der das ganzheitlich angeht: Diskussion-Link
  • Ich freue mich sehr darüber, wie schnell sich die MCP-Spezifikation verbessert. Mit jedem neuen Release sehe ich, wie einer nach dem anderen genau die Punkte nachgebessert werden, die ich bei meinen MCP-Integrationen zuvor vermisst hatte
  • Ich finde es interessant, dass für die Übernahme einer Spezifikationsänderung offenbar nur eine einzige Zustimmung nötig ist
  • Ich verstehe nicht so recht, welches Problem MCP in der Praxis eigentlich löst. Für mich kommt es im Moment vor allem fürs schnelle Prototyping auf dem Notebook infrage. Wenn ich ein lokales Programm baue, möchte ich das Toolset, auf das ein LLM zugreifen kann, viel granularer kontrollieren. Selbst wenn ich an einen MCP-Server für Google Calendar denke, spart mir MCP nicht wirklich viel Zeit. Ich könnte dieselbe API auch direkt selbst nutzen, und ich muss dem LLM ohnehin explizit sagen, wann und wie es Google Calendar aufrufen soll, also möchte ich das ungern an einen Dritten delegieren. Außerdem fühlt es sich unangenehm an, in meiner Umgebung beliebig Prozesse zu starten, unabhängig davon, in welcher Sprache das MCP geschrieben wurde. Wenn mein eigener Stack Python ist, kann es problematisch sein, den Nutzern zusätzlich noch eine TypeScript-Runtime abzuverlangen. Wenn ein MCP-Wrapper Sicherheitslücken hat, mache ich mir auch darüber Sorgen. Im Serverumfeld ist die Rechtfertigung noch schwieriger. Für Aufrufe über verschiedene Maschinen hinweg, ohne die Implementierungsdetails zu kennen, gibt es mit RPC bereits einen hervorragenden Weg. MCP wirkt für mich so, als würde es darauf nur noch meinungsstarke Middleware und Sicherheitsprobleme draufsetzen
    • Was ich nicht verstehe, ist, warum alle MCPs, die ich bisher gesehen habe, kommando- bzw. prozessbasiert sind und keine HTTP-Schnittstelle nutzen. Mit HTTP könnte man einen einzigen Server betreiben, den die ganze Organisation gemeinsam nutzt, ohne dass jeder seine eigene Toolchain einrichten muss
    • Anders als bei herkömmlichen Ansätzen, bei denen das Backend einen festen Ablauf vorgibt, kann mit MCP das LLM selbst die Orchestrierung direkt übernehmen. Wenn es zum Beispiel eine Websuche macht, kann es die Query mehrfach anpassen und es erneut versuchen, bis es die gewünschten Informationen findet. Auch beim Lösen spezieller Probleme über die CLI kann es mehrere Tools in der passenden Reihenfolge einsetzen. Diese Art der Organisation ist mit einem festen Ablauf nicht möglich
    • MCP löst das Problem, aus einer LLM-zentrierten Perspektive verschiedene Fähigkeiten wie Tools standardisiert über ein Protokoll an einen Agenten anzubinden
    • In Teilen stimme ich dir stark zu. Wenn man es tatsächlich benutzt, fühlt es sich ziemlich langsam an. Ich habe vor zwei Jahren sogar meinen Job gekündigt, um einen LLM-Client zu entwickeln, und habe trotzdem bis heute keine Google-Calendar-Integration hinbekommen. Aus Nutzersicht liegt der Nutzen von MCP darin, solche provisorischen Lücken zu stopfen. Ich muss dabei an die Zeit denken, als die oberen drei Reihen auf dem iPhone-Home-Bildschirm bei allen ähnlich waren, die unterste Reihe aber bei jedem ganz anders aussah. Ich habe das Gefühl, dass IT-Abteilungen und Entwicklerteams auch in Zukunft weiter ihre jeweils eigenen MCP-Server für ihre konkreten Arbeitsabläufe bauen werden