Model Context Protocol can give an AI coding assistant a structured way to inspect and change a website. That is more useful than copying code into chat, but it also changes the risk model: the assistant may be able to call real tools, modify content, or publish changes.
The solution is not to avoid agents. It is to design the connection so that reading is easy, destructive actions are narrow, and every visible change remains reviewable.
MCP in plain language
MCP is an open standard that connects AI applications to external systems. The official MCP introduction compares it to a common connector: an AI application can discover data sources and tools rather than relying on pasted context or a custom integration for every service.
There are three useful roles:
- Host: the AI application the person is using, such as an editor or assistant.
- Client: the connection that the host maintains to one MCP server.
- Server: the program that exposes controlled capabilities and context.
The server can expose three core primitives:
- resources for contextual data;
- tools for executable actions;
- prompts for reusable interaction templates.
The current MCP architecture documentation describes this client-server model and the discovery process in detail.
Why MCP fits website work
A website task usually needs more context than a code snippet. The agent may need to know:
- available pages and routes;
- the current component or DOM structure;
- content and SEO metadata;
- design tokens;
- previous edits;
- deployment state;
- the difference between a draft and the live site.
An MCP server can expose that information through typed operations. Instead of asking an agent to guess where a headline lives, the agent can list pages, inspect the selected page, and call a narrowly defined update tool.
Typed tools also create a better audit trail. update_text({ pageId, elementId, value }) is easier to validate and log than an unrestricted instruction to rewrite arbitrary files.
Design the tool surface around user intent
Start with the smallest useful set of operations. A safe website server often needs four layers.
1. Discovery tools
Examples:
- list sites;
- list pages;
- describe the current page;
- inspect a selected element;
- list available fonts, tokens, and components.
These should be read-only and inexpensive. They let the agent verify identifiers before changing anything.
2. Draft editing tools
Examples:
- update text;
- change a link;
- replace an image reference;
- modify a style property;
- add or remove a draft element;
- update SEO metadata.
The tool should validate the target and value. Prefer a domain-specific input such as { elementId, colorToken } over arbitrary JavaScript or shell execution.
3. Validation tools
Examples:
- render or preview the draft;
- report broken links;
- run accessibility checks;
- compare a screenshot;
- show a structured diff;
- validate metadata and routes.
Validation should be callable before any live action.
4. Release tools
Examples:
- save a version;
- create a deployment preview;
- publish;
- roll back to a known version.
Publishing deserves a separate tool and permission boundary. Editing a draft should never silently publish it.
Separate read, write, and publish permissions
A single all-powerful token makes the integration simple to build and hard to trust. Use scopes or server-side authorization so the connection can distinguish:
- read site;
- edit draft;
- manage settings;
- deploy preview;
- publish production.
Default new connections to read-only or draft editing. Ask for elevated authorization only when the user invokes the corresponding action.
For a remote MCP server, follow the current authorization guidance for that transport. The protocol's documentation recommends standard authentication mechanisms and discusses OAuth for remote connections. Security requirements evolve, so implement against the version your clients actually support rather than a copied configuration from an old tutorial.
Use stable identifiers
Agents work best when tool targets are unambiguous. Do not identify a button only by its visible label; a page may contain four buttons named “Learn more.” Return stable site, page, element, and version identifiers from discovery tools.
A good inspection response might include:
{
"pageId": "page_home",
"elementId": "hero_primary_cta",
"type": "link",
"text": "Start free",
"href": "/signup",
"version": 18
}
The update tool can require the version it inspected. If another collaborator changes the page first, the server rejects the stale write instead of overwriting new work.
Make every write idempotent where possible
Network retries happen. If “add component” runs twice, you do not want duplicate sections. Accept an idempotency key for creation and publication operations. For replacements, define exactly which property is being set so calling the same tool twice produces the same state.
Return the new version and a concise diff after every write. The agent can then confirm what changed rather than assuming the call worked.
A dependable agent workflow
Use this sequence for real editing sessions.
1. Establish scope
Tell the agent which site, page, breakpoint, and outcome are in scope. State constraints such as “keep the existing brand colors” or “do not publish.”
2. Inspect before editing
Have the agent list the relevant pages and inspect the exact elements. A useful prompt is:
Inspect the homepage hero and explain which elements you would change to make the product value clearer. Do not edit yet.
This catches misidentification before a write.
3. Ask for a short plan
For a multi-element change, require the agent to list the intended edits. The plan should refer to actual element identifiers or page sections discovered through tools.
4. Apply a small batch
Change one coherent section. Large, site-wide transformations are difficult to review and rollback even when each individual tool call is correct.
5. Preview and validate
Render the draft, check responsive behavior, verify links, and inspect the diff. For visual changes, test at more than one viewport.
6. Publish explicitly
Only invoke the production publish tool after review. Record the actor, source version, destination version, timestamp, and deployment result.
Prompts that produce reviewable results
Weak prompt:
Make the site better.
Better prompt:
On the homepage only, inspect the hero and pricing section. Keep the existing typography and blue brand color. Rewrite the hero headline and supporting copy for founders converting Framer sites to Next.js. Do not change layout or publish. Show the text diff and create a preview.
For a structural task:
Add a three-item proof section below the hero using the existing card component. Reuse current spacing tokens, do not introduce a new font, and keep every statement factual. Check mobile stacking and stop before publishing.
The better prompt defines scope, invariants, review output, and release boundary.
Protect against prompt injection in website content
Web pages and CMS entries are untrusted data. A page can contain text that looks like an instruction to the agent. The host and server should treat retrieved content as content, not authority.
Practical safeguards include:
- tool descriptions that state what the tool may and may not do;
- server-side authorization independent of model instructions;
- confirmation for sensitive actions;
- rejecting external URLs or file paths outside allowed domains;
- validating every identifier against the authenticated site;
- never returning secrets inside resources;
- logging the tool name, arguments, actor, and result;
- rate limits and size limits;
- a reversible version for every accepted write.
The MCP project maintains security best practices. Review them during implementation and when upgrading protocol versions.
Avoid the “arbitrary code” shortcut
It is tempting to expose run_javascript, execute_shell, or write_any_file because one powerful tool can handle every request. It also bypasses most of the safety and validation benefits of MCP.
Prefer explicit website tools. If code execution is genuinely required, isolate it from production credentials, restrict its filesystem and network access, impose time and memory limits, and make its output a proposed patch rather than an automatic deployment.
Audit and rollback are product features
Store enough information to answer:
- who authorized the connection;
- which host called the tool;
- which site and version were targeted;
- what arguments were accepted;
- what changed;
- which validation ran;
- whether the change reached production;
- how to restore the previous version.
Do not rely only on conversational history. Tool calls may come from different hosts, and chat transcripts are not a deployment ledger.
Measure whether the agent workflow helps
Useful product metrics include:
- edits accepted without manual correction;
- validation failures caught before publishing;
- time from request to reviewed preview;
- rollback rate;
- most frequently called tools;
- authorization or stale-version rejections;
- production errors attributed to agent-created releases.
The goal is not maximum tool calls. The goal is a shorter path from intent to a correct, reviewable change.
Production checklist
Before enabling MCP editing for customers, confirm:
- read, draft-write, and publish permissions are distinct;
- every target uses stable identifiers;
- stale versions cannot overwrite new changes;
- create and publish operations support safe retries;
- write responses include a diff and new version;
- previews never mutate production;
- publish is explicit and logged;
- secrets never appear in resources or tool output;
- untrusted page content cannot grant permissions;
- rate, payload, and domain limits are enforced;
- rollback has been tested, not merely documented.
MCP provides the connection standard. A trustworthy website editor comes from the capabilities and boundaries you build on top of it.