Building marketing agents with MCP servers: what we learned
We built marketing agents on MCP servers. Here is what held up, what failed, and the approval gates that saved us, dated August 2026.
Every MCP post you find is selling something: either a server marketplace, a gateway product, or a newsletter. The boring reality is the part worth reading. The protocol works, and the failures are almost all upstream of the model. I spent my evenings this summer building marketing agents on MCP servers. This post is what held up, what fell over, and what I would wire differently next time. All of it is dated to August 2026.
What MCP actually changes for marketing agents
MCP is a protocol that lets an agent talk to tools and data sources through one standard interface. Instead of writing per-vendor API glue, you connect a server that exposes tools, and the agent calls them like functions. For marketing, that means one pattern for the ad platform, the spreadsheet, the email tool, and search. That is the appeal, and it is real.
The change is specific, though: what MCP lowers is the build cost of connecting things. What it raises is the blast radius. The same easy connection makes it easy to give an agent too much. That tradeoff is the whole story of this post.
The protocol also moved under us. The 2026-07-28 revision dropped the handshake and sessions for direct HTTP calls (spec). Simpler to connect, and one more surface to secure.
NoteWhat I verified hands-on: the tool-call loop, several community and self-hosted servers, and every failure mode below. What I have not done: production load at agency scale or a real security audit. Those claims belong to the docs and to the researchers, not to me.
The agent failure modes we hit
Four failure modes dominated our runs, and none were about the model: they live in the plumbing around it.
Tool sprawl. Every server you connect adds tools. Add enough, and the agent spends its context deciding which one to call. The most common design failure, per the audit thread, is one tool per API method (HN). That buries the model in near-useless entries. The fix is grouping tools into areas, with actions inside each one. I hit the same wall, and my drafts got worse before they got better.
The context tax. Every tool output the agent reads once stays in context until compaction, and big catalogs soften the model’s edges. The fix is discipline: fewer tools, shorter outputs, and a small curated catalog. Server quality matters more than people admit, too. An independent audit graded 36 popular MCP servers on agent usability (tengli.dev). A third scored a D or an F. The full catalog is serialized into every request, so size taxes you either way. Vet a server the way you would vet a vendor.
Retry loops. Agents retry failing tools with the same arguments. I watched a draft agent call the same broken search tool eleven times in one run. How to stop the looping in production is a live question on Hacker News (HN). The answer is boring: a call budget, an error path, and logs.
Silent wrong-tool calls. This is the dangerous one: the agent treats tool output as truth, and bad output flows downstream. So treat every data source as untrusted: tool output can carry instructions that look like helpful guidance. That is not paranoia, it is a documented attack path, and it lands in the next section.
| Failure mode | What it looks like | The fix |
|---|---|---|
| Tool sprawl | Agent hesitates, catalog keeps growing | Small curated catalog, tools grouped by area |
| Context tax | Decisions get softer as the run goes on | Fewer tools, shorter outputs, compaction discipline |
| Retry loops | Same failing call, repeated | Call budget, error path, logs |
| Silent wrong calls | Bad tool output flows downstream | Treat tool output as untrusted, verify writes |
Where the real risk is: permissions and prompt injection
The risk is not the model, it is the tools. An overprivileged server with direct database access is one bad instruction away from exposing things. Researchers demonstrated the path (Coalition for Secure AI). Prompt injection via support ticket data could expose private tables through a connected MCP server. The mechanism is simple. Data you control contains instructions, the agent follows them, and the server holds more rights than it needs.
Three rules from our builds:
- Scope credentials per server. No master keys. Proxy keys, and read-only tokens where the API allows it.
- Read-only defaults for anything touching accounts. The agent reads, a human writes.
- Approval gate for anything that writes or spends. One click is the cheapest control you will ever buy.
WarningAs of August 2026, no tool in my setups writes or spends without a human approve step. The tool-call loop never touches money and never sends mail on its own. That is a choice, not a protocol feature: MCP does not gate writes for you, you gate them.
What held up in our builds
Three builds survived the summer, and one got cut: the pattern is worth more than any single build.
The reporting pull. A read-only server over the ads API that answers campaign questions in plain language. This is the killer use case, and the r/PPC threads I read say the same thing. MCP kills the manual pull and upload grind, while “never touch the account again” is where it falls over. The pull never writes, so the risk stays low.
The brief generator. Research tools feed a one-page brief, and the agent stops before drafting. The quality jump came from the same lesson as my n8n agent builds: make it stop at the brief. Review the output before anything else happens.
The alert watcher. A threshold crosses, a message arrives. Boring, reliable, and worth more than the flashy builds.
The cut. An auto-pause tool for an ad account. It worked in the sandbox, and I still cut it, because the blast radius beat the time saved. A wrong pause on a live account costs more than the workflow ever saved. That decision matches the honest test I ran on ChatGPT for marketing: the tool is never the whole story.
- The job is read-mostly: pulls, briefs, alerts, research.
- Every tool has the minimum scope it needs, read-only where possible.
- Anything that writes or spends has a human approve step.
- Tool calls are logged with arguments and outcomes.
- The catalog stays small enough to name from memory.
MCP agent or plain API workflow
MCP wins on setup speed for read-mostly jobs. Plain API workflow wins when you need deterministic control and an audit trail. Pick by the job, not by the hype.
| MCP agent | Plain API workflow | |
|---|---|---|
| Setup | Connect a server, describe the tools | Write and maintain the calls |
| Control | The model decides the sequence | You decide the sequence |
| Audit trail | Tool logs, if you keep them | Code review, always |
| Failure modes | Sprawl, context tax, loops | Yours, and you debug them fast |
| Best fit | Read-mostly, exploratory, multi-source | Writes, money, anything irreversible |
The hybrid is what I run now: MCP for reads and research, plain code for anything that writes. The protocol is a tool, not a policy. If you are building your own stack, the agents category has the rest of my notes.
The Bottom Line
- MCP lowers the build cost of connecting tools, and it raises the blast radius.
- The failure modes are sprawl, context tax, retry loops, and silent wrong calls.
- The risk lives in the tools, not the model: scope credentials, read-only defaults, approval gates.
- Read-mostly jobs held up. Autonomous writes to live accounts got cut.
- Match the approach to the job: MCP for reads, plain code for writes.
Filed under agents. More in the tools category and about this blog.