MCP Server vs Built-In AI Chat: Who Pays for the AI

A website builder can give you AI in two ways. It can put its own chat box inside the product and bill you for every message, or it can run an MCP server and let the assistant you already pay for do the work. Both can build the same site. They differ in who pays for the AI, what the assistant knows, where the conversation lives and who holds the result.

This post is part of our MCP guide. It compares the two models honestly, including where the built-in chat is the better choice and what MCP costs you that a chat box does not.

The two models

Built-in chat. The builder runs its own model behind a chat panel. You describe a change, the panel makes it, and the builder meters the work in credits or tokens. Lovable prices per message, and its pricing page gives examples: 0.50 credits to make a button gray, 0.90 to remove a footer, 1.20 to add authentication. Bolt meters in tokens, and its pricing page explains that most token use comes from syncing the project's files to the AI, so the larger the project, the more tokens each message uses.

MCP server. The builder exposes its actions as tools through the Model Context Protocol, described in the protocol documentation. Your own assistant, whether that is Claude, ChatGPT, Claude Code, Codex or Cursor, calls those tools. The builder's job is to make the tools complete and safe.

Some builders, including Beste, offer both: an assistant inside the editor for people who want it there, and an MCP server for people who already have an assistant. The question is which one you should reach for, and when.

A third case: MCP that forwards to the builder's AI

"Has an MCP server" no longer tells you which model you are in. Some servers simply pass your request to the builder's own agent.

Lovable's MCP server is a clear example. Its documentation lists a send_message tool that sends a chat message to the project's AI agent and waits for the response, and it says standard Lovable credits apply to create_project and send_message calls, while other tools are free. That is useful: you can drive Lovable from Claude or Cursor, read diffs and deploy without opening the editor. But the editing is still done by Lovable's agent, and still billed as Lovable credits.

A tool-level server works differently. Your assistant reads the page, decides what to change and calls the edit itself. Beste's server is built this way, with tools such as get_page_markdown, update_section and publish. There is no second model in the middle, so there is no second AI bill.

When you compare builders, look past the label and ask one question: when my assistant asks for a change, who writes it?

Who pays for the AI

With built-in chat, you pay the builder for every change, for as long as the site keeps changing. That is fine for a one-off build and expensive for a site that changes every week. It is also a cost that is hard to see coming. A year of small requests, a price here and an opening time there, is not something anyone estimates at the start.

A rough picture, using Lovable's own examples: a site that gets four small changes a week sees around 200 changes a year. At 0.50 to 0.90 credits per small change, that is roughly 100 to 180 credits a year on maintenance alone, before any new pages. The exact cost depends on the plan, but the shape is the point: the bill grows with how alive the site is.

With a tool-level MCP server, the AI cost is a plan you already have. Claude's custom connectors over remote MCP are available on its Free, Pro, Max, Team and Enterprise plans, with Free limited to one custom connector, per Anthropic's support article. Codex is included in the ChatGPT plans listed on OpenAI's Codex pricing page. You are not buying AI twice.

A builder can still meter MCP edits on its own side. Beste counts them as AI agent edits: 150 a month on a Free project and unlimited on Pro, Team and Business, with reads never counted. What the builder charges for is the site, not the conversation.

What the assistant knows

This is the difference that matters more than cost, and the one people notice last.

A built-in chat knows the builder. It does not know your brand document, your old site, the spreadsheet of products your client sent, or the notes you keep in whatever tool you keep notes in. Every session starts from the builder's view of the world. Some builders let you store project knowledge for their agent, which helps, but it is one more copy of your context to keep up to date.

Your own assistant knows everything you have given it. If it is connected to your files, your email or your other tools, it can read the brief in one place and build the page in another. On beste.co, we keep the tone rules and glossary for each language in a document the assistant reads before it touches a page. A built-in chat could not read that document unless we pasted it in every time.

The practical effect is that an MCP session starts with context and a built-in session starts with a blank box.

Where the conversation lives

With built-in chat, the conversation is inside the builder. That is one more tab, one more history, one more place where a decision was made that you cannot find later.

With MCP, the conversation is wherever you already work. For us that is Claude Code in a terminal for long sessions, and Claude on a phone for a quick fix on a Sunday. The history of what was decided sits next to everything else we decided that week. Which client fits which kind of work is covered in Claude Connector, Claude Code or Codex: Which One to Build Your Website With.

Who controls the result

A built-in chat is usually tuned to act. It makes the change and shows it to you. That is a good default for a demo and a bad one for a live client site.

An MCP server can be built to be more careful, because it is a set of tools with explicit permissions rather than a model with a prompt. The things to look for:

Changes go to a draft, never straight to the live site.
Publishing is a separate tool that runs only when you ask.
Tools are labeled read or write, so the assistant knows what is safe.
Errors name the field, so the assistant fixes its own request.
Most changes can be undone in batches, and deletion needs a second step.
Access is granted per project and can be removed.

These are the guardrails in Beste's server, described on the MCP server page. The assistant is still your assistant, with your rules. The server simply refuses to let it do the dangerous thing in one step.

What MCP costs you that a chat box does not

It would be dishonest to say MCP is free of trade-offs. Three are real.

Setup. A chat box is there when you open the editor. MCP needs a connector added, a plugin installed or a command run once. It takes minutes, but it is a step.
Context. Every MCP server you connect adds its tool descriptions to the assistant's context. OpenAI's Codex pricing page advises limiting the number of MCP servers you use for exactly this reason, since each one uses more of your plan. Connect the servers you work with, not every one you find.
Rules are your job. A built-in chat comes tuned for its product. Your own assistant follows the rules you write. Without them, it is consistent with itself only by luck. What to write is in Writing Rules for Your Website Agent.

When built-in chat is the right choice

It is the right choice when the person building the site does not have an AI assistant of their own, or does not want one. A business owner who opens the editor once a month to update a page does not need Claude Code. For that person, an assistant inside the editor is the whole product, and it should be good. In Beste that assistant is Bestie, and it uses the same tools over the same server.

It is also the right choice for a first draft when you have nothing else to bring. If there is no brief, no old site and no rules, the context advantage of MCP is small.

When MCP is the right choice

It is the right choice when you already pay for an assistant and already keep your working context there. When you build many sites and want the same rules applied to all of them. When the site changes often and a per-message bill would be a surprise. And when you want the conversation and the decisions to live in your own tools, not in a vendor's panel.

For studios building client sites, it is also a pricing decision. The AI cost of a client site becomes part of your overhead instead of a line that grows with every request.

A quick way to decide

You have no assistant and edit once a month: built-in chat.
You already pay for Claude or ChatGPT and the site changes weekly: tool-level MCP.
You run several client sites with shared rules: tool-level MCP, with a rules file per client.
You want to drive another builder's AI from your editor: a forwarding MCP server works, but budget for its credits.

How this works in Beste

Beste runs both. Bestie, the assistant in the editor, serves people who want AI inside the product. The MCP server serves everyone else: the Connector for Claude on the web, desktop and phone, the Plugin for ChatGPT, and npx beste-agent@latest for Claude Code and Codex, with Cursor, Gemini CLI and Grok connected from the dashboard. The same 70-plus tools serve all of them, so a site started in one can be continued in another.