Skip to main content
The MCP server and Conversion AI in chat run on the same engine: the same tools against the same workspace data. Most of what you can do is identical. A few things behave differently because an external client, not Conversion, is driving the model and there’s no in-product chat surface to review changes in.

What’s the same

What’s different

Editing existing assets

This is the main difference. The two surfaces take opposite approaches to changing an asset that already exists. In chat: a reviewed edit list. When Conversion AI edits an existing email, form, audience, or campaign, each change is a proposal, not an immediate write. Proposals accumulate into a pending edit list for the turn. Nothing changes while the AI works, and reads keep showing the asset’s current state. When the turn ends, all edits to each asset are merged and shown to you to approve or reject, per asset. Only approved edits are applied. Over MCP: raw, immediate edit tools. There’s no proposal step and no edit list. The MCP server exposes raw edit tools (update_email, update_form, update_form_draft, update_audience, add_audience_contacts, update_campaign, and the campaign membership and token tools), and each one applies its change the moment your client calls it.
Because raw edit tools apply immediately, the responsibility for confirmation moves to your client. Send only the fields you intend to change, and read the current asset before replacing a body or design (those fields take the complete definition, not a diff).
Conversion AI no longer uses “artifacts” (the older preview-then-apply object) to stage changes. Chats use the pending edit list described above; the MCP server uses raw edit tools. Existing chats that still have staged artifacts can read them over MCP, but new work doesn’t create them.

Approvals and confirmation

In chat, sensitive writes pause on an in-product Allow / Deny approval, and merged edit lists are approved per asset before they apply. Over MCP, those prompts don’t appear; Conversion has no chat surface to show them in. Instead, each tool is annotated with whether it reads or writes, and your client decides when to ask you to confirm. Confirmation behavior depends entirely on the client you connect.
Review your AI client’s settings so you understand when it will run a write tool without asking. The safeguards that gate writes in chat are not enforced by the MCP server.

Files and the sandbox

Chat has a sandbox: an isolated Linux environment for reading attachments, running scripts, and generating files to download. The MCP server has no sandbox and no file tools. Working with files, running code, and uploading generated images to your media library are chat-only. Your AI client may have its own file handling and code execution, but that runs in your client’s environment. It has no connection to Conversion and can’t reach your workspace except through the MCP tools.

Universal Business Context

In chat, your Universal Business Context (your workspace Description, Instructions, Documents, and brand voice samples) is loaded for Conversion AI at the start of every session, so it follows that guidance automatically. Over MCP, it isn’t. Your AI client is the model, and Conversion only exposes tools; it doesn’t control your client’s prompt, so it can’t supply that context. The connected client knows nothing about your business beyond what it reads through tool calls.
If you want the client to follow your brand voice or operating rules, include that guidance in your client yourself, for example in its system prompt or project instructions.

How skills load

Both surfaces use the same building references. The difference is delivery: in chat they’re loaded for the AI automatically when relevant; over MCP your client calls a skill tool (learn_email_building, learn_form_building, learn_workflow_building, learn_statement_semantics) to load the reference before it builds.

At a glance