What to check before connecting an MCP server to marketing tools

What should a marketer check before connecting an MCP server to their tools?

Check five things: who built the server, what it can read and write, how it signs in, where it runs, and how you would undo its actions. An MCP server lets an AI assistant act inside your CRM, CMS, or analytics. That means the server deserves the scrutiny you would give a new hire with login access.

Marketing teams are connecting AI assistants to real tools faster than most IT reviews can keep up. A model that can read your HubSpot records, edit your Webflow pages, or pull your ad spend is genuinely helpful. It is also a new way for mistakes, or bad actors, to reach systems that matter.

This article is a practical checklist for non-engineers. It draws on the security best practices page in the Model Context Protocol specification, translated into the questions a marketing lead can ask before clicking connect.

What is an MCP server in plain terms?

An MCP server is a connector that lets an AI assistant use a tool on your behalf. The Model Context Protocol defines how assistants like Claude discover what a tool can do and call it. The server sits between the assistant and the tool, translating requests into actions like reading records or publishing a page.

Think of it as a translator with keys. The assistant says what it wants. The server decides how to do it and uses whatever access you granted. If you grant broad access, the translator can open a lot of doors.

I gave a longer introduction in what MCP servers are and why marketers should care. This piece assumes you already want to connect one and focuses on doing it safely.

Who built the server, and can you trust the source?

Start with provenance. An official server published by the vendor of the tool, such as a CRM or CMS company, is a different risk from an unknown package someone shared in a forum. Prefer servers from the tool's own vendor or from a maintainer you can identify, with public code and recent updates.

This matters more than it sounds. The MCP specification's security page describes how an attacker can distribute a malicious payload inside a server itself, or slip a harmful startup command into a client configuration. A server that looks helpful can still run code you never intended.

A quick provenance check takes five minutes. Who publishes it? Is the source code public? When was it last updated? Does the tool vendor link to it from their own docs? If you cannot answer those, wait.

What can the server read and write?

List every action the server exposes and sort them into read and write. Reading campaign stats is low risk. Deleting contacts, sending emails, or publishing pages is high risk. Connect with the narrowest access that does the job, and add write actions only when you have a specific reason and a way to review them.

The MCP specification calls this scope minimization. It lists common mistakes, including wildcard or omnibus scopes like full access, and bundling unrelated privileges up front to avoid future prompts. It recommends a progressive, least-privilege model, where a session starts with low-risk read operations and asks for more only when needed.

For marketers, the translation is simple. If the setup screen asks for full admin access to your CRM just to read deal stages, that is a red flag. Ask whether a read-only or limited role exists, and use it.

My rule for marketing tools is short: read first, write later, and write only with logging turned on.

How does the server sign in to your tools?

Look for a proper sign-in flow, usually OAuth, where you approve specific permissions on the tool's own consent screen. Be wary of setups that ask you to paste a master API key into a config file. Keys pasted into files tend to be broad, long-lived, and easy to leak.

The MCP specification is strict on one point here. It says MCP servers must not accept any tokens that were not explicitly issued for the MCP server. That rule exists because passing tokens straight through to other services breaks audit trails and lets a stolen token reach places it should not.

You do not need to audit the server's token handling yourself. You do need to ask whoever set it up two questions. Which account does this server act as? And can that access be revoked in one place without breaking everything else?

Where does the server run, and with what privileges?

Know whether the server runs on your laptop or on a hosted service. A local server runs on your machine and, per the MCP specification, may have direct access to your system. The spec says clients should warn that MCP servers run with the same privileges as the client. That is a lot of trust to extend.

The specification also says that if a client supports one-click setup of local servers, it must show the exact command that will run and require explicit approval first. If you see that dialog, read it. A command that touches files outside its own folder, or uses system-level privileges, deserves a pause.

Hosted servers move the risk rather than remove it. You trade local system access for trust in the host. Check who operates it, what they log, and how you disconnect it.

How would you undo what the server did?

Before connecting, decide how you would reverse a bad action. Can you restore a deleted CRM record? Roll back a published CMS change? See a log of every action the assistant took? If you cannot answer yes, keep the server read-only until you can. Reversibility is what makes experimentation safe.

The MCP specification notes that bugs in legitimate servers, not just attackers, can cause irrecoverable data loss. That is the realistic risk for most marketing teams. A well-meaning assistant misreads an instruction and updates five hundred records instead of five.

Logging is the cheapest insurance. Every action a server takes should leave a trace you can read later: what changed, when, and on whose request. I covered what that trace should contain in what to log when an automation runs.

How do you run a safe first test?

Run the first test against a sandbox, a test property, or a staging site, never your live account. Give the assistant a narrow task, watch every action it takes, and compare the result with what you asked for. Only after a few clean runs should the server touch production data, and even then start read-only.

Many tools offer a sandbox, a staging site, or a way to create a limited test user. Check your tool's docs and use whatever it offers. A mistake in a sandbox costs you a few minutes. The same mistake in production can cost a week of cleanup.

If you want an example of a lower-risk, read-heavy use case to start with, my walkthrough on running a Webflow SEO audit with an MCP server is a good first project. Auditing reads a lot and changes nothing.

What should you do next?

Pick one MCP server you want to use and answer the five questions in writing: who built it, what it can read and write, how it signs in, where it runs, and how you would undo its actions. If any answer is unclear, keep it read-only and test in a sandbox first. Then expand access one permission at a time.

Share the answers with whoever owns your tool stack. A one-page note is enough. It turns a casual connection into a decision someone made on purpose, which is exactly what you want when something goes wrong later.

If you are connecting AI assistants to your marketing and sales tools and want a second opinion on the setup, reach out. I build and maintain these systems for B2B teams, and I am happy to look at yours and tell you honestly where the risk sits.