4 Lektionen aus der Arbeit mit MCP-Tools und Vonage-APIs

Das Model Context Protocol (MCP) hat sich schnell entwickelt. Ich erinnere mich, als ich im März letzten Jahres auf der FOSSASIA 2025. Es ist kaum zu glauben, dass es weniger als ein Jahr her ist, aber es fühlt sich bereits so an, als sei es in der Programmierung allgegenwärtig geworden.

Obwohl ich schon früh davon gehört habe, habe ich mich erst in den letzten Monaten wirklich damit beschäftigt. Ich habe mich mit der Vonage-Dokumentation und Tooling MCP-Serverzunächst lokal, dann durch Blogposts, Demos und schließlich durch die Mitarbeit am Open-Source-Tooling-Server. Dies ist keine Rekapitulation der MCP-Funktionen oder eine Anleitung für den Einstieg: Es handelt sich um eine Reihe von Lektionen, die beim Versuch, die Werkzeuge in der Praxis nutzbar zu machen, auftauchten.

Lektion Eins: Ein früher Fehler: Agenten setzen auf Codegenerierung

Das erste wirkliche Versagen war kein technischer Fehler. Es war ein fehlerhaftes mentales Modell.

Ich verband meine IDE mit dem MCP-Server, bestätigte, dass die Tools registriert waren, und bat den Agenten, eine WhatsApp-Nachricht zu senden. Anstatt das vorhandene Tool aufzurufen, öffnete der Agent eine neue Datei und begann, ein Node.js-Skript zu schreiben. Er versuchte, das Vonage SDK zu importieren, die Authentifizierung zu konfigurieren und den API-Aufruf direkt durchzuführen.

Mit dem Modell war nichts "falsch". Es tat genau das, wofür es trainiert worden war: Probleme durch das Schreiben von Code lösen.

Das Problem war, wie ich das System konzipiert hatte. Der Agent fungierte als intelligenter Codegenerator und nicht als Orchestrierungsschicht. Die Werkzeuge waren bereits vorhanden. Der Agent brauchte nichts zu entwickeln: Er musste auswählen und aufrufen, was verfügbar war.

Nachdem ich die Aufforderungen an den Agenten angepasst hatte, klappte alles wie am Schnürchen. Anstatt ihn zu bitten, Funktionen zu erstellen, bat ich ihn, Funktionen zu nutzen.

Diese Veränderung klingt unbedeutend, aber sie ist in Wirklichkeit eine große mentale Veränderung.

Das Fazit: MCP funktioniert am besten, wenn Sie aufhören, in Skripten zu denken, und anfangen, in Tools zu denken. Wenn der Agent Klebstoffcode schreibt, bedeutet das in der Regel, dass etwas im Vorfeld nicht richtig strukturiert ist.

Lektion zwei: Die Konfiguration war ein echter Zeitfresser

Sobald das mentale Modell korrigiert war, erwartete ich, dass der Rest der Arbeit einfach sein würde. Das war sie aber nicht.

Der zeitaufwändigste Teil der lokalen Entwicklung bestand darin, die IDE dazu zu bringen, eine zuverlässige Verbindung zum MCP-Server herzustellen. Die meisten Fehler sahen aus wie "das Tool wird nicht angezeigt", was die Annahme erleichterte, dass der Server defekt war. Es lag aber fast immer an der Konfiguration.

Verschiedene IDEs erwarten die MCP-Konfiguration an unterschiedlichen Stellen. Windsurf zum Beispiel sieht aus wie VS Code, ist aber nicht VS Code, und der Konfigurationspfad ist nicht dort, wo er laut Muskelgedächtnis sein sollte. Ich habe mehr Zeit als ich zugeben möchte damit verbracht, nicht vorhandene Fehler zu suchen, weil der Server gar nicht erst gestartet wurde.

MCP-Konfigurationen verhalten sich auch nicht wie Shell-Skripte. Der Client ruft direkt einen Prozess auf. Sie können sich nicht auf sh -c, cdoder verkettete Befehle verlassen. Wenn Sie keine absoluten Pfade und expliziten Befehle verwenden, sind Fehler in der Regel geräuschlos.

Sobald alles korrekt konfiguriert war, verlief die Erfahrung auf die beste Art und Weise ereignislos. Starten Sie die IDE neu, aktualisieren Sie das Plugin-Bedienfeld, und die Werkzeuge erscheinen.

Die Quintessenz: MCP folgt einem bekannten Programmiermuster: Die Einrichtung bereitet die meisten Kopfschmerzen. Wenn etwas nicht funktioniert, liegt es meist an der Konfiguration. Sobald Sie eingerichtet sind, lässt MCP Sie fliegen!

Lektion 3: Stdio funktioniert lokal gut, anderswo weniger gut

Der standardmäßige stdio-Transport von MCP ist eine gute Lösung für die lokale Entwicklung. Er ist einfach, schnell und vermeidet die Offenlegung von Ports oder Anmeldeinformationen. Für IDE-basierte Arbeitsabläufe erfüllt er genau das, was Sie wollen. Und genau aus diesem Grund haben wir ihn für für unseren Tooling Server verwendet. Wir wollten ihn schnell und flexibel in die Hände der Entwickler geben.

Es gibt jedoch einige Einschränkungen, wenn Sie versuchen, die gleichen Werkzeuge außerhalb einer IDE zu verwenden, z. B. bei der Integration eines externen Systems. Sie können keine HTTP-Anfrage an stdin stellen. Es gibt keinen zu sichernden Endpunkt und keinen offensichtlichen Ort, an dem man die Authentifizierung anbringen kann.

