Agenten und Kontrolle /
Der Agent ist verbunden. Was darf der nächste Werkzeugaufruf?
Ein Programmieragent liest eine Datei, startet einen Test und ändert anschließend einen Eintrag in einem anderen System. Auf dem Bildschirm erscheint das als ein Arbeitsgang. Hinter jedem Werkzeugaufruf steht jedoch eine eigene Entscheidung darüber, welcher Zugriff erlaubt ist. Der am 2026-09-25 zusammengeführte Entwurf für MCP over ACP gibt diesen einzelnen Anfragen mehr Gewicht: Jede bringt ihren Kontext mit, statt ihn aus einer vorherigen Anfrage zu übernehmen.
Eine freigegebene Verbindung beantwortet noch nicht, ob der nächste Werkzeugaufruf auf dieselben Daten zugreifen darf.
Ein Weg für Gespräch und Werkzeuge
ACP regelt den Austausch zwischen einem Editor und einem Programmieragenten; MCP erschließt dem Agenten Werkzeuge und Datenquellen. Die Begründung des Vorschlags setzt bei Editoren an, die eigene Projektwerkzeuge über einen zusätzlichen HTTP-Endpunkt oder Unterprozess anbieten. Der Vorschlag lässt diese Aufrufe über die vorhandene ACP-Verbindung laufen. Eine serverId bezeichnet das Werkzeugangebot, eine requestId die einzelne logische Anfrage. Auch Rückmeldungen zum Fortschritt gehören zu genau dieser Anfrage. Eine verspätete Meldung darf deshalb nicht bei einer anderen Operation landen.
Der Kontext reist mit jeder Anfrage
Der Entwurf verlangt pro Operation die MCP-Version, die Fähigkeiten des Aufrufers und weiteren Anfragekontext. Der Anbieter muss diesen Kontext auch beim Auflisten und Ausführen der Werkzeuge berücksichtigen. Für die Anmeldung bleibt eine Grenze ausdrücklich stehen: Serverkennung und Anfragekennung dienen der Zuordnung, die vom Client selbst gemeldeten Angaben beweisen keine Identität. Daraus folgt für ein Team, das solche Werkzeuge anbietet, eine konkrete Prüfaufgabe: Es muss den Aufrufer an eine tatsächlich geprüfte Identität binden und dessen Zugriff vor der Ausführung begrenzen. Ein plausibel ausgefülltes Nachrichtenfeld erledigt diese Arbeit nicht.
Abbrechen hat eine zeitliche Grenze
Der Abbruch gehört zur einzelnen Anfrage und erfolgt laut Entwurf nach bestem Bemühen; eine Operation kann normal enden, wenn sie bereits fertig ist oder sich nicht mehr abbrechen lässt. Bereits ausgelöste Änderungen in anderen Systemen bleiben bestehen. Für einen interaktiven Aufruf, der weitere Eingaben braucht, sieht der Entwurf eine neue Anfrage mit frischer Kennung vor. Die Transportschicht darf dabei weder eine Rückfrage selbst genehmigen noch einen Aufruf mit Nebenwirkungen ohne die Vorgaben des Agenten wiederholen. Bei einem Werkzeug, das etwa ein Ticket anlegt, wäre eine automatische Wiederholung nach einem Verbindungsproblem sonst ein möglicher Weg zum doppelten Ticket.
Entwurf und SDK liegen auseinander
MCP over ACP ist weiterhin als Draft gekennzeichnet und richtet sich ausschließlich an MCP 2026-07-28. Der Änderungsverlauf belegt die Umstellung am 2026-09-25, keinen fertigen Produktstart. In der am 2026-09-28 gelesenen Dokumentation des offiziellen Rust SDK stehen dagegen noch mcp/connect und mcp/disconnect samt einer eigenen Verbindungskennung. Diese ältere Form ersetzt der neue Vorschlag ausdrücklich; die zugehörige Umsetzung liegt als offener Entwurf in Rust-Pull-Request 376. Vor einer Integration müssen Teams deshalb den verwendeten SDK-Stand mit der gewünschten Protokollfassung abgleichen. Ein vorhandener HTTP-Anschluss genügt als Nachweis der passenden MCP-Unterstützung ebenfalls nicht.
Ein begrenzter Versuch für den eigenen Betrieb
Als erster eigener Test bietet sich ein Werkzeug an, das ausschließlich in einen wegwerfbaren Testbestand schreibt. Zwei Aufrufer erhalten unterschiedliche Rechte. Der Versuch prüft, ob beide dieselbe Werkzeugliste sehen, ob ein verbotener Aufruf tatsächlich scheitert und ob eine verspätete Fortschrittsmeldung sauber zugeordnet bleibt. Danach folgt ein Abbruch während einer laufenden Anfrage, während eine zweite weiterarbeitet. Im Protokoll sollten Abbruchanforderung, tatsächliches Ende und bereits ausgeführte Änderung getrennt stehen. Das ist ein vorgeschlagener Prüfumfang, kein hier durchgeführter Test. Eine Zusage zur Sicherheit einer konkreten Implementierung lässt sich aus dieser Quellenprüfung nicht ableiten. Nach einem unterbrochenen Schreibaufruf muss der Test den Zielbestand auslesen, bevor er denselben Auftrag erneut schickt.
QUELLEN UND STAND / GEPRÜFT 2026-09-28
MATHIAS HEINKE