Lass andere doch die Arbeit machen – wie man MCPs erstellt und dadurch geschickt Dienste miteinander verbindet

Von der Spielerei zum agentenbasierten Werkzeug

LLMs bzw. KI sind heute aus dem privaten wie geschäftlichen Umfeld nicht mehr wegzudenken. Kaum eine Technologie hat sich in den letzten Jahren so schnell und so disruptiv entwickelt wie die künstliche Intelligenz. Waren ChatBots anfangs noch ein Spielzeug für Nerds oder schlecht gemachte Supportassistenten auf Websites, hat KI als Werkzeug bzw. haben damit generierte Inhalte längst den Alltag erreicht: Verkehrsmeldungen im Radio werden von einer KI-Stimme vorgelesen, klassische Suchanfragen lassen sich endlich natürlichsprachlich formulieren, und so manche schulische Leistung bekommt (nicht ganz legal) einen Boost durch KI.

Auch im geschäftlichen Umfeld ist die Reise vom simplen ChatBot schon längst weitergegangen. Es geht nicht mehr nur darum, Fragen oder Suchbegriffe in ein Chat-Interface einzutippen. Heute geht es vor allem darum, verschiedene Dienste über ihre Schnittstellen miteinander zu verknüpfen und gemeinsam Aufgaben erledigen zu lassen. Die beiden größten Anbieter, OpenAI und Anthropic, bauen ihre Clients immer weiter in Richtung agentenbasierter Tools um: So kann man sich seine nächsten Termine genauso anzeigen lassen, wie einen Auftrag erteilen oder den Download-Ordner automatisch aufräumen lassen. Und damit eine KI mit anderen Diensten, Tools und Datenquellen einfach und einheitlich kommunizieren kann, hat die Firma Anthropic Ende 2024 das Model Context Protocol (MCP) vorgestellt. MCP ist dabei ein offener Standard und es gibt viele SDKs, um die Funktionalität in diversen Programmiersprachen zu realisieren.

Abbildung 1: Gute Tools liefern nicht nur Daten – Sie machen den nächsten Schritt

Das Wetter-Beispiel: einfach ist nicht dasselbe wie fertig

Bei let's dev haben wir deshalb schon früh damit angefangen, unsere eigenen und fremden Dienste durch MCPs miteinander zu verknüpfen und an LLMs anzubinden (übrigens bauen wir unsere eigenen Lösungen immer so auf, dass sie Datensouveränskriterien vom EU AI Act erfüllen). Und so verlockend das Versprechen von MCP ist, Dienste und Tools einfach miteinander zu verknüpfen, so liegt natürlich auch hier wieder der Teufel im Detail.

Zugegebenermaßen ist es erstmal wirklich ziemlich einfach, eine erste Version eines solchen Servers herzustellen. Nehmen wir zum Beispiel an, man möchte dem Chatclient seiner Wahl beibringen, den aktuellen Wetterbericht für einen bestimmten Standort abzufragen. Dafür kann man sich als Dienst z. B. OpenWeatherMap aussuchen. Der Dienst bietet eine API an, die genau das erbringt, was wir nutzen wollen. Allerdings erwartet der „normale“ API-Call bei OpenWeatherMap, dass man den Standort in Form von WGS-84-konformen Koordinaten angibt. Wenn man jetzt also nicht zufällig die Koordinaten seiner Liebslings- oder Urlaubsorte auswendig kennt, braucht man noch einen weiteren Aufruf, der einen Städtenamen in Koordinaten wandelt. Und schon braucht man einen zweiten MCP, der einen entsprechenden Geocodingdienst bereitstellt. Außerdem muss man bei der Definition der MCP-konformen Protokolle darauf achten, dass das aufrufende LLM versteht, wie man die Dienste miteinander kombiniert. Ein einfaches „stellt Wetterdaten zu einem Standort bereit“ und „wandelt Städtenamen in Standortdaten“ reicht dazu nicht aus. Vor allem dann nicht, wenn man bedenkt, dass die Antwort auf die Frage „Wie ist der Standort von Neustadt?“ nicht eindeutig ist, sondern eine Liste mit mehr als einem Dutzend Einträgen. Ohne weitere Präzisierung gibt es hier also keine gute Lösung. Klar, ein ChatBot stellt einem sicherlich die Rückfrage, welche Neustadt denn nun genau gemeint sei. Aber wollten wir nicht genau diese Rückfragen durch Automatisierung umgehen?

Genau hier fängt es jetzt an, spannend zu werden: Damit eine KI bzw. agentic AI wirklich Nutzen aus anderen Diensten und deren Verknüpfung ziehen kann, muss man sich beim Design der MCP-Schnittstellen Gedanken machen. Auch wir haben dabei die Erfahrung gemacht, dass das durchaus mehr ist, als „einfach nur“ die API zu wrappen.

Werkzeug statt Wrapper

