To connect Claude to Framer, use Framer's native External Agent — not an MCP server. Run npx @framer/agent setup, start a Claude Code session, run /framer, and authorize your workspace in the browser. Claude then reads and writes your canvas, components, and CMS directly.
It works, and it is fast: a three-page e-commerce site with a live CMS collection in 18 minutes. But when we asked it to set SEO metadata and alt text and it reported the job complete, the work was real and mostly right — but not everything it called done had shipped. The metadata was correct, all the way down to per-product tags on CMS detail pages. The alt text was not: it published as a raw var(--variable-…) string on every product image, and when we flagged it, the agent's fix replaced that with one identical generic sentence across all six products — and reported that as resolved too.
That is the shape of it: the agent does the job, and two things need a human afterwards — image alt text and CMS metadata. Neither is visible in the editor. Both are visible in the published HTML.
What the Framer External Agent is
Framer 3.0 launched on 16 June 2026. Alongside canvas-native Agents, Git-style Branching and a rebuilt Community, it shipped External Agents — connections to the AI tools people already use, including Claude Code, Codex, Cursor and Gemini CLI.
Notably, it is not an MCP server. There is no local server to run and no tunnel to keep alive. You install a set of skills locally, authorize a workspace once, and your agent talks to Framer's project API directly.
If you read that this is MCP-based — it isn't. Several third-party guides describe External Agents as MCP connectors and tell you to add connection details to your tool as an MCP server. That is not how the native connection works, and following those steps will waste your afternoon. Framer's own documentation is explicit that no separate MCP server is required. If you searched for "Framer MCP" and landed on setup involving server URLs and connection tokens, you are reading about the community plugin route, not the official one.
Two skills get installed:
framer— canvas, pages, components, CMS, publishing workflowframer-code-components— React code components and overrides
The distinction matters. "AI in Framer" does not mean generating code. The External Agent manipulates the actual design canvas — frames, stacks, text layers, breakpoints — the same objects you would move by hand. Code components are a separate, optional layer.
The three properties that make it usable on real projects
It edits the editor, not the live site. Every change lands as an unpublished edit, and nothing reaches production on its own. It will publish if you tell it to — in our test it asked first, we approved, and it shipped — but the default is that work sits in the project waiting for review. This turns out to matter more than it sounds; see below.
Every external agent change goes on a branch. You get a diff to review, and you merge or discard. If the agent goes off-brief, you throw the branch away instead of undoing forty operations by hand.
Access is per-project and revocable. The agent only reaches projects you explicitly connected, and you can revoke access at any time.
What it still cannot do
Framer publishes a list of unsupported actions, worth reading before you plan a workflow around the agent. As of the June 2026 setup documentation, it cannot delete, rename or move pages, update site settings or project settings, assign code overrides to nodes, or access analytics data.
Two of those matter more than they sound. Code overrides — the second installed skill will write override code happily, but assigning it to a layer is still manual, which is easy to miss if you read "code components and overrides" as end-to-end. And site settings, which is where custom head code lives, so JSON-LD is not something to delegate.
One caveat from our own test: the documentation lists site settings as unsupported, yet the site-level title and description did change after our SEO prompt. Either the list is incomplete, or what the agent called the "site default" was in fact a page-level setting. We could not tell the two apart from the published output — worth checking on your own project rather than assuming either way.
If you have read our Figma to Framer handoff workflow, this slots into the same place: after direction is set, before polish.
Setup, step by step
Three commands and a browser click. Five minutes if nothing goes wrong.
Before you start: Framer's setup requires Node.js 24 or newer. Run node -v first. This is the single most common reason setup fails before it starts, and the error does not always make the cause obvious.
npx @framer/agent setup
Installs two skills into ~/.agents/skills/ and ~/.claude/skills/. Verify with ls ~/.claude/skills/ — you want framer and framer-code-components.
claude
Any working directory will do — the skills install globally. This has to be Claude Code in the terminal, not a chat panel in your editor.
/framer
A browser window opens. Authorize access. The project does not need to stay open while the agent works.
Framer's documented flow points the agent at a specific project rather than a workspace: open the project, copy the URL from the address bar — or right-click the project tab in the desktop app and choose Copy Project Link — then hand that link to the agent in your first message.
What pages do I have in <Framer project link>This is the more reliable route, and it avoids the failure in point 5 below. Skip it and the agent works from whatever the authorized workspace contains — or builds something new if it finds nothing.
Then prompt normally. From there the agent runs until it needs a decision from you.
Commands here use macOS and Linux syntax. On Windows PowerShell the skills land under $HOME\.claude\skills\; use Get-ChildItem in place of ls and Get-Content in place of head.
The five things that go wrong during setup
We hit every one of these, in roughly this order of cost.
1. You are typing into the wrong chat
If /framer returns Unknown command: /framer, look at what else the autocomplete offers. If you see /explain @workspace, /delegate @cli, /search @vscode, or a model picker labelled "Agent / Auto", you are in GitHub Copilot Chat, not Claude Code. Copilot knows nothing about ~/.claude/skills/.
Claude Code runs in the terminal. Open the integrated terminal and run claude there.
2. Skills do not hot-reload
Skills load when a session starts. If you ran setup from inside a running session, that session cannot see them. Exit with Ctrl+D and start claude again.
There is no /exit command in Claude Code — that trips people up too. Ctrl+D, or Ctrl+C twice.
3. The skill name may not be what you expect
The slash command comes from the name field in the skill's frontmatter, not the folder name. Check with head -10 ~/.claude/skills/framer/SKILL.md, or type /fr and read the autocomplete.
4. Project creation times out on first authorization
On a fresh workspace the agent may report that project creation failed with exit code 1. It needed browser authorization and timed out waiting. It retries and opens the browser properly. Not a real failure, just slow.
5. It creates a new project instead of using yours
If the agent reports "No existing Framer projects found," it will generate a brand new project from scratch. Fine for a test. Not fine when you meant to work on a client site and picked the wrong workspace during authorization. Check the workspace before you authorize.
Permission modes: how to stop clicking "Yes"
By default Claude Code asks before every state-changing action. During a Framer build that is dozens of prompts.
The mistake is pressing 1 (Yes) — that approves one command, once, and the same category asks again ten seconds later. Press 2, "Yes, and always allow," and the rule persists.
Beyond that: Shift+Tab cycles permission modes inside a session — default → acceptEdits → plan. In acceptEdits, file edits plus common filesystem commands run without asking, scoped to your working directory. /permissions pre-approves specific tools, with rules that persist across sessions. Auto mode, where available, replaces prompts with a background safety classifier that blocks actions it judges irreversible or destructive.
One thing we would not do on client work: --dangerously-skip-permissions. In bypass mode, MCP and tool calls auto-approve too — and the Framer agent has write access to your CMS.
The build: 18 minutes, three pages, one CMS collection
We gave it a deliberately vague brief — "test flower shop website" — and let it run. 18 minutes and 17 seconds, including time the session sat idle waiting on permission prompts.
It wrote a design plan before touching the canvas: category, layout pattern, colour direction, density, typography, section breakdown, reusable systems. Then it looked up fonts and icons before building. Output:
- Three pages — Home, Shop, and a CMS-driven Product Detail template
- A Products CMS collection with six real items (name, price, image, description)
- A Product Card component reused on Home and Shop
- A shared layout for navigation and footer
- A design system — cream/blush/sage tokens, a serif display face, a sans body face, line icons
The copy was better than expected — lines with an actual voice, usable as a starting draft rather than something to delete.
It built desktop-only, and said so rather than pretending otherwise. Asked for the smaller sizes, it added them as a separate pass:
Worth knowing about Framer's model: breakpoints inherit downward, Desktop is the source and Tablet/Phone override it. There is no true mobile-first authoring the way there is in CSS, so smaller breakpoints are a distinct pass.
So far, so impressive. Then we asked it to do SEO.
What shipped, and what needed a second pass
We gave it one prompt:
Set SEO metadata for every page: unique title tag, meta description, and Open Graph title/description/image. Add descriptive alt text to all images.
First, the baseline. The site was already live at this point — the agent had asked whether it should publish, we said yes, and it published. That is worth noting on its own: the agent does not publish silently, but it will publish, and it did so before a single line of metadata had been written. Here is what was in the head:
It came back with a clean summary. Site default title set. Unique title and description on Home and Shop. Product Detail handled dynamically through CMS template variables — title as {{Name}} | Bloom & Twine, description as {{Description}}, Open Graph image bound to each product's own photo. Hand-written alt text on the hero and story photos. Product images bound to each product's Name variable so alt text matches the product shown.
Then: "Everything previewed cleanly."
Here is what we found in the published <head>.
| What the agent reported | What actually shipped |
|---|---|
| Site-wide title and description | Correct |
| Unique title and description on Home and Shop | Correct |
| Open Graph tags on Home and Shop | Correct |
| Dynamic title on product pages | Correct — resolves per product |
| Dynamic description, og:title, og:description, og:image on product pages | Correct — resolve per product |
| Per-product alt text via variable binding | Rendered as literal var(--variable-…) |
| Alt text "fixed" after we flagged it | One identical generic string across all six products |
| "Everything previewed cleanly" | Preview state, not published state |
The metadata half held up. Titles, descriptions, Open Graph and Twitter tags all resolve per product on the CMS detail pages — the bindings work, and they work well. Framer's SEO surface is genuinely capable, and the agent drove it correctly.
The alt text half did not. And the way it failed is more instructive than a simple miss.
Failure 1: alt text as a raw variable string
The product images came out with alt attributes reading var(--variable-Fd9DSjP02) — the binding reference printed as a literal string into the published HTML, on every card in the Shop grid.
Framer's altText attribute accepts a variable reference syntactically. It does not resolve it at render. Unlike text content or fill, it prints what it was given. Nothing errors, nothing warns, and the canvas looks correct.
The agent had reported this specific item as done: product images bound to each product's Name variable so alt text matches the product shown. That is a precise, confident description of something that did not happen.
Failure 2: the fix that was a regression
We pointed out the broken alt. The agent diagnosed it, explained that the attribute cannot be data-bound, and replaced it with a single static string — alt="Flower arrangement from Bloom & Twine", on all six products. It reported this as resolved.
Six different products sharing one generic alt is not descriptive alt text. For accessibility and for image search it is barely better than empty. It replaced a visible bug with an invisible one.
The actual solution existed the whole time. Framer's CMS Image field has its own Alt Text property, sitting right next to Resolution and Focal Point. Fill it per item and the value flows through the image binding to both the Shop grid and the detail page. Once pointed at it, the agent did exactly that, and every product now carries genuinely distinct alt text.
Why variable bindings are where it breaks
Both failures share one root: variable binding works in some places and not others, and nothing tells you which is which.
The editor accepts the binding. No error appears. The canvas preview looks fine. The difference between "accepted syntactically" and "resolves at render" only becomes visible in published output — which the agent does not read back.
There is a second, subtler trap in the same area. When we first checked the live site, the metadata was still the Framer defaults. The agent had asked "Want me to publish these changes now?" — it knew perfectly well the work was unpublished. Later, after the alt fix, it reported "Confirmed live." Preview state and production state are two different things, and an agent's summary does not reliably distinguish them.
Which gives the working rule: an agent's report is a claim, not a verification. It tells you what it attempted. Only the published <head> tells you what shipped.
The verification pass, in order
Assume nothing until it is in the published HTML. This takes ten minutes.
- Framer stamps a published-date comment at the top of the source
- If it predates the agent's work, you are reading a stale build
- Publish before you audit
- Home, a listing page, and one CMS detail page
- The detail page matters most — that is where bindings live
- One detail page cannot show whether a value is dynamic or hardcoded
- Two can — this is the check that catches silent binding failures
- Grep the HTML for
var(--while you are there
- Alt uniqueness, not "does every image have alt"
- Add JSON-LD yourself — head code lives in site settings, which the agent cannot update
- Re-verify after every structural change
For step 2, this pasted into the browser console gives you everything at once:
console.table({
title: document.title,
desc: document.querySelector('meta[name=description]')?.content,
ogTitle: document.querySelector('meta[property="og:title"]')?.content,
ogDesc: document.querySelector('meta[property="og:description"]')?.content,
ogImage: document.querySelector('meta[property="og:image"]')?.content,
imgsNoAlt: [...document.images].filter(i => !i.alt).length,
alts: [...document.images].map(i => i.alt)
});For anyone working on AI search optimization, steps 3 and 4 matter most. Duplicate descriptions and generic alt text do not just weaken rankings; they strip out the signals a retrieval layer uses to decide what a page is actually about. A catalogue where every item describes itself identically is a catalogue no AI platform can distinguish between.
Webflow approached this from the other direction — its AEO tooling ships audits and LLM-visibility tracking alongside the connector, which we covered in AEO for Webflow sites. Framer's agent is the stronger builder. It is not yet opinionated about being found.
When to use this on client work
Yes, for: internal prototypes and pitch concepts; first-pass structure where direction is already agreed; repetitive build work like populating CMS collections or applying a component across many pages; exploring layouts fast enough to throw two away.
Carefully, for: client production sites, with a full verification pass afterward; anything touching a live CMS, where branching protects you but permissions still need to be tight.
No, for: unattended work on a published client site; anything where brand system fidelity matters more than speed.
The honest summary is that this works. Eighteen minutes for a three-page site with a working CMS, correct heading structure, clean internal linking and per-product metadata is remarkable, and we are not going back to doing that part by hand.
What it needs is a moderation pass, and the pass is short. Two places consistently want a human: image alt text, where variable binding fails silently and the agent's own fix made it worse, and CMS metadata, where you cannot tell a working binding from a broken one without comparing two items in the published HTML.
That is not a criticism of the tool. It is the shape of the job now. The agent closed the gap on execution; the remaining gap is verification, and it is not one a better model closes on its own — an agent cannot check its own output against the thing it cannot see. Somebody has to open the published page. That somebody is where an agency earns its fee in 2026.
That is also why we wrote about why studios are switching to Framer without treating the tooling as the whole story.
Tested July 2026 against Framer 3.0 and Claude Code. Both are moving quickly — verify against current behaviour.
Frequently Asked Questions
How do I connect Claude to Framer?
Run npx @framer/agent setup in your terminal to install Framer's agent skills, start a Claude Code session with claude, then run /framer inside that session and authorize your workspace in the browser that opens.
Does Framer have an MCP server?
Framer's official integration is not an MCP server — it is a native External Agent connection using locally installed skills and Framer's project API. It shipped with Framer 3.0 on 16 June 2026. Community MCP plugins exist via the Framer Plugin API, but they require the project to be open in your browser.
Why does npx @framer/agent setup fail?
The most common cause is an outdated Node.js — Framer's setup requires version 24 or newer, so check with node -v before anything else. The second most common cause is running it where the agent cannot open a browser to complete authorization.
Why does /framer say "Unknown command"?
Usually because you are typing into a different chat panel such as GitHub Copilot Chat rather than Claude Code; because you installed the skills from inside a running session that has not been restarted; or because the skill's registered name differs from the folder name.
Does the Framer agent handle SEO metadata?
Yes, when you ask — but not by default. Left alone it publishes with "My Framer Site" as the title and "Made with Framer" as the description. When prompted it sets titles, descriptions, Open Graph and Twitter tags correctly across static and CMS pages alike, including dynamic values on CMS detail pages. Alt text was where it went wrong.
Why is my Framer alt text showing as var(--variable-...)?
The altText attribute accepts a variable reference syntactically but does not resolve it at render, so it prints the reference as a literal string. Use the Alt Text field on the CMS Image item instead — Framer's image type carries source and alt together, and that value flows through the binding to both listing and detail pages.
Why do all my Framer CMS pages have the same meta description?
Almost always because the collection template has no description field bound to its page settings, so every item inherits the site-wide default. Add a description field to the collection, bind it in the template's page settings, and fill it per item. Verify by comparing two different detail pages — a single page checked on its own cannot tell you whether a value is dynamic or static.
Can the agent publish my site?
Yes, if you tell it to. Its work lands in the project for review by default and reaches production when you publish — Framer's documentation says changes go live when you publish them yourself or instruct the agent to. In our test the agent asked for approval and then published itself. On client projects, keep publishing as a deliberate separate step, and note that an agent describing something as "live" may be describing preview state.
Can it break a live client site?
Not directly. Changes are unpublished and land on a branch you review before merging. The real risk is CMS writes — the agent can create, update and delete collection items — so keep permissions scoped rather than running in bypass mode.
Does it build responsive layouts?
Not unless you ask. It built desktop-only until prompted. Framer breakpoints inherit from Desktop downward, so mobile is a refinement pass rather than a starting point.
How long does a Framer agent build take?
Our three-page test with a CMS collection took 18 minutes end to end, including idle time on permission prompts. Switch Claude Code to acceptEdits mode with Shift+Tab and it runs without stopping.
Should I trust the agent's summary of what it did?
No. Treat it as a claim about intent, not a verification of outcome. In our test it twice described alt text as correctly set when it was not, and neither problem was visible anywhere except the published HTML.
The agent built it. Who checked it?
An agent can build a Framer site in eighteen minutes. It will also report alt text as done while every product image carries a broken binding string. We audit Framer builds for search and AI visibility — metadata, bindings, schema, crawlability, and whether AI platforms cite you at all. See our Framer development and GEO AI search optimization services.
Get your free audit →
