WordPress Always Wins

This week I spent an afternoon connecting Google Stitch to Antigravity via MCP. Stitch is Google's new AI-powered UI design tool. MCP is the Model Context Protocol — an open standard that lets AI agents interact with external tools. Antigravity is the IDE I use to run agentic coding tasks.

It took longer than it should have. There was a red error, a JSON file I had to find manually, an API key I had to generate, copy, and paste in exactly the right place.

And halfway through, I realized something.

I was just installing a plugin.

What MCP Actually Is

🤓 Dev Mode

MCP is an open protocol that standardizes how AI agents communicate with external tools and services. Each tool exposes a set of callable functions — in Stitch's case things like generate_screen_from_text, edit_screens, apply_design_system. The agent discovers these functions at runtime and can invoke them directly, passing structured parameters and receiving structured responses.

The config lives in mcp_config.json. Each integration gets a named block inside mcpServers with a serverUrl and an headers object for authentication. Add a block, the agent gains a capability. Remove it, the capability is gone. No restart required beyond a Refresh.

{
  "mcpServers": {
    "stitch": {
      "serverUrl": "https://stitch.googleapis.com/mcp",
      "headers": {
        "X-Goog-Api-Key": "YOUR-KEY"
      }
    }
  }
}

😶 Just Follow Along

MCP is a way to give your AI superpowers. Without it, the AI only knows what you type to it. With it, it can actually do things — open a design tool, read a document, push code somewhere.

You connect each tool by adding a small block of text to a config file. One block = one superpower. It's basically a list of everything the AI is allowed to touch.

The WordPress Parallel

🤓 Dev Mode

The architectural parallel is closer than it looks. WordPress's plugin system exposes action hooks and filters that third-party code can register against. MCP exposes a tool manifest that agents can query and invoke. Both are runtime extension systems built on the same principle: a core that does one thing well, and a standardized interface for adding everything else.

The difference is execution context. WordPress plugins run server-side in the same PHP process — which is why they conflict. MCP servers are remote, isolated processes communicating over HTTP. No shared memory, no hook collisions, no "this plugin is incompatible with that plugin." The protocol solved the conflict problem by design.

But the mental model — a base system extended by modular connectors authenticated with API keys — is identical.

😶 Just Follow Along

Here's what installing a WordPress plugin looks like:

1. Find the plugin
2. Click Install
3. Enter an API key somewhere in Settings
4. Hope it doesn't break something else

Here's what adding an MCP server looks like:

1. Find the MCP server
2. Add a block to a JSON file
3. Enter an API key in the right field
4. Hit Refresh and see if the red error goes away

Different interface. Same idea. You're connecting a new tool to a base system using a key and a config. WordPress figured this out in 2003. AI agents figured it out in 2024.

Every Abstraction Converges

🤓 Dev Mode

This isn't a coincidence — it's convergent design. Any extensible system operating at scale eventually needs the same primitives: a discovery mechanism, an authentication layer, a configuration format, and an error surface. WordPress has plugins, wp-config.php, and a debug log. MCP has mcpServers, API key headers, and a red error in the settings panel.

The implementation details differ. The system design doesn't. If you understand one, you understand the shape of the other.

😶 Just Follow Along

Every platform ends up building the same stuff:

• A way to add new features → plugins, MCP servers, extensions
• A way to prove you're allowed to use them → API keys, passwords, tokens
• A way to set them up → settings pages, JSON files, .env
• A way to know when something's broken → error logs, red text, a friend on Discord

The tools change every few years. The pattern doesn't. If you've ever installed a WordPress plugin, you already speak this language. You just didn't know it had a new name.

The One Actual Difference

MCP integrations don't break each other. There's no shared runtime, no plugin ecosystem of 40,000 extensions fighting over the same hooks, no mystery error after an update, no three-year-old support thread explaining why two tools conflict.

That's real. That matters. Especially at 11pm before a client presentation — and I know because I've been there, in a past life, watching Elementor eat a page layout.

But conceptually? WordPress got there first.

It always does.

Filed under: things I figured out while trying to make a JSON file work.