Every lesson in this course has used Claude Desktop or Cursor as the concrete example. None of the abilities you registered in Course 2, and none of the patterns from this course’s earlier lessons, actually depend on Claude specifically. This closing lesson makes that explicit, and shows you what, if anything, you’d need to change to run the exact same server against a completely different LLM provider.
Everything from the earlier lessons in this course, a working server, at least one connected client, and ideally the multi-ability patterns from Lessons 4 through 7. No new WordPress code in this lesson, this is about how you think about the architecture you’ve already built.
Your server has no idea which model is calling it
Walk back through the request lifecycle from Course 1: a client opens a connection,
sends initialize, requests the tool list, and later sends tools/call with a tool
name and arguments. Nothing in that exchange identifies which LLM decided to make
that call. Your execute_callback receives arguments matching your input_schema,
runs, and returns a result matching your output_schema. It would run identically
whether the request originated from a decision Claude made, a decision GPT made, or a
decision some other model entirely made, they all speak the same MCP request format
to reach your server.
This isn’t an accident of how you built things, it’s what MCP is for. The protocol exists specifically so that “the thing exposing tools” and “the model deciding how to use them” can be built, updated, and swapped independently of each other.
Where model choice actually lives
Model choice is a client-side decision, made when you configure Claude Desktop, Cursor, or any other MCP client, not something your WordPress site or your abilities have any say in.
| Layer | Where it lives | Who chooses it |
|---|---|---|
| Abilities and their schemas | Your WordPress site (Course 2) | You, once, regardless of client |
| MCP transport and endpoint | The MCP Adapter plugin | You, once, regardless of client |
| Which LLM interprets requests and picks tools | The client app (Claude Desktop, Cursor, etc.) | Whoever configures that client |
| Authentication into your server | WordPress Application Passwords | You, independent of which model is on the other end |
Practically, this means the same server you built in Course 2 and connected in Lessons 1 and 2 of this course could be pointed at by a team member using a completely different client backed by a different provider, without you touching a single ability. If your organization decides to standardize on a different LLM vendor next year, or wants to let different teams use different assistants against the same WordPress abilities, that’s a client-side configuration change, not a WordPress migration.
What actually does change between providers
Being vendor-agnostic at the protocol level doesn’t mean every model behaves
identically once connected. Tool-selection quality, how reliably a model reads your
description fields and picks the right ability, does vary between models and
providers. This is exactly why Lesson 4’s advice to write clear, specific ability
descriptions matters more, not less, in a multi-provider setup: those descriptions
are the only interface a model has into your site regardless of which one it is, and
some models lean on that text more carefully than others.
If an ability is important enough to build a confirmation gate for (Lesson 6) or to chain into a multi-step workflow (Lesson 7), it’s worth testing that ability against at least two different clients before relying on it in production. A description that reads clearly to one model can occasionally be ambiguous to another, catching that early is cheaper than discovering it after someone’s team has standardized on a different assistant.
A practical checklist for staying portable
Test it
If you have access to more than one client, connect the same server to a second one and run the same request through both.
Client A (e.g. Claude Desktop): "List my draft posts."
Client B (e.g. Cursor): "List my draft posts."If a specific model handles a request awkwardly, the instinct is sometimes to special-case an ability’s logic around that model’s behavior. Resist that. Fix the description, the schema, or the error message instead, changes that help every client, rather than a change that quietly assumes one specific model is on the other end.
Recap
Your WordPress MCP server has no concept of which LLM is calling it, and doesn’t need one, MCP’s request format is identical regardless of the model behind the client. Model choice, and everything that depends on it (persona, system prompts, client-specific UI), belongs entirely on the client side. Keeping your abilities, descriptions, and authentication persona-neutral and client-neutral is what makes it realistic to switch providers, or support several at once, without touching the WordPress side of this stack at all.
Resources & further reading
- Model Context Protocol specification, modelcontextprotocol.io
- MCP Adapter repository, GitHub
- Abilities API reference, developer.wordpress.org