Marketing Agent" Doesn't Mean Chatbot: What It Takes for Claude or GPT to Actually Run Your Site's Marketing

Ask Claude to write you a Google Ads headline and it writes you a Google Ads headline. That's a chatbot. Ask it to look at last week's campaign performance, flag the three ad groups bleeding spend, pause the worst one, and publish a blog post targeting the keyword that's actually converting — and have it do all four without you copying anything into anything — and now you need an agent. The gap between those two sentences is where almost every "AI marketing agent" article quietly stops being useful, because it reviews a dashboard product instead of explaining the three things that make that second sentence possible: a connection, a permission, and a gate.

This isn't a roundup of marketing-agent SaaS tools. It's the plumbing underneath them — the same plumbing you'd wire up yourself if you decided not to pay for one.

The connection: what "wired to your site" means

A chatbot has no memory of your Google Ads account past what you paste into it. An agent has a live connection — almost always now via Model Context Protocol (MCP), the open standard that lets Claude or GPT call tools against external services instead of just generating text about them.

Google Ads is the clearest example of what this looks like in practice, and it's also the clearest example of why "connected" doesn't mean "autonomous." Google's own official Google Ads MCP server is read-only: it answers questions about your account by running reports, but it lets Claude read your account and answer questions about it in plain English, and it only reads — it can't change a bid, pause a campaign or add a keyword. If you want an agent that can actually pause that losing ad group, you need a different server entirely — one of the write-access options that exposes tools like pause_campaign and update_budget as thin wrappers over the Google Ads API. The functional capability of your "marketing agent" is entirely determined by which server you installed, not by which model is running it.

The same pattern holds for analytics and your CMS. An MCP server can expose your site's traffic data as a read tool and your blog's publish endpoint as a write tool, and Claude is exactly as capable as the tool list it's been handed — nothing more.

The permission: what the agent is allowed to try

Connecting a tool and permitting a tool are two different layers, and conflating them is the single most common mistake in agent setups. In Claude's Agent SDK, this shows up directly in how tool access is configured: permission is whether a call gets approved once Claude attempts it, and allowedTools is an auto-approve list — tools you don't list are still available, a call to one of them just goes through the permission flow instead of running immediately. Listing a tool doesn't remove it from the agent's reach; it just decides whether the agent gets to use it without stopping to ask.

This matters because the opposite assumption — "if I didn't list it, the agent can't touch it" — is wrong and has burned people. A scoped deny rule leaves the tool in context and blocks only matching calls; if you want a tool gone, you have to remove it from the tool list or deny it by bare name. There's also a mode-level trap: broad "just let it run" settings override your careful allow list entirely. allowedTools does not constrain the most permissive mode — set it alongside full-bypass permissions and every tool is still approved, including the ones you never put on the list.

For a marketing agent, the practical translation is: decide, tool by tool, whether "can read analytics" and "can publish to the CMS" and "can change ad spend" belong on the same trust tier. They almost never do.

The gate: where a human still has to say yes

This is the piece that turns a capable agent into a safe one. Security researchers describe tool authorization in MCP as a two-step check: Gate 1 is capability admission — should this capability be available to this agent in the first place — and Gate 2 is execution authorization — given the current identity and context, should this particular use of the capability be allowed against this particular resource right now. Deciding Claude is allowed to use a "publish post" tool at all (Gate 1) is a separate decision from deciding it's allowed to publish this specific post, right now, with this title (Gate 2). A real marketing agent setup needs both gates, not just the first one.

In practice, Gate 2 is a human-in-the-loop approval step for anything consequential. One breakdown of safe MCP design puts it plainly: every tool must be explicitly classified as read-only or mutating, and mutating tools must trigger client-side approval gates before the call is actually sent. Reading your Search Console data, pulling last week's campaign report, drafting three headline variants — none of that needs a human to click "approve." Pausing a campaign, raising a budget, or publishing a post to a live site does.

Anthropic's own SDK bakes this distinction into its permission modes rather than leaving it to convention. One mode runs headless with a fixed, pre-approved tool surface and denies anything else outright; another stops before every write and waits on a callback you control. A headless agent with a fixed, explicit tool surface pairs a short allow list with scoped rules, bare-name denies for tools it never needs, and a hook for policy enforcement before any call runs. That's the shape a marketing agent should take: wide-open on read tools, a hard stop in front of every write.

Why this doesn't happen by default

Here's the part the SaaS reviews skip entirely, because it's bad for selling a product: MCP itself doesn't enforce any of this for you. A recent breakdown of the protocol's current state is blunt about it — there's no first-class per-tool permission model; authorization is largely optional and implementation-defined. The protocol can let a tool describe itself as dangerous, but almost nothing in the stack is required to treat it that way — annotations get dropped, hosts gate at the UI, and servers often assume someone else already enforced it. If you install a random MCP server for your ad account and never configure permission modes or an approval callback, you haven't built a marketing agent — you've handed a chatbot your login.

There's a second, quieter failure mode worth knowing about before you wire up a dozen marketing tools: servers can add new capabilities after you've already approved them. Dynamic tool discovery exacerbates this — almost all MCP hosts dynamically enable new tools at runtime as servers add capabilities, so if a remote server adds a delete-type tool in an update, agents automatically gain access without user awareness or approval. The ad-account MCP server you approved for reporting last month might ship a pause_campaign tool next month, and your agent inherits it silently unless you're re-reviewing what's actually been granted.

A blueprint, not a product

Put together, a marketing agent that's actually running your marketing — not drafting copy for you to paste — looks like this: an MCP connection to each surface (CMS, analytics, ad accounts), a permission list that keeps reads auto-approved and writes explicitly denied by default, and an approval callback sitting in front of every consequential action — publish, pause, budget change — that a human has to clear. None of the three pieces is optional, and skipping any one of them is how "I gave Claude access to my ad account" turns into a support ticket.

If you've already got the scheduled-publishing half of this working — Claude drafting and shipping blog posts on a cadence — the agent permission model here slots directly on top of it; see Your AI Should Publish While You Sleep: Building an MCP Pipeline That Blogs on a Schedule for that side of the pipeline. And if the automation you're building goes beyond MCP tool calls into raw API wiring against OpenAI or Claude directly, Stop Copy-Pasting From ChatGPT: Wire Your Site to the LLM API So It Updates Itself covers the cron-and-serverless-function layer underneath all of this.