End-to-End-Entwicklung mit Agenten und MCP

Im vorherigen Post habe ich beschrieben, wie ich Agenten in Claude Code und GitHub Copilot anlege, sie für das Projekt fine-tune und im Workflow verlässlich einsetze. Die Agenten kennen ihre Rolle, sie kennen das Projekt über CLAUDE.md und ihre Konventionen. Was sie bisher aber nicht kannten: alles, was außerhalb des Repos lebt.

Konkret heißt das: Mein Komponenten-Agent kannte den Tailwind-Setup, aber nicht die aktuellen Designs in Figma. Mein Solution Architect kannte die Code-Struktur, aber nicht die Live-Schemas im Backend. Beides musste ich vorher manuell in jeden Prompt kopieren – Tokens, Komponentennamen, Collection-Attribute. Genau diese Lücke schließt MCP.

Was ist MCP eigentlich?

MCP steht für Model Context Protocol – ein von Anthropic Ende 2024 veröffentlichter offener Standard, der die Anbindung externer Tools und Datenquellen an LLMs vereinheitlicht. Die offizielle Analogie aus der Ankündigung beschreibt es treffend: MCP ist „USB-C für KI-Tools". Statt für jede Datenquelle eine eigene Integration zu bauen, spricht jeder MCP-Server dieselbe Sprache, und jeder MCP-fähige Client – Claude Code, Copilot, Cursor und andere – kann ihn nutzen.

Für mich heißt das in der Praxis: Statt Figma-Frames manuell zu beschreiben oder Appwrite-Schemas in jeden Prompt zu kopieren, hängt sich der jeweilige Agent über MCP direkt an die Quelle. Das verändert weder die Agenten-Logik noch das Human-in-the-Loop-Prinzip aus Post 12 – es macht nur die Daten frischer und die Prompts kürzer.

Frontend: Figma-MCP und der Komponenten-Agent

Eine konsistente UI ist mir wichtig – nicht aus Eitelkeit, sondern weil inkonsistente Komponenten die Wartbarkeit fressen. Was ich vermeiden will, ist genau das Duplikations-Problem aus Post 11: ein Agent baut eine Card-Komponente, drei Wochen später baut derselbe Agent eine zweite Card-Komponente, weil er die erste nicht mehr sieht.

Die Lösung in meinem Setup ist ein spezialisierter Komponenten-Agent, der über den Figma-MCP direkt auf das aktuelle Design zugreift. Wenn ich ihn auf einen Frame ansetze, liest er Layout-Daten, Spacing-Tokens, Farb-Variablen und Komponenten-Properties – und erzeugt daraus eine .vue-Komponente, die meinem Tailwind-Setup folgt. Anschließend aktualisiert er einen Styleguide unter docs/styleguide.md und dokumentiert die neue Komponente samt Props und Verwendungsbeispielen.

Der entscheidende Punkt liegt nicht im Komponenten-Code, sondern in diesem Styleguide-Dokument. Der Komponenten-Agent ist Gatekeeper für die UI-Schicht – ähnlich wie der Solution Architect aus Post 12 Gatekeeper für die Architektur ist. Wenn der Developer-Agent später einen neuen Screen baut, liest er nicht Figma, sondern den Styleguide. Damit ist sichergestellt, dass bestehende Komponenten wiederverwendet und nicht dupliziert werden. Single Source of Truth – diesmal für das Design.

Backend: Appwrite-MCP für Solution Architect und Developer-Agent

