Das Model Context Protocol, erklärt für Entwickler
Jedes Team, das mehr als einen Agenten baut, schreibt denselben Adapter zweimal: mit einem System verbinden, beschreiben, was es kann, und diese Fähigkeiten dem Modell in der Form anbieten, die der heutige Client erwartet. Das Model Context Protocol soll diese Doppelarbeit beenden, indem es die Schnittstelle zwischen Agent-Client und Werkzeugserver standardisiert.
Das ist wirklich nützlich und zugleich enger, als die Begeisterung nahelegt. MCP beschreibt, wie Fähigkeiten angekündigt und aufgerufen werden. Es entscheidet nicht, wer sie aufrufen darf — und diese Verwechslung ist die Quelle der Sicherheitsvorfälle.
Was das Protokoll standardisiert#
- Discovery: Der Server nennt dem Client seine Werkzeuge und Ressourcen samt Schemata.
- Aufruf: Der Client ruft ein Werkzeug mit typisierten Argumenten auf und erhält ein strukturiertes Ergebnis.
- Ressourcen: Nur-Lese-Inhalte, die der Client bei Bedarf in den Kontext zieht.
- Transport: ein gemeinsames Format, damit Client und Server verschiedener Herkunft zusammenarbeiten.
Was es bewusst nicht tut#
MCP authentifiziert Ihre Nutzer nicht, entscheidet nicht, welche Datensätze wer lesen darf, und nicht, ob eine Handlung Freigabe braucht. Das bleibt bei Ihnen und muss serverseitig leben — ein Client, der höflich um Erlaubnis bittet, ist kein Berechtigungssystem. Der häufigste Fehler ist, ein breites Werkzeug wie `run_query` über MCP anzubieten und darauf zu vertrauen, dass der Prompt es im Rahmen hält.
Behandeln Sie jedes MCP-Werkzeug so, als riefe es früher oder später ein verwirrter oder manipulierter Aufrufer mit den schlimmsten plausiblen Argumenten auf.
Wo es sich heute lohnt#
| Situation | Nutzen von MCP |
|---|---|
| Ein internes System, mehrere Agent-Clients | Hoch — Server einmal schreiben |
| Desktop-Assistenten mit lokalem Kontext | Hoch — das Ökosystem ist darauf gebaut |
| Ein Agent mit drei eigenen Werkzeugen | Gering — direkte Funktionsaufrufe sind einfacher |
| Fremde Werkzeuge, die Sie nicht kontrollieren | Mittel — praktisch, aber prüfen Sie den Server |
Sicher einführen#
- Enge Fähigkeiten kapseln statt allgemeiner Macht: `get_order(id)` statt `sql(query)`.
- Autorisierung im Server erzwingen, pro Aufruf, mit der Identität des Endnutzers statt eines Allmachts-Servicekontos.
- Ehrliche, kurze Fehler zurückgeben — `nicht gefunden`, `nicht erlaubt` — damit der Agent sinnvoll reagiert.
- Jeden Aufruf mit Argumenten und Aufruferidentität protokollieren; das ist Ihr Audit-Trail.
- Genutzte Server auf geprüfte Versionen pinnen, wie jede andere Abhängigkeit.
Die Lieferketten-Frage#
Ein fremder MCP-Server ist Code, der Ihrem Agenten Werkzeuge beschreibt und die Argumente empfängt, die Ihr Agent zu senden beschließt. Werkzeugbeschreibungen sind Teil des Modellkontexts — eine bösartige oder schlampige Beschreibung kann Verhalten beeinflussen. Prüfen Sie Server vor der Einführung, bevorzugen Sie lesbare, und halten Sie ungeprüfte Server fern von Clients mit Zugriff auf sensible Systeme. Gewöhnliche Abhängigkeitshygiene, angewandt auf eine neue Art von Abhängigkeit.
Häufige Fragen
Brauche ich MCP, um einen Agenten zu bauen?
Nein. Für einen Agenten mit einer Handvoll eigener Werkzeuge sind direkte Funktionsaufrufe einfacher. MCP zahlt sich aus, wenn dieselbe Fähigkeit mehrere Clients bedienen soll oder Sie Werkzeuge anderer Teams konsumieren wollen.
Ist MCP standardmäßig sicher?
Es ist ein Transport- und Discovery-Standard, kein Sicherheitsmodell. Authentifizierung, nutzerbezogene Autorisierung und Freigabetore implementieren Sie serverseitig — und delegieren sie niemals an den Prompt.
Können MCP-Server ein Injection-Vektor sein?
Ja — über Werkzeugbeschreibungen im Modellkontext und über zurückgegebene Inhalte. Behandeln Sie Serverausgaben als nicht vertrauenswürdig, halten Sie Werkzeugbereiche eng und richten Sie keinen schreibberechtigten Agenten auf ungeprüfte Server.
model context protocolmcp erklärtagenten werkzeugstandardmcp sicherheittool discovery
