MCP in der Softwareentwicklung: Kontrollierter Zugriff für AI-Agents

Die meisten Diskussionen über agentische Entwicklung drehen sich um Modelle. Die praktisch schwierigere Frage ist eine andere: Worauf darf der Agent zugreifen – und wer entscheidet das? Ohne Antwort darauf entsteht entweder ein Assistent, der zu wenig weiß, um zu helfen, oder ein Prozess, in dem ein Werkzeug mehr darf als die meisten Mitarbeitenden.

1. Was MCP ist – und was nicht

Das Model Context Protocol (MCP) ist ein offenes Protokoll, das beschreibt, wie eine KI-Anwendung mit externen Systemen spricht: Datenquellen, Werkzeuge, Dienste. Es wurde von Anthropic veröffentlicht und wird als offene Spezifikation gepflegt; die Nachrichten folgen JSON-RPC 2.0.

Der Nutzen ist zunächst ein sehr unspektakulärer: Standardisierung. Ohne ein solches Protokoll bekommt jede Kombination aus KI-Werkzeug und System ihre eigene Integration – und damit ihre eigene Rechteverwaltung, ihre eigenen Fehlerfälle und ihre eigene Wartung. Mit MCP beschreibt ein System seine Fähigkeiten einmal, und unterschiedliche Clients können sie nutzen.

Ebenso wichtig ist, was MCP nicht ist:

• Kein Sicherheitsmodell für Ihre Systeme. Das Protokoll regelt die Kommunikation, nicht die Frage, welche Rechte ein Zugang haben sollte. Diese Entscheidung bleibt bei Ihnen.
• Keine Garantie für sinnvolles Verhalten. Ein Agent kann eine angebotene Fähigkeit falsch, zu früh oder im falschen Kontext aufrufen.
• Kein Ersatz für eine API. Ein MCP-Server ist in aller Regel eine zusätzliche, für Agents zugeschnittene Fassade vor einer bestehenden Schnittstelle – nicht deren Ersatz.

2. Tools, Ressourcen, Prompts

Ein MCP-Server bietet seine Fähigkeiten in klar getrennten Kategorien an. Die Unterscheidung wirkt formal, entscheidet aber darüber, wer eine Aktion auslöst – und ist deshalb der wichtigste Teil des Protokolls für die Architektur:

Die praktische Konsequenz: Was nur gelesen werden muss, gehört nicht in ein Tool. Ein Schema, das als Ressource bereitsteht, ist Kontext. Dasselbe Schema hinter einem Tool ist eine Aktion, die das Modell selbstständig auslösen kann – mit allem, was daran an Prüf- und Protokollierungsbedarf hängt.

Ergänzend definiert das Protokoll Fähigkeiten auf Client-Seite, unter anderem die Möglichkeit, dem Server einen begrenzten Arbeitsbereich mitzuteilen und Anfragen des Servers an das Modell oder an den Nutzer zurückzuspiegeln. Welche davon ein konkreter Client unterstützt, unterscheidet sich – das ist beim Entwurf eines Servers früh zu klären.

3. Host, Client, Server: die Rollenverteilung

Die Architektur ist bewusst einfach gehalten:

• Host – die KI-Anwendung, in der gearbeitet wird: eine Coding-Umgebung, ein Editor-Plugin, ein Terminal-Agent.
• Client – im Host enthalten, hält je eine Verbindung zu genau einem Server und verwaltet deren Zustand.
• Server – stellt die Fähigkeiten eines Systems bereit: Repository, Ticketsystem, Datenbank, Entwicklungsplattform.

Sicherheitsrelevant ist vor allem die Stellung des Hosts. Er ist die einzige Instanz, die alle Verbindungen gleichzeitig sieht, und damit die einzige, die eine Freigabe sinnvoll einholen kann. Ein Server weiß nicht, welche anderen Server im Spiel sind – und darf das auch nicht voraussetzen.

4. Transport und Betriebsmodell

Für die Übertragung sind zwei Wege verbreitet: ein lokaler Prozess, der über Standardein- und -ausgabe angebunden wird, und eine HTTP-basierte Anbindung für entfernte Server. Der Unterschied ist keine Geschmacksfrage, sondern bestimmt das gesamte Rechtemodell:

• Lokal: Der Server läuft als Prozess unter dem Konto der Person, die ihn startet – und erbt damit deren Rechte, inklusive Dateisystem und lokal hinterlegter Zugangsdaten. Bequem, aber selten fein abgestuft.
• Entfernt: Der Zugriff läuft über eine authentifizierte Verbindung. Für diesen Fall beschreibt die Spezifikation ein Autorisierungs­modell auf OAuth-Basis; damit lassen sich Identität, Geltungsbereich und Widerruf sauber trennen.

