Die zweite Welle von MCP: Werkzeuge für LLMs entwickeln, nicht für Entwickler

In der heutigen schnelllebigen Technologiewelt ist es entscheidend, dass Teams ihre Werkzeuge und Prozesse kontinuierlich anpassen, um effizient und zuverlässig zu arbeiten. Die Einführung des Model Context Protocols (MCP) hat viele Teams dazu veranlasst, schnell Lösungen zu entwickeln, die oft nur dünne Wrapper um bestehende APIs waren. Doch diese Herangehensweise hat sich als unzureichend erwiesen, insbesondere wenn es um die Nutzung von Large Language Models (LLMs) geht. In diesem Artikel werden wir die Unterschiede zwischen API-gestützten Tools und workflow-basierten Tools für LLMs untersuchen und die Vorteile der letzteren hervorheben.

Die Herausforderungen traditioneller API-gestützter Tools

Als das MCP-Standard erstmals eingeführt wurde, war der Drang, schnell etwas auf den Markt zu bringen, groß. Viele Teams entschieden sich für eine einfache Lösung: Sie packten bestehende API-Strukturen in neue Wrapper, um zu behaupten, sie würden MCP unterstützen. Dies mag in der Anfangsphase sinnvoll gewesen sein, doch es gibt grundlegende Unterschiede in der Art und Weise, wie LLMs und Entwickler mit APIs umgehen.

Entwickler können den Zustand zwischen API-Aufrufen verwalten und behalten Informationen über vorherige Interaktionen. Sie speichern beispielsweise Projekt-IDs und überprüfen den Status von Bereitstellungen, bevor sie weitere Schritte unternehmen. LLMs hingegen beginnen jede Konversation ohne Erinnerung an vorherige Interaktionen. Sie müssen herausfinden, welche Werkzeuge verfügbar sind und in welcher Reihenfolge sie verwendet werden sollten. Dies führt oft zu wiederholter Orchestrierung und inkonsistentem Verhalten, da LLMs immer wieder die gleichen Probleme lösen müssen.

Wie LLMs APIs anders nutzen

Der entscheidende Unterschied zwischen der Nutzung von APIs durch Entwickler und LLMs liegt im Kontext- und Zustandsmanagement. Während Entwickler den Fluss ihrer API-Aufrufe steuern, müssen LLMs bei jedem neuen Gespräch die richtige Reihenfolge der Werkzeuge ermitteln. Dies wird besonders deutlich, wenn man sich die Bereitstellung eines Projekts mit der Vercel API ansieht.

Ein Entwickler könnte den folgenden Code verwenden, um ein Projekt bereitzustellen:

const project = await client.projects.create({ name: domain.replace(/\./g, '-'), gitRepository: { repo: repoUrl }});
await client.projects.createProjectEnv({ idOrName: project.id, upsert: 'true', requestBody: Object.entries(env).map(([key, value]) => ({ key, value, target: ['production', 'preview', 'development'], type: 'encrypted' })) });
const deployment = await client.deployments.createDeployment({ requestBody: { name: project.name, target: 'production', gitSource: { type: 'github', repo: repo.replace('.git', ''), ref: 'main' } }});
await client.projects.addProjectDomain({ idOrName: project.id, requestBody: { domain: domain }});

Hierbei muss der Entwickler IDs zwischen den Aufrufen verwalten und potenzielle Fehler an jedem Schritt berücksichtigen. Ein LLM hingegen steht vor der Herausforderung, diese Puzzles bei jedem neuen Gespräch erneut zu lösen, was zu Fehlern und Ineffizienzen führen kann.

Einzelne Workflow-Tools vs. mehrere Endpunkte

Die Lösung liegt darin, Werkzeuge um vollständige Benutzerziele herum zu entwickeln, anstatt sich auf API-Funktionen zu konzentrieren. Anstatt vier separate Tools zu erstellen, die jeweils einen Teil des Bereitstellungsprozesses abdecken, sollte ein einziges Tool entwickelt werden, das den gesamten Workflow intern verwaltet.

Dies verändert die Art und Weise, wie Werkzeuge gestaltet werden:

• API-gestützte Werkzeuge: create_project, add_env, deploy, add_domain
• Intention-basierte Werkzeuge: deploy_project

Ein intention-basiertes Tool könnte wie folgt aussehen:

deploy_project(repo_url, domain, environment_variables, branch="main")

Dieses einzelne Tool verwaltet den gesamten Workflow intern und gibt eine konversationelle Antwort zurück, anstatt technische Statuscodes zu liefern. Statt einer Antwort wie { status: 200, data: { id: “proj_123” } } könnte das LLM antworten: “Projekt erfolgreich unter example.com bereitgestellt. Build abgeschlossen in 45 Sekunden. Alle Systeme laufen normal.”

Gestaltung von workflow-basierten MCP-Tools

Der erste Schritt zur Entwicklung eines effektiven workflow-basierten Tools besteht darin, den Workflow manuell zu testen, bevor Code geschrieben wird. Nehmen Sie eine reale Benutzeranfrage wie “Richten Sie mein Projekt mit Authentifizierung und einer Datenbank ein” und gehen Sie Schritt für Schritt durch den Prozess unter Verwendung Ihrer bestehenden APIs. Die Teile, die mühsam oder repetitiv erscheinen, sind gute Kandidaten für ein einzelnes MCP-Tool.

Denken Sie bei der Gestaltung von MCP-Tools daran, dass sie maßgeschneiderte Werkzeugkästen sind, die einem KI-Modell helfen, eine bestimmte Aufgabe zu erfüllen, und keine bloßen API-Spiegel. Es kann mehrere APIs und Geschäftslogik hinter einem einzigen MCP-Tool geben. Wenn Benutzer etwas als einen Workflow betrachten, gestalten Sie es als ein Tool.

Leistungsverbesserungen durch Workflow-Tools

Teams, die von API-gestützten zu workflow-basierten Tools gewechselt sind, haben signifikante Verbesserungen in Bezug auf Zuverlässigkeit und Effizienz festgestellt. Der gemeinsame Nenner ist, wie diese Werkzeuge gestaltet sind:

• Sie konzentrieren sich auf Benutzerabsichten anstelle von API-Abdeckung.
• Sie verwalten vollständige Workflows, anstatt einzelne Operationen freizugeben.
• Sie antworten auf konversationelle Weise, anstatt technische Codes zurückzugeben.

MCP funktioniert am besten, wenn Werkzeuge vollständige Benutzerziele widerspiegeln. LLMs verwalten den Zustand nicht wie Entwickler, daher führt der Aufbau von Werkzeugen rund um Workflows zu besseren Ergebnissen.

Probieren Sie diesen Ansatz aus. Der MCP Handler macht es einfach, Ihre Anwendungslogik als workflow-basierte MCP-Tools bereitzustellen. Starten Sie mit der Next.js MCP-Vorlage oder erkunden Sie die Dokumentation.

Fazit

Die zweite Welle von MCP erfordert ein Umdenken in der Art und Weise, wie wir Werkzeuge für LLMs entwickeln. Indem wir uns auf die Benutzerabsichten konzentrieren und vollständige Workflows gestalten, können wir die Effizienz und Zuverlässigkeit unserer Systeme erheblich steigern.

Quellenliste:

• Quelle: The Second Wave of MCP: Building for LLMs, Not Developers
• MCP Documentation
• MCP Handler on GitHub
• Next.js MCP Template