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
| Area | Behavior |
|---|
| Reading and lookups | The same read tools for contacts, companies, opportunities, audiences, emails, forms, workflows, campaigns, folders, and sync. |
| Building knowledge | The same skill references for emails, forms, workflows, and filters. (Over MCP your client loads them with the skill tools; in chat they load automatically.) |
| Hard limits | Neither can send, schedule, publish, activate, delete, or externally sync. Those are always manual steps in Conversion. |
| Workflows are create-only | To change a workflow, create a new one. There’s no edit flow for an existing workflow in either place. |
What’s different
Creating new assets
Both surfaces build new emails, forms, and workflows, and the result is the same: the asset lands live but dormant, an unpublished draft you publish, send, or activate yourself. The path there differs:
- In chat, a new build is staged as an artifact: a preview you review and apply. Nothing is created in your workspace until you apply it.
- Over MCP,
create_email, create_form, and create_workflow create the asset directly; there’s no artifact step. The asset is still dormant, but it exists in your workspace the moment the tool runs.
Editing existing assets
This is the main difference. The two surfaces take opposite approaches to changing an asset that already exists.
In chat: reviewed before anything changes. When Conversion AI changes an existing email or form, the proposed version is staged as an artifact: a preview you review and apply. Nothing changes in your workspace until you apply it. Other edits (audiences, campaigns, renames, and similar) are written directly, but only after an in-product Allow / Deny approval.
Over MCP: raw, immediate edit tools. There’s no artifact and no in-product approval. 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.
| Chat | MCP server |
|---|
| How an edit is expressed | An artifact you apply, or an approval prompt | A direct call to a raw edit tool |
| When it applies | After you apply or approve it in Conversion | Immediately |
| Review step | Artifact preview or Allow / Deny prompt, in-product | None in Conversion; your client decides |
| Reads during the change | Show the current state until you apply | Reflect the change as soon as it’s applied |
| Partial updates | An artifact carries the complete new version | Each call is applied as sent; set only the fields you change |
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).
The MCP server doesn’t create artifacts; creates and edits go straight to the asset. Artifacts remain how chat stages email, form, and workflow builds, and artifacts staged in chat can still be listed and read over MCP. Approvals and confirmation
In chat, sensitive writes pause on an in-product Allow / Deny approval, and email, form, and workflow builds are staged as artifacts you 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
| Capability | Chat | MCP server |
|---|
| Read and look up data | ✓ | ✓ |
| Create assets (live but dormant) | ✓ | ✓ |
| Edit existing assets | Artifacts and in-product approvals | Raw edit tools, applied immediately |
| In-product Allow / Deny prompts | ✓ | Client-controlled |
| Universal Business Context applied | ✓ | ✗ |
| Sandbox, files, image upload | ✓ | ✗ |
| Send / publish / activate / delete | ✗ | ✗ |