MCPs sollten nicht als dünne API-Wrapper gedacht werden, sondern als agententaugliche Arbeitswerkzeuge. Wer nur stumpf Endpoints exponiert, bekommt Tools – keine dynamischen, intelligenten Arbeitswerkzeuge. Nur wer zusätzlich Rolle, Einsatzzeitpunkt und Ergebnissemantik gestaltet, bekommt auch eine brauchbare Zusammenarbeit zwischen den Tools. Und genau darauf kommt es uns am Ende an: Wir formulieren zwar die Aufgabe, also das „Was“ – die eigentliche Erledigung, das „Wie“, sollen die Tools aber selbst herausfinden und untereinander aushandeln.

Warum das Schreiben eines guten MCPs schwerer ist, als es aussieht

Genau an dieser Stelle unterschätzen viele Teams den Aufwand. Ein MCP-Server, der nur einen Endpoint 1:1 durchreicht, ist in wenigen Stunden gebaut – und genau das macht die Sache tückisch. Er sieht fertig aus, funktioniert im ersten Test auch scheinbar problemlos, und trotzdem fällt er in der Praxis später auseinander, sobald ein Agent ihn wirklich eigenständig einsetzt.

Ein paar der Schwierigkeiten, die uns dabei immer wieder begegnen:

Semantik statt Syntax. Ein Tool-Schema, das syntaktisch korrekt ist, sagt einem LLM noch lange nicht, wann es eingesetzt werden soll und wann nicht. Zwei Tools, die sich in ihrer Beschreibung zu ähnlich sind, führen dazu, dass ein Agent das falsche wählt oder beide durcheinander wirft – ein Problem, das sich erst zeigt, wenn man den Server tatsächlich mit einem echten Agenten und realistischen Aufgaben testet, nicht beim isolierten Unit-Test einer einzelnen Funktion.

Fehlerfälle sind der eigentliche Designraum. Der Glückspfad eines Tools ist meistens schnell geschrieben. Die eigentliche Arbeit steckt darin, was passiert, wenn eine Anfrage mehrdeutig ist, ein externer Dienst nicht antwortet oder ein Ergebnis unvollständig bleibt. Soll das Tool dann einen Fehler werfen, eine leere Antwort liefern oder von sich aus nachfragen? Jede dieser Entscheidungen verändert grundlegend, wie gut ein Agent mit dem Tool umgehen kann – und lässt sich nicht nachträglich draufsetzen, ohne die Schnittstelle noch einmal neu zu denken.

Sicherheits- und Vertrauensgrenzen. Sobald ein MCP nicht nur Daten liefert, sondern selbst Inhalte von außen entgegennimmt oder verarbeitet – eine URL, ein Dokument, eine E-Mail – verschiebt sich die Vertrauensgrenze. Wer garantiert, dass ein Agent nicht versehentlich unsichere Inhalte weiterverarbeitet, oder dass in einem Dokument versteckte Anweisungen den Agenten selbst manipulieren? Solche Fragen werden in vielen ersten MCP-Implementierungen schlicht übersehen, weil sie im API-Design des ursprünglichen Dienstes gar nicht vorkamen.

Zusammenspiel mehrerer MCPs. Sobald mehrere MCP-Server im Zusammenspiel eine Aufgabe lösen sollen, wie im Wetter-Beispiel oben, entstehen Abhängigkeiten, die kein einzelner Server für sich allein lösen kann. Wie granular müssen Ergebnisse sein, damit ein anderes Tool sie direkt weiterverarbeiten kann? Wie geht man mit uneindeutigen Zwischenergebnissen um, ohne dass am Ende einfach geraten wird? Das sind Designfragen, die weit über die einzelne Schnittstelle hinausgehen.

Abbildung 2: Nur durchgereicht vs. für echte Zusammenarbeit gestaltet

Bei let's dev bauen wir mittlerweile eine ganze Reihe an MCP-Servern – für interne wie für extern angebundene Dienste – und genau aus dieser wiederholten Praxis heraus haben sich bei uns klare, gemeinsame Prinzipien herausgebildet: Tools werden nicht isoliert entworfen, sondern immer mit Blick darauf, wie ein Agent sie tatsächlich in einer größeren Kette einsetzen wird. Fehlerfälle werden von Anfang an mitgedacht, nicht nachträglich ergänzt. Und wiederkehrende Bausteine – vom Server-Grundgerüst über einheitliche Antwortformate bis hin zu Sicherheitsmechanismen – bündeln wir in einer gemeinsamen internen Bibliothek, statt sie in jedem neuen Projekt erneut zu erfinden. Das bedeutet, dass ein neuer MCP bei uns nicht bei null anfängt, sondern von Anfang an auf einem Fundament aufbaut, das schon aus echten, gelernten Fehlern der vorherigen Server besteht. Unsere Erfahrungen auf diesem Gebiet ermöglichen es uns heute, zügig neue MCPs zu erstellen oder bestehende an neue Standards und Gegebenheiten anzupassen – denn natürlich steht auch die Weiterentwicklung des Model Context Protocols selber nicht still. Gerne helfen wir auch dabei, einen eigenen MCP zu erstellen oder eine bestehende Installation zu pflegen und weiterzuentwickeln – kontaktieren Sie uns einfach.