Lesson 1 drew one line: WordPress data versus cross-system coordination. Now that you’ve built both directions of that line in practice, webhooks in, webhooks out, CRM chaining, Slack, this lesson turns it into a repeatable framework covering all three places logic can live: a plain ability, an ability exposed over MCP, or an external automation workflow.
Courses 2 and 3 (registering and exposing abilities over MCP) and Lessons 1 through 6 of this course. This lesson doesn’t introduce new code, it organizes what you’ve already built.
Step 1: Three options, not two
It’s easy to flatten this into “WordPress versus automation platform,” but there are really three distinct places logic can live, and each answers a different question:
| Option | Answers the question |
|---|---|
| A plain WordPress ability, never exposed over MCP | ”Some PHP code, or WP-CLI, needs to do this reliably, with permission checks.” |
An ability exposed over MCP (meta.mcp.public: true) | “An AI agent needs to decide, conversationally, when to do this.” |
| An external automation platform workflow | ”A WordPress event needs to trigger action across other systems, with no judgment call involved.” |
The middle row is the one this course hasn’t been about, that’s Courses 2 and 3’s territory, an agent reading a description and deciding to call a tool. This course’s territory is the first and third rows: internal-only abilities, and the automation platforms from Lessons 2 through 6.
Step 2: The three questions
If question 2 comes back “yes,” you’re building an MCP-exposed ability, Courses 2 and 3 already cover that path in depth. If it comes back “no” and question 3 says “two or more external systems,” you’re in this course’s territory: a webhook feeding an automation platform. If both come back negative, you likely just need a plain ability or even a direct WP-CLI command, no MCP, no external platform, at all.
Step 3: Worked examples
| Request | Answer | Why |
|---|---|---|
| ”Let support staff bulk-approve pending comments from a WP-CLI script.” | Plain ability | Internal code calling internal code, no agent judgment, no other systems involved. |
| ”Let our support chatbot look up a customer’s order status and answer questions about it.” | MCP tool | An AI model needs to decide when to call it and how to phrase the answer, that’s Course 7’s territory. |
| ”When an order ships, update the CRM, tag the customer for a follow-up sequence, and notify sales in Slack.” | External automation | Three external systems, no judgment call, pure “this happened, now do these steps." |
| "Let an agent draft a blog post from a Slack message, on request.” | MCP tool, invoked from within an automation platform | A hybrid: the automation platform (Lesson 3’s pattern) supplies the trigger and the Slack context, but the actual drafting decision and the ability call is still MCP. |
That last row matters: these three options aren’t mutually exclusive within one
system. An automation platform can be the thing that decides when to call an MCP
tool, exactly like Lesson 3’s HTTP Request node calling tools/call. The framework
tells you which piece of a larger system belongs where, not which single option to
pick for an entire project.
Step 4: What changes your answer later
A plain ability can outgrow itself into an MCP tool the moment you introduce an AI
agent that needs to decide when to use it, that’s just adding meta.mcp.public: true
and a public server, no rewrite required, per Course 2. An automation-platform workflow
can shrink back into a plain ability if the “coordination across systems” turns out to
only ever touch one system after all, simplify it rather than leaving unnecessary nodes
in a workflow just because that’s where it started. Revisit the framework whenever a
requirement changes, don’t treat the original choice as permanent.
Test it: classify your own backlog
Take three real feature requests from your own project’s backlog and run each one through Step 2’s three questions. If you land on “external automation” for something currently half-built as a WordPress ability, that’s a signal worth raising with whoever owns that roadmap, before more PHP gets written around it.
It’s tempting to make every ability meta.mcp.public: true on the theory that an AI
client might want it someday. Each publicly exposed ability is additional attack
surface an agent (or anyone spoofing one) can reach, per the permission model from
Course 2’s schema and permissions lessons. Expose an ability over MCP when there’s an
actual conversational use case in front of you, not preemptively.
Recap
Three places logic can live: a plain ability for internal-only code, an MCP-exposed ability for anything an AI agent needs to decide to call, and an external automation platform for anything reacting to a WordPress event across multiple external systems with no judgment call involved. The three questions, who initiates it, does a model need to choose, how many systems does it touch, sort almost any real request into one of those three, and they can combine within a single larger system rather than forcing an all-or-nothing choice. The final lesson wraps up the whole course.
Resources & further reading
- Abilities API reference, developer.wordpress.org
- MCP Adapter repository, GitHub
- Model Context Protocol specification