Framer MCP review: let the agent edit on a branch, keep the publish button

What Framer shipped today

Framer launched Framer MCP today, Oct. 22, 2026. MCP, the Model Context Protocol, is a standard way for AI tools to plug into other apps, and Framer now runs a remote MCP server at https://mcp.framer.com/mcp. Connect ChatGPT, Claude, Codex, Cursor or another client that supports remote MCP servers and OAuth, approve the connection with your Framer account, and the agent can work inside your projects. In Framer's words, "Your agent can work on the canvas, manage CMS content, publish your site, and more."

That covers the edits most site owners keep putting off. Framer's help article on what you can do lists new pages that work "across desktop, tablet, and phone breakpoints" using your existing styles and components, new CMS collections and items, imported content, and a review of metadata, headings and alt text. There's nothing to install on your computer, and the Framer editor doesn't need to be open, so someone can ask for a change from their phone where the AI client supports it.

So who is it for? Teams whose marketing site already lives in Framer and who already pay for an AI tool they like. Framer's own case for MCP over its built-in agent is practical: you work from the agent you already use, and "Your AI usage follows that agent's plan or credits." Framer doesn't list a separate price for MCP.

The word to plan around is in the announcement itself: publish. The rest of this review walks through the four settings that decide whether an agent's edit can reach your live site before a person has looked at it.

Which account the agent signs in as

Framer is direct about this. "The connection uses the permissions of the Framer account you sign in with," says the getting-started guide. The MCP page adds that once you approve the connection, the agent can work with "the canvas, components, supported project settings and CMS in projects your Framer account has access to."

Read that twice if you're about to sign in as the workspace owner. Framer's roles page says workspace members have access to every project in the workspace, and the agent inherits all of it: last year's campaign site, the half-finished redesign, the main site. The guide even suggests you give the agent the full project link if it opens the wrong one. It's a helpful tip and a small warning in the same sentence. We've written before about how an AI assistant will find the folder everyone forgot was shared, and this is the same problem with a publish button attached.

The cleaner setup is a separate Framer login for agent work, invited only to the project it should touch. Project members get access "only to the specific projects they are invited to," and on plans that support advanced permissions you can grant Design and Content while leaving Deploy off. Two costs come with it. Framer says members with edit access are billed, so that login is a paid seat. And whoever connects it to ChatGPT or Claude becomes the agent's operator, so decide who that is before anyone clicks Allow.

In a larger workspace, check one more thing. Framer's troubleshooting advice is to "Ask your workspace administrator whether plugins or MCP connections need approval." If nobody knows the answer, sort that out before anyone connects anything.

Branch first, main later

By default, Framer says, the agent's changes "stay in your project and don't affect the live site until you publish." That's true, and it's also the catch. Without a branch the agent is editing main, and main is the version that gets published. If a colleague publishes main this afternoon to fix a typo, the agent's unreviewed changes go out with it.

So make the branch part of the request every time. Framer's FAQ puts it plainly: "You can ask your agent to work on a branch". Its branches guide calls a branch "an isolated copy of your project where you can make changes without affecting main," and it covers canvas edits, CMS updates and page structure, not just one page. The review loop looks like this:

• Ask the agent to create a branch and make the change there.
• Publish the branch to get a preview URL you can send to whoever needs to see it. Publishing a branch "does not publish main," so the live site stays as it was.
• Open the branch, click Review Changes and read the diff.
• Click Apply if it's right. Applying updates main, but it doesn't publish anything.
• Publish main when you're ready.

If something slips through anyway, Framer says you can revert an applied branch from version history, and the changes move back into a draft. It's the same habit we recommend when you let an agent propose a catalog change before it writes live. The agent drafts, a person looks at the real thing, and only then does it count.

Who presses publish

Can the agent publish your live site? Framer's answer is "Yes, if you explicitly ask it to publish." The getting-started guide closes its review step the same way: "publish it yourself or ask your agent to publish." So unless the account can't publish, the only thing between an agent and your customers is one sentence in a chat window, and long chats are exactly where a loose "looks good, push it" slips in.

That's why the Deploy permission matters. Framer's roles page says that with staging turned off, "Only members with Deploy permission can publish changes directly to the live site." With staging on, any project member can publish to staging, and only Deploy holders can promote changes to the live site. Connect the agent through an account without Deploy, and that stray instruction has nowhere to go.

Our suggestion for most small teams is simple: the agent never publishes main. A named person does, after reading the diff. If your plan doesn't include granular permissions, write the rule down anyway, keep agent work on branches, and tell everyone who uses the connection. It's a policy rather than a lock, so it only holds if people know about it.

CMS edits deserve the same care. Framer's article on the older External Agents setup says that once connected, the agent "can read and write CMS collections, including creating, updating, and deleting items." Bulk changes are where agents save the most time, and also where one misread instruction rewrites every blog post at once. Ask for CMS work on a branch too, and spot-check several items in the preview, not just the first one.

Where it falls short, and the alternatives

Localization is the biggest gap. "Localization support is not available in Framer MCP at launch," the help article says. If you maintain translated pages, keep using the local @framer/agent CLI, which Framer says "still works for workflows like localization." According to Framer's setup guide, that route "runs on your computer and requires Node.js," and you start it with npx @framer/agent setup.

The CLI has limits of its own. Framer's External Agents article says it can't update some site or project settings like project names and domains, can't assign overrides to nodes, and can't access analytics data. Framer MCP is described as working with "supported project settings" without a list of which ones, so don't plan on handing it your domain setup. Framer also says both routes "remain supported while Framer MCP reaches feature parity," so expect these limits to move.

Here's how the three ways to bring an agent into Framer compare:

• Framer's built-in agent keeps the work inside Framer, and the branches guide shows it running on a branch too. Pick it if you'd rather not connect an outside AI tool to your site at all.
• The @framer/agent CLI is the choice for localization, or for a developer who already runs Claude Code or Cursor locally with Framer's skills installed.
• Framer MCP fits a team that already works in ChatGPT, Claude, Codex or Cursor and wants those tools to reach the site directly, from a laptop or a phone.

On price, as published: Framer lists no separate fee for MCP. The AI work is billed by your AI tool's plan, and a dedicated Framer login with edit access counts as a paid seat.

Verdict, and putting it into practice

Worth turning on for a Framer site that has a reviewer, not as a way to skip one.

Framer MCP is a sensible way to hand routine site work to an AI tool your team already uses: copy updates, new CMS items, alt text and metadata clean-up, a first draft of a new page. The guardrails are there, too. You get branches, a diff, preview URLs and the Deploy permission. None of them is switched on for the agent by default, though, so the setup is your job.

Before anyone connects it:

• Decide which Framer account the agent signs in as, and limit it to the one project it needs.
• Leave Deploy off that account if your plan offers granular permissions.
• Make "work on a branch" part of every request, CMS edits included.
• Name the person who reads the diff and publishes main.
• Keep localization on the CLI for now.
• Start small, say a homepage heading, and walk that one change through the whole loop before you hand over anything bigger.

Let the agent do the editing. Keep publishing with a person.

If you'd like help deciding what your agents may change on their own and what waits for a person, that's the kind of boundary we design in our AI applications and agents work. Tell us what you're connecting.

Related work: Howcast.