Für Unternehmen mit eigener Infrastruktur ist der zweite Weg meist der einzig tragfähige – nicht wegen des Protokolls, sondern weil erst dort eine nachvollziehbare Rechtevergabe möglich wird. Das Protokoll entwickelt sich weiter und wird über Datumsstände versioniert; welcher Stand für Ihre Werkzeugkette gilt, gehört in die Entscheidungsdokumentation.

5. Berechtigungsgrenzen: die eigentliche Entwurfsarbeit

Der häufigste Entwurfsfehler besteht darin, einem MCP-Server dieselben Rechte zu geben wie einem Administrator – „damit es funktioniert“. Damit wird das Werkzeug zur Umgehung des eigenen Berechtigungskonzepts.

Ein belastbarer Zuschnitt beantwortet vier Fragen:

1. In wessen Namen handelt der Server? Ein technischer Sammelzugang macht jede spätere Zuordnung unmöglich. Besser ist eine Identität, die auf die handelnde Person zurückführt.
2. Welcher Ausschnitt ist erreichbar? Ein Projekt, ein Mandant, ein Repository – nicht „alles, was der Dienst kann“.
3. Welche Aktionen sind schreibend? Lesen und Schreiben gehören getrennt. Ein Großteil des Nutzens entsteht bereits im Lesemodus.
4. Was ist irreversibel? Löschen, Deployen, Freigeben, Rechte vergeben: Solche Aktionen gehören entweder gar nicht in die Werkzeugliste oder hinter eine ausdrückliche menschliche Freigabe.

Eine bewährte Faustregel: Der Agent bekommt die Rechte einer neuen Person im Team am ersten Tag – ausreichend, um zu arbeiten, ohne Zugriff auf Produktion, Geheimnisse und Rechteverwaltung. Wie sich das in eine unternehmensweite Regelung übersetzt, beschreibt der Deep Dive AI Coding Governance.

6. MCP im Entwicklungsworkflow

Konkret wird der Nutzen dort, wo ein Agent gegen definierte Plattformfähigkeiten arbeitet statt gegen eine leere Datei. Ein typischer Ablauf in der Backend-Entwicklung:

1. Das AI-Coding-Tool erzeugt Frontend-Code gegen eine bekannte Schnittstelle.
2. Über den MCP-Server werden Datenmodelle, Relationen, Rollen und Rechte sowie Validierungen definiert – nicht als Textdatei, sondern als explizites Modell.
3. Das Ergebnis wird visuell geprüft und dort korrigiert, wo die fachliche Entscheidung beim Menschen liegt.
4. Aus der geprüften Projektdefinition entstehen Build, Container-Image und Deployment über die eigene CI/CD.
5. Die generierte OpenAPI-Dokumentation schließt den Kreis: Sie ist präziser Integrationskontext für Frontend und AI-Werkzeuge gleichermaßen.

Der Unterschied zu „Agent schreibt Backend-Code“ ist grundlegend. Was über definierte Fähigkeiten entsteht, bleibt prüfbar, vergleichbar und wiederholbar. Wie CodamAI diesen Ablauf abbildet, steht auf der Feature-Seite.

7. Wo zu breite Rechte kippen

Die relevanten Risiken agentischer Werkzeugketten entstehen selten durch einen einzelnen Fehler, sondern durch eine ungünstige Kombination. Drei Muster sollte jedes Team kennen:

Indirekte Prompt Injection

Alles, was ein Agent liest – Ticketbeschreibungen, Code-Kommentare, Fehlermeldungen, Webseiten, Werkzeugergebnisse –, kann Anweisungen enthalten. Modelle unterscheiden Inhalt und Anweisung nicht zuverlässig. Ergebnisse aus Werkzeugen sind deshalb Daten, nicht Befehle, und ihre Vertrauenswürdigkeit hängt an der Quelle.

Die gefährliche Kombination

Kritisch wird es, wenn drei Eigenschaften zusammenkommen: Zugriff auf vertrauliche Daten, Verarbeitung nicht vertrauenswürdiger Inhalte und die Möglichkeit, nach außen zu kommunizieren (Netzwerkzugriff, Pull Request, Nachricht, Commit in ein fremdes Repository). Fehlt eines der drei Elemente, bleibt der Schaden begrenzt. Genau darauf sollte der Zuschnitt der Werkzeuge zielen.

