Actionable AI: What the Heck is MCP and Why Should You Care?

Meet MCP: The Who, What, and Why

{
  "tool_name": "getSalesForMonth",
  "arguments": {
    "month": "May",
    "year": 2025
  }
}
// LLM sends something like the above to a Model Context Protocol Server...
// ...and might get back:
{
  "total_sales": 12345.67,
  "currency": "USD",
  "top_product": "Widget Deluxe"
}

A simplified conceptual example of an LLM requesting to use a tool and the kind of response it might receive.

One way to think about it is that instead of a 1-to-1 relationship between AIs and services (so you've have countless LLMs, each with n connections to services, leading to an n*n scenario, you have AIs connecting to the Model Context Protocol Client which connects in turn to the services. So an n+n situation. Far more manageable!

MCP, OpenAI's Tool Calling, and the Ecosystem

It's important to note that while the concepts are similar, different players have their own implementations. MCP was coined and formalized by Anthropic. Claude Desktop is currently a prominent client implementation of Model Context Protocol.

OpenAI’s tool-calling capabilities (the part of the Chat Completions / Assistants API that returns `tool_calls`) play a similar role to an MCP Host's function but it isn’t MCP-compatible at the wire level—think of it as a parallel dialect. It makes GPT behave like it can use tools. Think: “I typed a message into ChatGPT, and instead of just words back, it knows it needs to call a tool — and here’s what it sent.” So, if MCP becomes a widely adopted standard, then anyone can write a backend that various LLMs (those supporting MCP) can call tools from—including your own Laravel app, WordPress admin, or even your Minecraft server. However, OpenAI doesn’t strictly use MCP; it uses its own schema, which is very similar but not identical or directly interoperable.

Scenario: The Widget Co. - A WordPress Site

The real "aha!" moment with MCP often comes when you realize you can wire LLMs into everyday platforms. Let's focus on one "hero" scenario: a WordPress site for "Widget Co." to see how Model Context Protocol can empower a business.

Conversational Data Access

Widget Co. uses a WordPress site to manage information about their widgets, business locations, staff updates, and production documents. They love widgets there. It's all they think about. The CEO wants to query this information naturally, because of course he does. Bosses don't have time for code and suchlike.

"I would love to be able to talk to my website; that sounds brilliant! I want to query who's been updating widgets recently, who's been the most productive, what's the latest widget that we've produced, and so on. Make it happen." - Boss Man

(Note: The data could be in an internal system, but for our example, WordPress is the source of truth. We're web developers, after all!)

Understanding Tools, APIs, and Security in WordPress

The "tool" is defined on the AI side (e.g., in a Custom GPT or understood by Claude via MCP discovery). You specify the endpoint (your MCP server on WordPress), method, and schema. The AI learns to associate user intent with these tools. Your WordPress REST API endpoints are the actual executors.

Power-User Stacks: Laravel & Craft CMS

Laravel: Granular Control for Sophisticated MCP Servers

For more complex needs, Laravel provides a robust foundation. It offers greater flexibility, testability, and control over your MCP server implementation. Think Sanctum/Passport for authentication (treating the LLM like a scoped API user), sophisticated gates and policies for authorization, job queues for asynchronous tasks, and powerful Eloquent ORM for data interactions.

You could define dedicated MCP routes (e.g., in `routes/mcp.php`), use resource controllers for tools, and implement rate limiting and detailed logging for AI interactions.

Future-Proofing with the Repository Pattern

A key advantage in Laravel is the ability to use design patterns like the Repository Pattern. You can wrap your MCP tool logic in an interface (e.g., `ToolExecutorInterface`). Your current implementation might use an MCP-specific schema, but you could later swap this out for OpenAI's tool-calling format or a future protocol without rewriting your core business logic.

Back on our WordPress site, similar approval queues and security considerations would apply if we were allowing write access.

Bidirectional Communication and Automation

The conversation doesn't have to be one-way. What about the website sending updates *to* the LLM? This is where things get really interesting, especially when you bring in automation tools like Zapier.

For example, a new order on your WordPress site could trigger a webhook. This webhook could send data to an LLM (perhaps via a custom tool or an intermediary service). The LLM processes this, and then, using a Zapier connection (if the LLM platform supports it as a tool), updates a Google Sheet or sends a Slack notification.

In Laravel, queued jobs could monitor for new products and then use a tool to inform an LLM, which in turn might use its own tools (like a Zapier integration) to update external spreadsheets or dashboards. This creates a more dynamic, event-driven interaction.

The AI-Personalised Home & Desktop: Local Power Unleashed

The line between AIs and the clients we use to access them is blurring. From desktop agents to IDE integrations, the ways we interact are multiplying, which can be overwhelming.

Your Desktop and Home Server: The AI Butler is In

Imagine querying files on your system ("Find PDF invoices from April"), summarizing spreadsheets, or running local scripts ("Run `disk_cleanup.py` every Friday")—all by talking to an AI.

With Claude Desktop, you can run an MCP client that talks to local tools. It starts and introspects an MCP server running on your machine (e.g., `mcp-desktop-automation` or custom scripts). You define tools locally, and Claude (the LLM in the cloud, via the Host in Claude Desktop) uses them. No public IPs or complex port forwarding needed for these local interactions.

This contrasts with using, say, ChatGPT's web interface with Custom GPTs for local tools. That typically requires your local tools to be exposed publicly via a server or a tunneling service like ngrok, and you manually define the tool schemas in the GPT builder. For true local-first power, a dedicated MCP client like Claude Desktop is currently more streamlined.

"With Claude Desktop, your local tools are easily accessible. For web-based AIs to use local tools, those tools often need a bridge to the internet."

"We used to script smart homes with logic blocks—now we just talk to them, and the LLM figures out the rest."

Reality Check: Limits, Roadmap, and the XKCD Prophecy

MCP is exciting, but it's early days. Let's address the current landscape and potential pitfalls.

What About the AI "Going Rogue"?

This is where the imagination can, well, run a little wild. We've all seen the movies. An AI, given the keys to the kingdom, decides to lock us all out (or worse!). When we talk about Actionable AI and MCP allowing LLMs to do things, it's natural to wonder if we're inching closer to that kind of scenario. Could MCP be the conduit for an AI to gain too much power?

Let's ground this a bit. MCP itself doesn't grant the AI sentience or independent ambition. The LLM isn't waking up and deciding to cause chaos via your WordPress MCP server. It's responding to prompts and using the specific tools you, the developer, have exposed. If there’s no "delete_database" tool available through MCP, the LLM can't just conjure one up.

The more pertinent concerns, when we strip away the sci-fi gloss, are a bit more down-to-earth but still incredibly important:

• Overly Powerful or Poorly Designed Tools: If a developer, for instance, creates an MCP tool that can execute arbitrary server commands with high privileges, the potential for misuse (whether instructed by a naive user, a malicious actor, or via a cleverly crafted prompt injection) is significant. The "power" isn't inherent in the AI deciding to rebel, but in the capabilities of the tools it's given.
• Unforeseen Cascading Effects: Imagine an AI tasked with managing inventory across multiple warehouses via MCP. A perfectly logical (from the AI's perspective) series of actions based on its training and a specific goal could lead to an entirely unforeseen and disruptive outcome in the real world if the initial parameters or the tools' interactions aren't perfectly understood.
• Human Misuse: A powerful LLM connected to a wide array of real-world systems via MCP could become an incredibly effective tool for someone with malicious intent. The AI isn't "rogue"; it's being directed.
• Security Flaws Amplified: A vulnerability in your MCP server, or a successful prompt injection attack that tricks the LLM, becomes much more critical when the AI can take direct actions.

So, while the narrative of a spontaneously rebellious AI is compelling, the immediate challenge with MCP is more about robust engineering, meticulous security, the principle of least privilege for exposed tools, and ensuring human oversight where actions have significant consequences. It’s less about the AI wanting to "go rogue" and more about humans ensuring they haven't inadvertently left the entire system vulnerable or designed tools that are too much of a "free rein" for any single point of failure or instruction.

The Evolving Ecosystem: Modularity, Teamwork, and Intelligent Oversight

As MCP and similar protocols mature, we'll see new patterns emerge.