Im Backend habe ich dieselbe Lücke an einer anderen Stelle: Datenmodelle, Collections und Cloud Functions ändern sich, und jede dieser Änderungen muss irgendwie ihren Weg in die Konzepte und die Implementierung finden. Manuelles Übersetzen ist zeitraubend und fehleranfällig – genau das Konzept-Problem aus Post 11 (die KI „erfindet" Schemas, die nicht zur Realität passen).

Appwrite bietet dafür zwei MCPs an, die ich beide nutze:

• Appwrite Docs-MCP: statisches Wissen über die Appwrite-APIs, Patterns und SDK-Aufrufe.
• Appwrite API-MCP: Live-Zugriff auf das eigene Projekt – aktuelle Collections, Attribute, Permissions, Functions.

Im Workflow greift das an zwei klar getrennten Stellen. Der Solution Architect (Post 12) zieht über den API-MCP den aktuellen Schema-Stand, bevor er das Lösungskonzept entwirft. Damit baut er auf existierenden Collections auf, statt ein paralleles Datenmodell zu erfinden. Der Developer-Agent (Post 13) prüft während der Implementierung Attribut-Typen, Indizes und Permissions – ohne dass ich den Workflow für eine Nachfrage unterbrechen muss.

Installation in kurz

Eine vollständige Klick-Anleitung spare ich mir – beide Anbieter pflegen ihre eigene Doku besser, als ich es hier könnte. Die wesentlichen Schritte:

# Figma-MCP installieren (Claude Code)
claude plugin install figma@claude-plugins-official

# Appwrite-MCPs installieren
claude plugin marketplace add appwrite/claude-plugin
claude plugin install appwrite@appwrite

Nach der Installation in Claude Code mit /plugin die Authentifizierung anstoßen (Figma öffnet eine Browser-Seite, Appwrite fragt nach Endpoint, Project-ID und API-Key) und anschließend mit /reload-plugins aktiv schalten. Die ausführlichen Anleitungen liegen in der Figma-MCP-Doku und der Appwrite-MCP-Doku.

Ein ehrlicher Punkt: Was MCPs nicht lösen

MCPs sind eine Erweiterung – kein Allheilmittel. Drei Schattenseiten, die mir in der Praxis aufgefallen sind und über die ich nicht hinwegreden will.

Erstens: Der Token-Verbrauch steigt spürbar. Jeder MCP-Call zieht Schema-Daten, Design-Tokens oder API-Antworten in das Kontextfenster. Bei einem mehrstufigen Agenten-Workflow summiert sich das. Im Solo-Projekt ist das eine Rechnung, die ich akzeptiere – im Team wäre es ein Posten, den man explizit budgetieren sollte.

Zweitens: Externe Daten sind ein Einfallstor für Prompt Injection. Wenn eine Datenbankspalte oder ein Figma-Frame manipulierten Text enthält, kann der Agent diesen Text als Anweisung interpretieren. Anthropic warnt in der MCP-Sicherheits-Doku ausdrücklich davor. In meinem Solo-Projekt mit kontrollierten Datenquellen ist das Risiko überschaubar, in einem Team-Setup mit Drittinhalten ist es ein Governance-Thema.

Drittens: MCP-Server sind externe Dienste mit allen Konsequenzen. Sie fallen aus, brauchen Auth-Refresh, ihre Schemata ändern sich, und sie sind ein zusätzlicher Punkt, den man warten muss. Mein Workflow muss funktionieren, auch wenn ein MCP gerade nicht erreichbar ist – sonst habe ich nur eine neue Abhängigkeit, statt ein robusteres System.

Fazit

MCPs machen aus isolierten Agenten ein vernetztes Team. Sie ersetzen kein Konzept, keinen Plan und keinen Human-in-the-Loop-Checkpoint – sie sorgen nur dafür, dass die Agenten mit den richtigen, aktuellen Daten arbeiten.

Genau diese Arbeitsteilung gefällt mir an dem Prinzip: Das Protokoll löst ein Datenproblem, nicht ein Denkproblem. Die Verantwortung dafür, ob das Konzept stimmt und die Implementierung tragfähig ist, bleibt bei den Agenten – und letztlich bei mir.

Im nächsten Post drehe ich den Spieß um: Wenn jetzt Agenten, Pläne und MCPs zusammen einen ganzen End-to-End-Workflow ergeben, drängt sich eine unangenehme Frage auf – woher weiß ich eigentlich, dass das alles wirklich besser ist als ein direkter Prompt? Wie misst man den positiven Effekt von Agenten?