MCP wird oft als Plumbing beschrieben, mit dem ein Modell Tools aufrufen kann. Technisch stimmt das. Architektonisch ist es unvollständig.
Sobald ein Agent ein Repository untersuchen, einen Service abfragen, ein Artefakt verändern oder einen Workflow ausführen kann, wird die Integration zu einer operativen Grenze. Das Designproblem ähnelt nun stärker API- und Security-Architektur als Prompt Engineering.
Capability ist die Einheit des Designs
Beginne nicht mit „Womit kann sich der Agent verbinden?“. Beginne mit „Welche Fähigkeit braucht diese Aufgabe?“.
Eine Capability sollte eng genug sein, dass sich klar benennen lässt:
- was der Agent lesen darf;
- was er verändern darf;
- welche Eingaben akzeptiert werden;
- welche Evidenz zurückkommt;
- was einen eigenen Freigabeschritt erfordert.
Das reduziert Mehrdeutigkeit für das Modell und macht das System für Menschen leichter auditierbar.
Lese- und Schreibpfade sollten sich unterschiedlich anfühlen
Inspektion ist billig. Mutation ist teuer.
Ein repository-bewusster Agent kann breiten Lesezugriff benötigen, um Architektur zu verstehen, und trotzdem nur eng begrenzte Schreibaktionen erhalten. Dasselbe Prinzip gilt für Infrastruktur, Datenbanken und externe APIs.
Wenn ein Tool Beobachtung und Mutation hinter einer vagen Aktion zusammenfasst, geht eine wertvolle Sicherheitsgrenze verloren und Debugging wird schwieriger.
Tool-Output ist Evidenz
Der Output eines Tool-Aufrufs sollte als strukturierte Evidenz behandelt werden, die eine spätere Stufe des Workflows prüfen kann.
Das bedeutet: Tool-Antworten müssen vorhersehbar genug sein, um sie zu konsumieren, zu protokollieren und zu vergleichen. Ein Validierungs-Agent sollte nachvollziehen können, was passiert ist, ohne von der Prosa-Zusammenfassung des Implementierungs-Agenten abhängig zu sein.
Die Architekturregel
Entwirf MCP-Tools so, wie du eine interne Produktions-API entwerfen würdest: kleine Oberfläche, explizite Semantik, Least Privilege und beobachtbare Ergebnisse.
Das Modell ist neu. Die Disziplin an der Schnittstelle ist es nicht.