Over the last few months, we’ve covered the Model Context Protocol (MCP) from the ground up, from what it is and why it matters to how to build your own MCP server tools for AI agents.
The MCP server ecosystem has been exploding, but this leads to the next, more interesting question: now that we have all these powerful tools, how do we actually use them for web development?
The answer lies with the MCP client.
In the MCP architecture, the application you directly interact with—an IDE like Cursor, a chatbot like Claude Desktop, or a visual web canvas like Builder’s Fusion—is called the host. The MCP client is a component that lives inside that host, and it has one primary job: to manage a dedicated, one-to-one connection with an MCP server.
The MCP client handles all the critical communication: discovering what tools and data a server offers, forwarding requests to that server, and relaying the responses back to the host application.
We have a complete breakdown of the Model Context Protocol and its pieces, for those interested.
So, what do these MCP clients look like for web developers today? They generally fall into two camps, each powerful in its own right but with critical blind spots for building on the web.
First, you have your chat-based hosts, like the Claude Desktop app, which are great for conversational queries. You can connect your company’s database as an MCP server and ask, "How many new users did we get last week?" and get an instant, accurate answer.
But the moment your request involves a UI, you hit a wall. Ask it to "Build me a responsive dashboard visualizing that user data," and it has nowhere to go. The client has no visual canvas, no concept of components, no way to render what you’ve asked for. The interface is simply wrong for the task of building visually.
The second camp is the IDE-based hosts, like Cursor and Windsurf. This is where things get really exciting for developers. You can connect it to a Notion server to keep team documentation up to date, and then automatically use that context later while prompting improvements. You could connect to the Figma MCP server to generate code based on actual design components, not just a screenshot.
This brings the core promise of MCP, portability, directly into your workflow. Your org can build an MCP server for its internal design system once, and every developer can use it. It's an elegant and powerful setup for devs.
But what happens when a product manager or designer wants to visually prototype a new feature based on a collection of those tickets? To them, that same IDE is an intimidating wall of text, and they’ve no choice but to stay in Figma or chat apps that don’t sync with your actual source of truth—the code repository. More labor falls to the devs.
Ideally, the world of MCP connects teammates more and makes design handoffs easier, thanks to portable team context. In reality, we see that each role is still relatively siloed, and shared context exists mostly as text and images instead of working code.
Developers find edge cases when making actual code, and designers have to mock up alternate states. Using a feature in reality might be a lot different from the idealized user story, and teams can waste valuable cycles when they’re only able to test usability once developers have coded up components.
The solution isn’t another hyper-specialized client. It’s one that creates a shared, visual context of your code for the entire team, with MCP capabilities to connect to the tools everyone already uses.
This is why we built Fusion, a visual AI canvas for the web that acts as an orchestration hub for product teams. It works both as a web app and a VS code extension, and it connects to your existing repo to let anyone branch and contribute.
Let’s see how Fusion gives each team member the right interface for their job, all the while reducing tedious back-and-forth with other teammates.
Product managers often have clear visions for new features, components, or pages. Usually, they’ll send designers and developers a PRD, but there might be a lot of cycles wasted trying to translate their words into designs and code.
More advanced PMs might use an AI prototyping tool, like Bolt, Lovable, or v0. The problem with these tools is that you’re always starting from scratch; you’re not working with your actual repo.
With Fusion, a PM can work out all the edge cases of their idea on a real branch with existing components. They can prompt changes as large as making whole new pages or as small as adjusting some button text.
Or, using the MCP client capabilities, they can let AI take the first pass at a pesky ticket:
The important thing is that Fusion gives them an AI-powered abstraction layer over the org’s repo, creating branches for each major changeset and generating preview URLs for every PR.
Even if the new feature still needs a designer for pixel-perfect finesse or a developer for final optimization, the PM has already been able to work out the entire user story on a true-to-life canvas.
Designers, instead of starting from a text document from a PM, now get to start from a working prototype, complete with all states ready to be designed.
For many teams, this may be enough—the designer can go in and make visual tweaks in the Figma-like interface to get it just right, and then let the AI apply the changes to the GitHub branch:
Or, if they need to jump back into Figma, that’s fine, too. Fusion can sync with Figma tokens to add pixel-perfect frames directly to the codebase any time you import a design.
Either way, designers can now contribute their skills directly to the repo, and they don’t have to worry about their Figma frames getting mutilated before they’re translated to the web.
Either from their PM or designers, developers now get a handoff that’s not only visually complete but also structured with familiar components and styling. Their job isn't to rebuild; it's to polish the functionality.
This is where Fusion's power as an MCP orchestration hub gets really exciting. For instance, let’s say a developer needs to wire up the sign-up form to multiple backend services:
"For this sign-up form:
- On submit, use the Stripe MCP server to create a new trial customer.
- Use the HubSpot MCP server to add that customer to our 'New Trial Users' marketing list.
- Use the Linear MCP server to close the original feature ticket and post a comment that the page is live."As long as you have all your data sources connected within Fusion, any combination is possible.
Or maybe the changes needed are much smaller. The developer can stay within GitHub and use the asynchronous Builder agent.
Since the whole workflow centers around actual code in the org’s actual repo, the developer can always jump into the IDE for anything that needs more finesse.
Fusion acts as that common ground. By combining a deep, native understanding of your codebase and design assets with the limitless extensibility of the Model Context Protocol, it creates a single environment where every member of the team can contribute effectively.
It finally bridges the gap between design, product, and engineering, moving us from building isolated tools to creating truly collaborative, agentic workflows.
