I Turned My WordPress Store Into an MCP Server. Now an AI Agent Runs My Business — With My Permission.

Or: how a WordPress plugin, an embedded OAuth 2.1 authorization server, and a blue slime named Blub are teaching AI agents to ask before they act.

The story that started it all

One evening, an AI agent created a product in my WooCommerce store.

Not through a hack. Not through a leaked admin password. And not because I gave an AI unrestricted access to my WordPress dashboard.

It proposed the action, I reviewed the details, and I approved it through an admin dashboard.

The product was "Cilok Goang Pedas Mantap" — a spicy Indonesian street-food product — with its price, sale price, stock, SKU, categories, tags, and SEO metadata configured through an AI-assisted workflow.

The agent was Meta's Muse Spark, accessed through Muse Code.

The bridge that made this possible is called MuseSpark MCP Bridge.

It's a WordPress plugin that turns a WordPress + WooCommerce installation into an MCP server, allowing AI agents to interact with business data through structured tools rather than relying entirely on browser automation.

And the part I care about most isn't that an AI can create a product.

It's that I can decide what it is allowed to do.

What is MuseSpark MCP Bridge?

MuseSpark MCP Bridge exposes selected WordPress business capabilities through the Model Context Protocol (MCP).

Instead of building a separate integration for every AI agent, the plugin provides a standardized interface for operations such as reading posts, managing product inventory, creating content, updating SEO metadata, and generating daily business summaries.

Here's the current toolset:

Tool	Access	Purpose
wp_list_posts	Read	Retrieve WordPress posts
wp_create_post	Write	Create content or drafts
seo_set_post_meta	Write	Update Yoast SEO metadata
wc_list_products	Read	Retrieve WooCommerce products
wc_create_product	Write	Create WooCommerce products
wc_update_stock	Write	Update inventory
newsletter_add_subscriber	Write	Add a newsletter subscriber
report_daily_summary	Read	Generate a daily business summary

The server implements the MCP 2025-06-18 specification over Streamable HTTP, including the relevant initialization, ping, tools, resources, and prompts protocol methods.

It has been verified end-to-end with the official MCP Inspector, including the OAuth authorization flow over HTTPS.

The project has also been tested in live Muse Code sessions using Muse Spark, where the agent created real products and content drafts through the approval workflow.

This is still an evolving prototype, but the basic integration is already doing useful work.

Why MCP instead of another custom API?

WordPress already has a REST API. WooCommerce has its own API. So why introduce MCP?

Because exposing an API and giving an AI agent a usable interface to business operations are two different problems.

A conventional API gives applications endpoints and data structures. MCP provides a standardized way for compatible AI clients to discover and invoke tools.

For example, instead of asking an agent to figure out how to construct a series of HTTP requests to create a product, I can expose a tool called wc_create_product with a defined input schema.

The agent can reason about the available tool, prepare its arguments, and request the operation through the MCP server.

The plugin then handles the WordPress-side integration and applies its authorization and autonomy policies.

This doesn't make every AI agent automatically compatible, nor does it eliminate the need for proper validation. It simply gives compatible clients a more consistent interface to work with.

The architecture looks like this:

AI agent → MCP client → MuseSpark MCP Bridge → WordPress / WooCommerce

The AI handles reasoning and tool selection. WordPress remains the source of truth for business data.

And the bridge determines how those tool requests are handled.

The part I'm proudest of: the AI asks for permission

Giving an AI agent access to a business system is easy to demonstrate.

Building a sensible boundary between what the agent can propose and what it can actually execute is the more interesting engineering problem.

MuseSpark MCP Bridge includes an autonomy policy engine with three modes.

1. read_only

The agent can inspect permitted business data, but write operations are not allowed.

This is the mode I'd start with when connecting an unfamiliar agent to a real store.

2. draft_only

The agent can prepare drafts rather than directly publishing content.

This is useful for workflows where AI can do the repetitive preparation while a human retains editorial control.

3. require_confirmation

This is the default mode.

When a write action requires confirmation, the plugin routes the request to an approval queue rather than immediately executing the requested operation.

I can review the proposed payload in the admin UI, approve it, or reject it. The action runs only after approval.

The distinction matters: an agent requesting an action is not the same as an action being authorized to execute.

The server also validates scopes at request time and records them with the task for auditing.

That creates a clearer record of what was requested and under which permissions it was processed.

Of course, an approval queue isn't a substitute for secure authorization, input validation, or proper capability checks. It's one layer in a broader security model.

But it's an important layer.

I don't want an agent to accidentally publish a product with the wrong price just because it misunderstood my instructions. And I certainly don't want a compromised integration to have unrestricted write access to my store.

OAuth 2.1, built into WordPress

One of the more substantial parts of this project is its embedded OAuth 2.1 authorization server.

Rather than relying exclusively on manually generated credentials, the plugin implements an authorization flow designed for compatible MCP clients.

The current implementation includes:

• Protected resource metadata under RFC 9728.
• Authorization server discovery under RFC 8414.
• Dynamic client registration under RFC 7591.
• Mandatory PKCE using S256.
• A user consent screen.
• Refresh-token rotation.
• Token revocation.
• A legacy scoped JWT bearer-token option for supported workflows.

Tokens and authorization codes are stored as hashes rather than plaintext credentials. The plugin also provides audit logging and an admin interface for managing tokens, approvals, logs, and settings.

For command-line workflows, a scoped JWT can be generated through WP-CLI:

wp musespark generate-token \
  --user_id=1 \
  --scopes='*' \
  --ttl=3600

