Systems Design Meditation · Edition 2
Nach den APIs
Warum MCP eine neue Infrastrukturschicht signalisiert
Edward Calderón
Softwarearchitekt
APIs haben Software miteinander verbunden. Agenten bringen Software mit, die entscheiden muss, mit welcher Software sie sich verbinden soll.
Eine klassische Integration beginnt mit Wissen: Der Entwickler wählt einen Endpunkt aus, studiert dessen Schema und schreibt deterministischen Code rund um diesen Endpunkt. Der Aufrufer kennt den Dienst und meist auch die Operation. Agentische Software ändert diese Annahme. Sie muss möglicherweise Fähigkeiten entdecken, ihre Beschreibungen verstehen, zwischen ihnen wählen und Kontext über die Grenze hinweg transportieren.
Vom Aufruf zur Discovery
REST, RPC und Event-Streams bleiben unverzichtbar. MCP macht sie nicht überflüssig. Es adressiert eine andere Schicht: Tools, Ressourcen und Prompts über eine gemeinsame Schnittstelle modellgetriebenen Clients bereitzustellen. Die zugrunde liegende Operation kann weiterhin ein API-Aufruf, eine Datenbankabfrage oder ein lokaler Prozess sein.
Diese Unterscheidung ist wichtig. Discovery ist nicht bloß ein komfortableres SDK. Eine Maschine, die eine Fähigkeit auswählt, braucht Namen und Beschreibungen, die korrektes Schlussfolgern ermöglichen, Schemas, die Eingaben einschränken, und explizite Sicherheitsgrenzen. Eine mehrdeutige Tool-Beschreibung ist ein Architekturfehler, weil sie das Auswahlverhalten verändert.
Die MCP-Spezifikation definiert eine Client-Host-Server-Architektur und die Aushandlung von Fähigkeiten. Sie warnt Implementierer zudem, Zustimmung, Datenschutz und Tool-Sicherheit zu bewahren. Das sind Hinweise auf die neue Schicht: Der Austausch von Kontext lässt sich nicht von der Autorität trennen.
Was mich interessiert, ist nicht, ob MCP zum endgültigen Protokoll wird. Es ist die Tatsache, dass die Interaktion zwischen Agenten und Systemen wichtig genug geworden ist, um überhaupt eine Protokollschicht zu erfordern. Das Protokoll mag sich ändern. Der Bedarf bleibt.
Die Control Plane rund um Tools
Ein nützliches Ökosystem an Agenten-Tools braucht mehr als einen Katalog. Es braucht Lebenszyklus und Governance. Wer hat ein Tool registriert? Welche Version ist aktiv? Welcher Mandant kann es sehen? Impliziert Discovery eine Berechtigung oder nur Kenntnis? Wie werden Ergebnisse als nicht vertrauenswürdig markiert? Was passiert, wenn ein Server mitten in einem Workflow verschwindet?
Das sind Fragen verteilter Systeme. Dienste fallen unabhängig voneinander aus. Schemas entwickeln sich weiter. Wiederholungsversuche können Seiteneffekte duplizieren. Der Agent hält möglicherweise veralteten Kontext. Ein Tool-Aufruf, der für das Modell atomar erscheint, kann sich darunter über mehrere nicht-atomare Operationen erstrecken.
Stellen Sie sich einen Operations-Agenten vor, der zwischen Tools zum Auslesen von Telemetriedaten, zum Anlegen eines Incidents und zum Ändern der Kapazität wählt. Discovery sollte alle drei Fähigkeiten offenlegen, doch die Autorisierung sollte nicht einheitlich sein. Der Lesezugriff darf breit gefasst sein. Das Anlegen eines Incidents sollte idempotent sein. Kapazitätsänderungen sollten strengere Richtlinien erfordern und auf einen begrenzten Rahmen festgelegt sein. Ein gemeinsames Protokoll hilft, die Schnittstelle zu beschreiben; die Plattform muss die Grenze aber weiterhin durchsetzen.
Herstellergrenzen machen das noch wichtiger. Organisationen werden mehrere Modellanbieter und Hunderte interner und externer Dienste nutzen. Maßgeschneiderte Adapter erzeugen Kopplung in beide Richtungen. Eine Protokollschicht kann einem Tool erlauben, sich weiterzuentwickeln, ohne dass jeder Client seine private Integration erlernen muss, und einem Client erlauben, sich zu ändern, ohne dass jeder Dienst neu geschrieben werden muss.
Standardisierung ohne Mythologie
Wichtige Ökosysteme beschleunigen sich oft, wenn Schnittstellen vorhersehbar werden. Aber Analogien können mehr verbergen, als sie erklären. MCP ist nicht einfach „das neue HTTP“. HTTP transportiert Repräsentationen zwischen vernetzten Komponenten. MCP definiert Konventionen für Kontext und Fähigkeiten, die sich an Modelle richten, und setzt dabei in der Regel auf bestehende Transporte auf.
Die nützliche architektonische Aussage ist enger gefasst. Standardisierte Schnittstellen verringern die Anzahl bilateraler Vereinbarungen, die für die Zusammenarbeit von Komponenten nötig sind. Sie schaffen Raum für Tooling: Registries, Gateways, Policy-Engines, Test-Harnesses und Observability. Sie machen Fehler zudem vergleichbar.
Standardisierung schafft nicht automatisch Interoperabilität. Zwei Server können dasselbe Protokoll implementieren und dabei inkompatible Semantiken verwenden. Ein Tool namens `search` kann die Dokumente eines Kunden, das öffentliche Web oder eine operative Datenbank durchsuchen. Semantische Qualität, Herkunft und Vertrauen bleiben Angelegenheiten des Gesamtsystems.
Das legt einen mehrschichtigen Entwurf nahe. Nutzen Sie Protokolle für Discovery und Austausch. Nutzen Sie Identität und Richtlinien für die Autorisierung. Nutzen Sie Domänenverträge für Bedeutung. Nutzen Sie Tracing und Audit-Aufzeichnungen für die Rechenschaftspflicht. Nutzen Sie gewöhnliche APIs und Warteschlangen für eine zuverlässige Ausführung. Keine einzelne Schicht sollte so tun, als löse sie die Probleme der anderen.
Für Entwickler liegt der unmittelbare Wert von MCP also nicht in einem Versprechen von Universalität. Er liegt in einem praktischen Druck, Modell-Clients von Tool-Implementierungen zu entkoppeln. Das macht Experimente günstiger und Ersetzungen leichter umkehrbar.
Protokolle zählen, weil sie es Systemen erlauben, sich unabhängig voneinander weiterzuentwickeln.