Um diese Lücke zu schließen, baute ich eine kleine Übersetzungsschicht, die JSON-RPC über stdio in HTTP konvertierte, damit andere Systeme mit dem MCP-Server interagieren konnten. Es funktionierte, aber es war eine zusätzliche Infrastruktur, die in der rein lokalen Einrichtung nicht vorhanden war.

Auch das Testen wurde umständlicher. "Es funktioniert lokal" ist nicht sehr aussagekräftig, wenn der Agent das Tool von einem anderen Ort aus aufruft. Es gibt derzeit keinen sauberen Mittelweg, um MCP-Tools isoliert zu validieren, ohne eine vollständige Agentensitzung zu starten.

Die Quintessenz: MCP macht IDE-Workflows einfach, deshalb haben wir dort angefangen. Für Entwickler, die es gewohnt sind, ihr eigenes Hosting und ihre eigene Authentifizierung zu verwalten, ist dieser Kompromiss angemessen. Sobald man über die lokale Nutzung hinausgeht, bringt stdio Herausforderungen wie Authentifizierung, Übersetzungsschichten und Tests mit sich. Dabei geht es weniger um MCP selbst als vielmehr darum, wo dieser Server steht. Halten Sie die Augen offen, wenn unser MCP-Angebot erweitert wird.

Lektion Vier: Planung für Wachstum: Werkzeugentwurf und Kontextbudget

Diese Lektion kam nicht dadurch zustande, dass etwas kaputt ging. Sie ergab sich aus einem Blick auf den Tooling-Server und der Frage: "Was wird passieren, wenn mehr Leute einen Beitrag leisten?"

Beim Schreiben über Verwendung der Vonage MCP-Tools und Ermutigung zu Open-Source-Beiträgenwurde klar, dass die Repo-Struktur nicht dafür ausgelegt war, zu wachsen. Alles befand sich in einer einzigen Datei. Am Anfang ist das noch überschaubar, aber es lässt sich nicht gut skalieren. Weder für Menschen noch für Agenten.

Wenn man sich ansieht, wie andere MCP-Server das Wachstum handhaben, wird eine noch wichtigere Einschränkung deutlich: Jedes Werkzeug, das Sie freigeben, verbraucht einen Teil des Kontextfensters des Modells.

Werkzeugschemata sind nicht frei. Namen, Parameter und Beschreibungen werden alle in die Eingabeaufforderung des Systems eingefügt. Mit zunehmender Anzahl von Werkzeugen verringert sich allmählich der Platz, der dem Modell zur Verfügung steht, um auf die tatsächliche Anfrage des Benutzers zu schließen.

Die Versuchung ist natürlich groß, flexible, vielseitig einsetzbare Tools zu entwickeln: eine einzige send_message die jeden Kanal und jedes Verhalten abdeckt. Aus Sicht der API ist das ordentlich. Aus der Sicht eines Modells ist es jedoch mehrdeutig und teuer.

Kleinere Werkzeuge für einen einzigen Zweck funktionieren in der Regel besser. Sie sind für das Modell leichter auszuwählen, billiger zu beschreiben und einfacher zu erklären. Interne Implementierungen können weiterhin gemeinsam genutzt werden. Das Wichtigste ist, was der Agent sieht.

Der aktuelle Open-Source-Tooling-Server implementiert noch kein kontextabhängiges Laden, und das ist beabsichtigt. Aber diese Einschränkungen prägen bereits unsere Überlegungen zu einem produktiveren MCP-Server, den jeder nutzen kann, nicht nur Entwickler.

Das Wichtigste: Bei MCP geht es bei der Leistung nicht nur um die Ausführungsgeschwindigkeit. Es geht auch darum, wie viel Kontext Sie verbrauchen.

Abschließende Überlegungen

Die Arbeit mit MCP hat meine Einstellung zur täglichen Arbeit verändert. Prozesse, die ich früher als manuell oder repetitiv akzeptierte, werden nun zu potenziellen Werkzeugen. Sobald diese Veränderung eintritt, sieht man überall Möglichkeiten; nicht um der Automatisierung willen, sondern um Reibungsverluste an Stellen zu beseitigen, die die eigentliche Arbeit verlangsamen.

MCP ist noch jung, und viele der Ecken und Kanten sind verständlich. Aber eines wurde sehr schnell klar: Der Erfolg eines MCP-basierten Systems hängt nicht nur von dem gewählten Modell ab, sondern auch davon, wie durchdacht die Werkzeuge gestaltet sind. Klare Grenzen, enge Verantwortlichkeiten und vorhersehbares Verhalten sind wichtiger als clevere Abstraktionen. Wenn diese Elemente vorhanden sind, wird das System vertrauenswürdiger und leichter erweiterbar.

Am interessantesten finde ich die Art und Weise, wie MCP dazu anregt, Software als etwas zu betrachten, das dazu bestimmt ist, genutzt zu werden verwendet von Agenten und nicht nur von Menschen genutzt werden soll. Das ändert die Art und Weise, wie man APIs schreibt, wie man die Dokumentation strukturiert und wie man bewertet, ob etwas "fertig" ist. Es ist eine andere Art von Kompromissen, die sich erst noch herausbilden muss.

In den kommenden Wochen werde ich mit anderen MCP-Tools experimentieren, wie Laravel-Boost und MCP UI um zu sehen, wie andere diese Probleme angehen. Wenn Sie mit MCP arbeiten oder nur darüber nachdenken, würde ich gerne hören, was Sie bauen und was Sie auf dem Weg gelernt haben. Senden Sie mir eine Nachricht auf LinkedIn oder den Vonage Entwickler Slack.