That example deliberately requests all scopes, so it should be treated as a development example, not a recommended production configuration. In a real deployment, use the narrowest permissions the workflow needs and an appropriately privileged WordPress account.

OAuth implementation details are not a guarantee of security by themselves. The project still needs further hardening, and I don't consider the current prototype production-ready.

That distinction is important enough to say explicitly.

BYOK: Bring your own agent

My philosophy is simple: the plugin ships no AI model.

There is no bundled model, no AI inference proxy, and no per-token markup. MuseSpark MCP Bridge is an integration layer, not an AI platform.

The responsibilities are deliberately separated:

• The agent reasons about the task and decides which tools to request.
• The MCP server exposes structured business capabilities.
• WordPress remains the source of truth.
• The authorization and policy layers determine which operations are permitted and whether approval is required.
• The human operator retains control over sensitive actions.

Muse Spark through Muse Code is the first agent workflow I've verified end-to-end with this project.

Because the server implements MCP rather than a proprietary Muse-specific tool protocol, other compatible MCP clients can potentially use the same endpoint too. Claude Desktop, Cursor, and custom agents are examples of clients worth exploring, but compatibility and authorization flows must be tested individually.

This is the architectural advantage I want to preserve.

If I change AI providers tomorrow, I shouldn't have to rebuild the entire WordPress integration just to expose the same business operations to another agent.

One backend. A standardized interface. Different potential agents.

That's a much more interesting proposition to me than tying a business workflow to a single AI vendor.

Meet Blub 💙

Every serious security project needs an unserious mascot.

Meet Blub, a chubby blue slime with an operator headset who lives in the admin dashboard.

Blub is there to greet the operator and keep the approval workflow a little less intimidating.

The mascot also has a small origin story: I briefly considered using a third-party mascot as a local easter egg, then decided that building an independent identity was the better choice.

So I created Blub instead.

His catchphrase is:

"Blub!"

Depending on the context, it roughly means, "The task is done."

The plan is to bring Blub into future chat-based workflows, including a Telegram control bot with inline approval and rejection actions.

That integration is on the roadmap, not a shipped feature yet.

Still, I like the idea of a friendly little slime reminding me that an AI agent has something waiting for my approval.

Security doesn't have to look intimidating to be taken seriously.

What works today, and what doesn't?

I'd rather be precise about the project's status than turn a working prototype into a production-readiness claim.

MuseSpark MCP Bridge is currently at v0.2.x.

What's been verified

• MCP protocol interaction through the official MCP Inspector.
• An end-to-end OAuth flow over HTTPS with MCP Inspector.
• Live Muse Code sessions using Muse Spark.
• Real WooCommerce product creation through the approval workflow.
• Content-draft workflows through the same integration.
• The WordPress admin interface for managing tokens, approvals, logs, and settings.

What's still missing

• An automated PHPUnit and integration-test suite.
• Rate limiting.
• Further OAuth and security hardening.
• The final WordPress.org submission package.
• Planned chat gateways and more granular autonomy controls.

These aren't minor footnotes. They're part of the work required before I would recommend treating the project as a production-ready business integration.

The current implementation is functionally verified in specific workflows, but that is not the same as having comprehensive automated coverage or a completed security review.

I'd rather publish an honest roadmap than pretend those gaps don't exist.

What's next?

There are four areas where contributions could make a meaningful difference.

1. Automated testing

The biggest gap is a proper PHPUnit suite and an integration harness covering authorization, scopes, tool execution, approval decisions, and failure cases.

2. Chat-based control

A Telegram bot with inline approve/reject buttons is planned. WhatsApp Cloud API integration is another potential direction, particularly for customer-service workflows.

3. More granular autonomy policies

The current three policy modes provide a starting point. The roadmap includes per-domain autonomy levels, from tightly controlled operations to more autonomous workflows, with appropriate boundaries.

4. Documentation and deployment

Installation instructions, OAuth flow documentation, translations, and a cleaner distribution package all need continued work.

If you want to explore the code, report a bug, or contribute, start here:

• Repository: https://github.com/joniilmanfahmi00-collab/musespark-mcp
• Contributing guide: https://github.com/joniilmanfahmi00-collab/musespark-mcp/blob/main/CONTRIBUTING.md
• Security policy: https://github.com/joniilmanfahmi00-collab/musespark-mcp/blob/main/SECURITY.md

The project is distributed under GPL-2.0-or-later.

MuseSpark MCP Bridge is an independent community integration. Muse, Muse Spark, and related marks belong to Meta Platforms, Inc.; the project is not affiliated with, endorsed by, or sponsored by Meta.

Your business, your rules

I started this project because I wanted to explore a practical question:

What happens when an AI agent can interact with a real business system, instead of merely explaining how a human could do it?

The answer isn't that the AI should automatically become the administrator of everything.

It's that we can give agents specific tools, define their permissions, record what they do, and require human approval where it matters.

A WordPress store doesn't need to surrender control to benefit from AI automation.

It needs a reliable interface, a clear authorization model, and sensible limits on what an agent can do.

That's what I'm trying to build with MuseSpark MCP Bridge.

If you'd like to explore the current prototype, check out the repository:

GitHub: MuseSpark MCP Bridge

For a local or development installation, a compatible MCP client can connect to the endpoint:

https://your-site.test/wp-json/musespark-mcp/v1/mcp

Replace the example hostname with your own WordPress site's HTTPS URL, and configure the client using the authentication method it supports.

This is a prototype, so review the setup and security requirements before connecting it to a live store.

The long-term goal is straightforward: let the agent do the repetitive work, let the system enforce the boundaries, and let the human remain in control.

And when there's a task waiting for approval?

Blub! 💙