Veränderliche Werkzeugbeschreibungen

Ein Server kann seine Werkzeugliste und deren Beschreibungen ändern, nachdem ein Nutzer ihn einmal freigegeben hat. Deshalb gilt: Server aus vertrauenswürdiger Quelle beziehen, Versionen festschreiben und Änderungen an der Werkzeugliste wie eine Abhängigkeitsänderung behandeln – also prüfen und freigeben.

8. Human-in-the-loop richtig platzieren

Freigaben wirken nur, solange sie gelesen werden. Ein Client, der bei jedem Lesezugriff nachfragt, erzieht Nutzer innerhalb eines Vormittags zum reflexhaften Bestätigen – und entwertet damit genau die Rückfrage, auf die es ankommt.

Sinnvoll gestufte Praxis:

• Lesend im freigegebenen Ausschnitt: ohne Rückfrage.
• Schreibend, umkehrbar: einmalige Freigabe pro Sitzung oder Werkzeug, mit sichtbarem Protokoll.
• Irreversibel oder außenwirksam: jedes Mal einzeln bestätigen – mit Anzeige der konkreten Parameter, nicht nur des Werkzeugnamens.
• Rechte- und Produktionsänderungen: gar nicht als Werkzeug anbieten.

Die Freigabe ersetzt keine Prüfung des Ergebnisses. Was ein Agent über MCP erzeugt, durchläuft dieselben Quality Gates und Reviews wie handgeschriebener Code.

9. Beispielarchitektur

Das folgende Muster hat sich für Teams bewährt, die agentische Entwicklung kontrolliert einführen wollen. Es ist eine Illustration, keine Produktkonfiguration:

Die zugehörige Client-Konfiguration bleibt bewusst schmal. Entscheidend sind der begrenzte Geltungsbereich und die Herkunft der Zugangsdaten aus der Umgebung statt aus der Datei:

{
  "mcpServers": {
    "project-platform": {
      "command": "<server-binary>",
      "args": ["--project", "erp-2026", "--env", "staging"],
      "env": { "PLATFORM_TOKEN": "${PLATFORM_TOKEN}" }
    },
    "project-context": {
      "command": "<server-binary>",
      "args": ["--repo", "erp-2026", "--read-only"]
    }
  }
}

Aufbau und verfügbare Optionen unterscheiden sich je nach Client und Server; das Beispiel zeigt das Prinzip, nicht eine konkrete Schnittstelle.

10. Trade-offs und Grenzen

• Kontextkosten. Jedes angebotene Werkzeug belegt Platz im Kontext und erhöht die Wahrscheinlichkeit einer Fehlauswahl. Zwölf präzise Werkzeuge schlagen sechzig generische.
• Zusätzliche Betriebsfläche. Ein MCP-Server ist Software, die betrieben, aktualisiert und überwacht werden muss – inklusive Abhängigkeitspflege.
• Nichtdeterminismus bleibt. Das Protokoll macht Aufrufe nachvollziehbar, nicht vorhersagbar. Wiederholbarkeit entsteht erst durch das geprüfte Artefakt.
• Reife der Clients. Nicht jeder Client unterstützt jede Fähigkeit oder jedes Freigabemodell. Das gehört vor der Einführung getestet, nicht danach.

Typische Fehler

• Administrativer Sammelzugang für den Server, weil es schneller geht.
• Alles als Tool anbieten, auch reine Leseoperationen.
• Server aus unbekannter Quelle ohne Versionsfestlegung einbinden.
• Freigabedialoge trainieren statt gestalten – zu viele Rückfragen erzeugen Blindbestätigung.
• Produktionszugriff über den Agent, statt über die Pipeline.
• Keine serverseitige Protokollierung, dadurch keine spätere Auskunftsfähigkeit.

Checkliste: MCP kontrolliert einführen

Fazit

MCP ist keine Beschleunigungstechnologie, sondern eine Strukturentscheidung. Es ersetzt die Frage „Wie bringe ich mein System an das KI-Werkzeug?“ durch die deutlich bessere Frage: „Welche Fähigkeiten will ich einem Agent ausdrücklich geben – und welche nicht?“

Teams, die diese Frage sauber beantworten, bekommen einen Agent, der mit den richtigen Informationen arbeitet und dessen Handlungen nachvollziehbar bleiben. Teams, die sie überspringen, bekommen einen Zugang, den niemand mehr vollständig beschreiben kann. Der Aufwand für den Unterschied liegt bei wenigen Tagen Entwurfsarbeit – der Unterschied selbst ist erheblich.