End-to-End Development with Agents and MCP

In the previous post I described how I create agents in Claude Code and GitHub Copilot, fine-tune them for the project, and deploy them reliably in the workflow. The agents know their role, they know the project through CLAUDE.md and their conventions. What they didn't know until now: everything that lives outside the repo.

Concretely, this means: my component agent knew the Tailwind setup, but not the current designs in Figma. My Solution Architect knew the code structure, but not the live schemas in the backend. I had to manually copy both into every prompt – tokens, component names, collection attributes. Exactly this gap is what MCP closes.

What Is MCP Anyway?

MCP stands for Model Context Protocol – an open standard released by Anthropic at the end of 2024 that unifies the connection of external tools and data sources to LLMs. The official analogy from the announcement describes it well: MCP is "USB-C for AI tools". Instead of building a separate integration for every data source, every MCP server speaks the same language, and every MCP-capable client – Claude Code, Copilot, Cursor, and others – can use it.

For me, in practice this means: instead of manually describing Figma frames or copying Appwrite schemas into every prompt, the respective agent hooks directly into the source via MCP. This changes neither the agent logic nor the Human-in-the-Loop principle from post 12 – it just makes the data fresher and the prompts shorter.

Frontend: Figma MCP and the Component Agent

A consistent UI matters to me – not out of vanity, but because inconsistent components eat away at maintainability. What I want to avoid is exactly the duplication problem from post 11: an agent builds a card component, three weeks later the same agent builds a second card component because it can no longer see the first one.

The solution in my setup is a specialized component agent that accesses the current design directly through the Figma MCP. When I point it at a frame, it reads layout data, spacing tokens, color variables, and component properties – and produces a .vue component from them that follows my Tailwind setup. It then updates a style guide under docs/styleguide.md and documents the new component along with its props and usage examples.

The decisive point lies not in the component code but in this style guide document. The component agent is the gatekeeper for the UI layer – similar to how the Solution Architect from post 12 is the gatekeeper for the architecture. When the Developer Agent later builds a new screen, it doesn't read Figma; it reads the style guide. This ensures that existing components are reused and not duplicated. Single source of truth – this time for the design.

Backend: Appwrite MCP for Solution Architect and Developer Agent

In the backend I have the same gap at a different point: data models, collections, and cloud functions change, and each of these changes has to find its way somehow into the concepts and the implementation. Manual translation is time-consuming and error-prone – exactly the concept problem from post 11 (the AI "invents" schemas that don't match reality).

Appwrite offers two MCPs for this, both of which I use:

• Appwrite Docs MCP: static knowledge about the Appwrite APIs, patterns, and SDK calls.
• Appwrite API MCP: live access to your own project – current collections, attributes, permissions, functions.

In the workflow this kicks in at two clearly separated points. The Solution Architect (post 12) pulls the current schema state via the API MCP before drafting the solution design. This way it builds on existing collections instead of inventing a parallel data model. The Developer Agent (post 13) checks attribute types, indexes, and permissions during implementation – without me having to interrupt the workflow to look something up.

Installation in Brief

I'll spare you a complete click-by-click guide – both providers maintain their own docs better than I could here. The essential steps:

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

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

After installation in Claude Code, trigger authentication with /plugin (Figma opens a browser page, Appwrite asks for endpoint, project ID, and API key) and then activate with /reload-plugins. The detailed instructions are in the Figma MCP docs and the Appwrite MCP docs.

An Honest Point: What MCPs Don't Solve

MCPs are an extension – not a cure-all. Three downsides I noticed in practice and don't want to gloss over.

First: Token consumption rises noticeably. Every MCP call pulls schema data, design tokens, or API responses into the context window. In a multi-stage agent workflow this adds up. In a solo project this is a bill I accept – on a team it would be a line item you should explicitly budget for.

Second: External data is a gateway for prompt injection. If a database column or a Figma frame contains manipulated text, the agent can interpret this text as an instruction. Anthropic explicitly warns of this in the MCP security docs. In my solo project with controlled data sources, the risk is manageable; in a team setup with third-party content, it is a governance topic.

Third: MCP servers are external services with all the consequences. They go down, they need auth refresh, their schemas change, and they are an additional point that has to be maintained. My workflow must function even when an MCP is not reachable – otherwise I just have a new dependency instead of a more robust system.

Conclusion

MCPs turn isolated agents into a connected team. They don't replace a concept, a plan, or a Human-in-the-Loop checkpoint – they just ensure that the agents work with the right, current data.

That is exactly the division of labor I like about this principle: the protocol solves a data problem, not a thinking problem. The responsibility for whether the concept is right and the implementation viable stays with the agents – and ultimately with me.

In the next post I'll flip the script: if agents, plans, and MCPs now jointly form a complete end-to-end workflow, an uncomfortable question forces itself to the surface – how do I actually know that all this is really better than a direct prompt? How do you measure the positive effect of agents?