The three MCP servers worth connecting on a web build
A connected server costs context on every request, so most are not worth it. The three that are, the scope decision that decides who gets them, and the injection risk nobody mentions.
Most of the friction in a web build is not writing code. It is moving facts between systems: the spacing from the design file, the field names from the CMS, the error from the last deploy. You read them in one window and retype them in another, and the agent you are working with knows none of it. The Model Context Protocol is the open standard that closes that gap, and Claude Code speaks it natively.
The question is not whether to connect servers. It is which three, because the cost of a connected server is paid on every single request in the session, and most of what is available is not worth that.
The scope decides who gets the server
There are three scopes, and the choice is more consequential than it looks. Local scope is the default and keeps the server to you on this machine. User scope gives it to you across every project. Project scope writes the server into a file at the repository root and shares it with everyone who works there, which is the one that matters for a client build. As the MCP reference explains, a project-scoped server waits for approval before it connects, so committing the file does not silently hand your team a connection they did not choose.
Our rule is that anything a colleague needs to reproduce the build goes in project scope, and anything tied to an account only one person holds stays local. Design tooling tends to be the second kind, which is worth knowing before you commit a file that half the team cannot use.
Where it pays: the design handoff
This is the clearest win, because the handoff is pure fact transfer and humans are bad at it. Reading token values, spacing scales and component variants out of a design file by hand produces an approximation, and the approximation is where design review time goes. A server that lets the agent read the file directly removes a whole category of back and forth.
Two warnings from using it in anger. First, the agent will happily translate a design into hard-coded values unless you tell it to use your existing tokens, and it cannot tell which it should prefer. Second, free and entry tiers on design platforms cap tool calls hard enough to stop a build mid-way, so check the ceiling before you plan a day's work around it.
Where it pays: the CMS you do not want to click through
If the site has a content model with a few hundred items, the admin interface is the bottleneck. Creating forty collection items by hand is an afternoon; describing them once and having the agent write them through an API is twenty minutes. Webflow publishes its own set of agent tools for exactly this, and the same shape exists for most hosted CMSes now.
The thing to plan for is that writing through an API is not the same as building in the editor. Some properties simply are not exposed, and you find out by hitting them. We keep a short note per platform of what the API cannot set, because discovering it twice is pure waste. The comparison of platforms goes into which ones leave more on the table.
Where it pays: reading your own deploys
The third one is the least discussed and possibly the most useful. A host server lets the agent read the build log, the runtime errors and the deploy status directly, which turns the most common debugging loop on a deployed site from paste-and-ask into a single question. Vercel documents theirs, and the pattern generalises.
Pair it with the habit from the production checklist and the loop gets short: push to a preview, ask the agent what the deploy said, fix, push again. No copying log lines into a chat window.
Where it does not pay
| Server | What it replaces | Worth it on a website build |
|---|---|---|
| Design file access | Reading tokens and spacing by hand | Yes, with a tool-call ceiling to watch |
| Hosted CMS write access | Clicking through the admin interface | Yes, above roughly thirty items |
| Host and deploy logs | Pasting build output into chat | Yes, and it is the cheapest of the three |
| Issue tracker | Reading a ticket yourself | Rarely on a marketing site |
| Analytics | Opening a dashboard | No, the numbers need judgement, not retrieval |
The pattern in that table is that a server earns its place when it replaces mechanical retrieval, and earns nothing when it replaces judgement. Analytics is the clean example: pulling the numbers was never the hard part.
The trust problem nobody puts on the slide
A connected server can put text into your agent's context, and text in context is something the agent may act on. That is the whole shape of prompt injection, and the docs say so plainly: verify that you trust a server before connecting it, because servers that fetch external content widen your exposure. On a web build the risk is concrete rather than theoretical, since a CMS field, a page you scraped and a comment on a design file are all content someone else can write.
The practical defence is not clever. Connect few servers, prefer ones whose publisher you can name, and treat anything a server returns as data rather than instruction. The same reasoning applies to what your own site gives to crawlers, which is the subject of what AI crawlers actually receive.
Three is the number
Every connected server adds tool definitions to context, and context you spend on tools is context you do not spend on the codebase. We run three on a typical build: the host, the CMS when there is one, and the design file while the design is still moving. Everything else gets connected for an afternoon and disconnected again. If you are deciding what to configure first, the agent's own instructions file matters more than any server, and the CLAUDE.md piece is where that starts. Skills are the next lever, and we set all of this up as part of a Webflow build or a custom one.
