Introduction
Framer now ships two different AI agents. The native Agent lives in the editor’s Properties panel and builds inside your open file. External Agents connect from outside Framer, through a CLI, using tools like Claude Code, Cursor or Codex, and can edit the whole project rather than one page. Neither one is MCP.
We use both to run this exact article, so this is a working comparison rather than a marketing one: what each can build, how to set External Agents up, what they cost, and where a “Framer MCP” search actually leads.
What is a Framer Agent?
“Framer Agent” now covers two separate things, and mixing them up is where most of the confusion starts. The native Agent is the AI assistant built into the Framer editor itself. External Agents are outside AI tools, connected to a Framer project through Framer’s own CLI, that can read and change the project without anyone opening the editor at all.
Native Framer Agent | External Agents |
|---|---|
Runs inside the editor’s Properties panel | Runs in a terminal or coding tool, connected through the Framer CLI |
Works on the page, section or element you have selected | Can work across the whole project: pages, CMS, code files, styles |
Builds native Framer layers and components | Builds native components and custom React code components |
No setup, it is already in the panel | One time setup: browser authorization or an API key |
Uses the workspace’s shared monthly AI credits | Uses the Framer Server API, free during its beta |
Framer Agent vs MCP: Why It’s Not the Same Thing
Plenty of people go looking for “Framer MCP” and land here confused, us included at first. Model Context Protocol is a general open standard, introduced by Anthropic in late 2024, that lets an AI model call outside tools and data sources in a structured way. It has nothing to do with Framer specifically, and dozens of unrelated products use it.
Framer’s own help center has a question for exactly this: do you need to set up a Framer MCP server? The answer is no. Connecting Claude Code, Cursor, Codex or Gemini CLI to a project gives that tool direct access to your canvas, components, CMS and project context, without any manual MCP setup, through Framer’s own connection instead. A dedicated FAQ entry for the question is itself a sign of how often it comes up.
What Framer actually built is a CLI and a Server API. An external tool runs npx @framer/agent setup, calls a /framer command, and talks to your project through that API rather than through an MCP server. Functionally it does a similar job to MCP, giving an outside AI structured access to a live project, but it is Framer’s own connection, not MCP itself.
Unofficial third party “Framer MCP” projects exist too, built by individual developers for narrower jobs like scripting Framer plugins. They are separate from Framer’s own external agent connection and are not what this article covers.
The Native Agent: Built into the Editor
The native Agent reads the context of whatever it is working in, then builds directly inside the live file rather than a separate mockup. Describe a component, a section or a piece of interaction, and it generates editable Framer layers we can inspect and adjust like anything else on the canvas.
It goes further than most AI tools we have tried, which tend to hand back a rough draft that still needs rebuilding. It produces ready to use components complete with Property Controls, so the result is adjustable in the panel the same way any hand built Framer component is. We can also pick which model handles the request, GPT, Sonnet, Opus or Fable, so the model matches the task instead of defaulting to whatever is on.
Starting a Native Agent Session
Select Agent in the right hand Properties panel and a prompt field appears. Send the prompt, and within a minute or so a working component shows up on the canvas. Keep chatting in the same session to fine tune it, or select the component first so a follow up prompt only touches that selection.
Prompts That Actually Work
The trick is keeping instructions clear and focused. Too vague, and we get generic results. Too specific, and there is no room left for the Agent to do anything useful. Here is a simple framework we follow:
Goal: “Build a [type] component that [main function]”
User actions: “People should be able to [specific interactions]”
Design and layout: “Include [styling or layout details]”
Adjustable features: “Add settings for [elements you might want to tweak]”
Reference: attach a screenshot, mockup or live URL, the Agent can use it as visual context
Not so great: “Create a contact form”
Better: “Design an interactive contact form for a portfolio page. Include fields for name, email, phone number and message, a dropdown for inquiry type, a live confirmation message after submission, and a send button that changes color on hover.”
What Costs the Most Here
The native Agent is genuinely good at one thing External Agents are not: it already knows the current design, the page you are on and the element you selected, so a follow up prompt needs almost no re-explaining. That convenience is also why it is the pricier option per task. It draws on a shared monthly AI credit allowance for the whole workspace, roughly 500 credits a month on the Free plan and more on paid site plans, and a big multi step request spends a lot faster than a small text edit. Credits reset on the first of the month and pause the feature once they run out. We cover the plan tiers themselves in Is Framer’s Pricing Worth It.
External Agents: Working on the Whole Site
External Agents are not limited to components. Once connected, they can read and write CMS collections, restructure pages, edit code files, update styles, handle localization and redirects, and publish, all from outside the editor.
Setup takes two real paths:
Browser authorization: run
npx @framer/agent setuponce, then inside Claude Code, Cursor or Codex, run the/framercommand and paste in your project link. The first time it connects, Framer opens your browser and asks you to allow the connectionAPI key: generate one from Site Settings, under General, for the project, and hand it to your agent instead. Useful when there is no browser around to authorize from
Either way, the agent produces the same two kinds of output as the native Agent, plus one more: native Framer components made of ordinary layers, and custom code components written in React with real property controls, type checked and debugged in the same session.
Two Things External Agents Are Actually Good For
The Boring, Repetitive Stuff
This is the least exciting use case and the one that saves the most time. Point an External Agent at a CMS collection and ask it to fill in missing SEO descriptions, normalize slugs, fix a broken reference, or update fifty items the same way at once. It is exactly how this article got written and edited, as a CMS content update, not a canvas session.
Screenshot to Design Replication
Hand an External Agent a screenshot and ask it to rebuild the layout in Framer. It gets you most of the way there, close enough that finishing it is faster than starting from nothing, but it is not a ship it as is result. Spacing, font weights and small interaction details still need a manual pass afterward.
Cost: Shared Credits vs Your Own Coding Tool
The two paths are billed differently today. The native Agent spends from Framer’s own AI credit pool, shared across the workspace and capped by plan. External Agents run through Framer’s Server API, which is free of charge while it is in beta, so what you are actually paying for is whichever coding tool is doing the thinking, Claude Code, Cursor or Codex, on its own subscription or API usage. That is usually a more generous ceiling than a shared workspace credit pool, though Framer has said the API will likely move to usage based pricing once it leaves beta.
Either side benefits from matching the model to the task. Both the native Agent and most external tools let you switch models mid session, so a cheap, fast model can handle a bulk CMS cleanup while a stronger one is saved for an actual code component or a genuine refactor.
When to Use Which
A rough rule that has held up for us:
Reach for the native Agent for a one off component or section while you are already looking at the canvas
Reach for an External Agent for anything repeatable: CMS cleanup, bulk content edits, localization, or a code component that needs real logic
Skip both for anything with compliance requirements, security sensitive API calls, or styling that has to match a brand system exactly
Treat either one as a first draft to refine, never as the final, unreviewed answer
Conclusion
Both agents are good, and getting better fast, and this is clearly where building in Framer is heading. But neither one is a hands off replacement yet. The native Agent still needs a look before we trust its first draft, and an External Agent rebuilding a screenshot still needs a manual pass before it ships. Agents are the future of this work, not a finished substitute for doing it. For the wider picture beyond agents alone, see our piece on Framer AI in Modern Web Design.
