cd /news/developer-tools/i-wired-11-wordpress-sites-to-an-llm… · home topics developer-tools article
[ARTICLE · art-82078] src=dev.to ↗ pub= topic=developer-tools verified=true sentiment=· neutral

I Wired 11 WordPress Sites to an LLM With MCP. Here’s Some Things That Broke.

An SEO professional who runs a content pipeline across 11 WordPress sites using Model Context Protocol servers detailed several failure modes encountered in production, including connectors that appear registered but fail to connect, transient errors that models misinterpret as permanent, and tools that behave differently than their descriptions suggest. The developer emphasized that MCP is easy to implement but that real-world integration issues arise from business logic, connector standardization, and tool capability mismatches, recommending retry-with-backoff in the tool layer and reading actual implementations before trusting destructive operations.

read4 min views2 publishedJul 31, 2026

I’m not a developer by trade. I’ve spent about twenty years in SEO — Raven Tools, TapClicks, now my own seo agency shop and a podcast network. But somewhere in the last year I ended up maintaining a production content pipeline that runs on Model Context Protocol servers, publishes to eleven WordPress installs, schedules across eight social platforms, and composites video with ffmpeg in a sandboxed container.

It works. It also broke in about a dozen ways that no MCP tutorial mentions, because every MCP tutorial stops at “and now the model can read your files!”

Here’s the part after that.

MCP is trivially easy. That’s the trap.

An MCP server is a thin wrapper around an HTTP call. That’s genuinely it. If you can write an Express route, you can write an MCP server. I’ve watched Claude Code scaffold one in an afternoon.

Which means the moment you start planning an integration, the protocol is not your constraint. The constraint is always one of these:

Number one is a business problem.

Numbers two, three and four are where I lost actual weeks.

Eg I spent two whole weeks where Desktop Claude pretended to access my Obsidian Vault but was just mining my previous chats for answers, the lie surfaced when I got deeper into using terminal and stopped feeding Desktop materials

Failure mode Confident Liar: the connector that’s registered but not connected

The single most disorienting bug in my whole setup. A connector appears in your server list. It shows up in config. The model can see its name. And it exposes zero callable tools.

You get some variation of “Server X is not connected — the user needs to connect this integration.” But it’s listed. It’s right there.

Ten of my sites run one WordPress MCP adapter at /wp-json/royal-mcp/v1/mcp. One site ran a different default adapter at /wp-json/mcp/mcp-adapter-default-server. The odd one out was the only one that wouldn’t handshake — and it took me an embarrassingly long time to notice the URL pattern difference, because “it’s in the list” reads as “it’s connected.”

Lesson: registration and authentication are separate states, and most tooling collapses them into one green dot. When you’re standardizing a fleet, standardize the adapter, not just the endpoint. One-off integrations are where your debugging time goes to die.

Failure mode Ghost Problems: transient failures that look permanent

Two of my connectors regularly return No approval received on the first call and succeed on an immediate retry. Same payload. Same session. Seconds apart.

If you’re building agentic workflows, this matters more than it sounds. A human sees a failure, shrugs, hits it again. A model sees a failure and reasons about it — it’ll write you a beautifully argued paragraph about how your authentication has lapsed and you should check your plugin settings. It’s confidently wrong, and now you’re chasing a ghost. Lesson: bake retry-with-backoff into your tool layer, not your prompt layer. Do not make the model responsible for distinguishing flaky from broken. It’s bad at it, and it’s bad at it persuasively.

Failure mode Capability Mismatch: tools that are narrower than they look

wp_upload_media sounds like it uploads media. It uploads images. Hand it a .pptx and you get an instant rejection on MIME type — not a size limit, not a timeout, a type check firing before a single byte transfers.

That restriction lives in the connector, not in WordPress. And WordPress also blocks .pptx in its default allowlist. Two independent gates, one generic-sounding tool name.

Similarly: wp_update_post overwrites the entire content field. Not a patch. Not a merge. The whole thing. If you’re feeding it partial content, you just deleted a page.

Lesson: tool descriptions are marketing copy for the model. They describe the happy path. Read the actual implementation, or probe the edges deliberately before you trust anything destructive.

Failure Mode Wrong Tool Use: MCP is a fragile toy

At the end of the day I wasted SOOOO much time rejoicing for my “unlock” of using MCP for my wordpress sites.

Truth: it was the wrong tool, broke on plugin updates and was not consistent.

Honestly the solution was REST access the whole time. Claude code could do 10000x what the limited MCP could deliver and was insanely easy to setup immediately and has not had a fraction of the problems.

── more in #developer-tools 4 stories · sorted by recency
── more on @wordpress 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/i-wired-11-wordpress…] indexed:0 read:4min 2026-07-31 ·