Everything in this course so far has assumed a plugin running on a site you control. This final lesson is about the other path: packaging what you’ve built, an ability library, a set of MCP servers, a whole integration, as a plugin listed on WordPress.org that other people install and, potentially, pay you for. The directory has real, specific rules about what a commercial plugin can and can’t do, and they’re worth understanding precisely before you build a business model that the review team will reject.
This lesson assumes you have a working, tested plugin (Lesson 9’s CI pipeline is a reasonable bar) that you’re genuinely considering distributing publicly, not a hypothetical.
Step 1: The GPL requirement is not optional, and it’s not just the PHP
Every file in a WordPress.org-hosted plugin, code, data, and images, must comply with the GPL or a GPL-compatible license. Using the exact same license as WordPress itself, “GPLv2 or later,” is strongly recommended and by far the most common choice, since it removes any ambiguity about compatibility. This applies to third-party libraries you bundle too: if your plugin vendors a Composer package (Lesson 7’s reusable ability library, for instance) under an incompatible license, that’s a real, common rejection reason, and it’s your responsibility as the submitter to verify every bundled dependency’s license before you submit, not something the review team figures out for you as a courtesy.
The GPL requirement covers what’s hosted on WordPress.org. A separate “Pro” add-on sold and distributed entirely through your own site, outside the WordPress.org directory, isn’t required to use the same license, this is exactly how the freemium model below works in practice.
Step 2: Freemium and SaaS are allowed. Trialware is not.
This is the single most important distinction for a commercial MCP plugin, and it’s worth being precise about, since the two patterns look similar on the surface and are treated completely differently.
| Pattern | Allowed? | Why |
|---|---|---|
| Freemium: free core plugin on WordPress.org, a separate paid “Pro” plugin sold on your own site with more abilities/servers | Yes | The free plugin’s functionality is complete and not artificially crippled; the paid product is a genuinely separate, additional plugin |
| SaaS: your plugin is an interface to a paid external service (for example, a hosted observability dashboard for your MCP servers) | Yes | The service itself provides real functionality of substance; the plugin isn’t just a license-check wrapper around code that could otherwise run locally |
| Trialware: the plugin’s own bundled functionality works fully for a trial period or quota, then locks | No | Functionality may not be disabled after a trial period or usage quota is met, this is explicitly prohibited |
| Fake service, real purpose is license validation only | No | Creating an external “service” purely to gate functionality that could run locally, without the service providing real substance, is treated the same as trialware |
For an MCP plugin specifically, this means: your free WordPress.org listing can register a working default MCP server with a real, useful set of abilities. A paid add-on can add more servers, more abilities, or a hosted observability backend (Lesson 3), sold and distributed separately. What it can’t do is ship all of that functionality in the free listing and then disable it after 30 days or 1,000 calls.
Step 3: Disclose external service calls, explicitly
Any plugin that contacts an external server needs explicit, documented disclosure of what’s being sent and why, generally through an opt-in mechanism rather than silent, automatic calls. This maps directly onto two things this course has covered extensively: an MCP server that lets external clients call abilities is, from the guidelines’ perspective, exactly this kind of external-service relationship in reverse, and anything using the PHP AI Client SDK to call Anthropic, OpenAI, or Google is unambiguously an external service call requiring disclosure. Your plugin’s readme should say, in plain language, what data gets sent to which provider, and your setup flow should require the site owner to actively opt in (typically by entering their own API key) rather than silently phoning home the moment the plugin activates.
// File: readme.txt (excerpt)
== Description ==
This plugin exposes an MCP server that authenticated AI clients can connect to, using
Application Passwords for authentication. It also optionally calls Anthropic, OpenAI,
or Google's AI APIs (your choice, your own API key) to summarize content. No data is
sent externally until you configure a provider API key in Settings.Step 4: The review process, in plain terms
Every plugin submitted to WordPress.org is examined before approval. In practice, that
review checks for exactly the concerns this lesson and the rest of this track have
already trained you to handle correctly: proper sanitization and escaping, a
GPL-compatible license across every bundled file, no disallowed trialware pattern, and
clear disclosure of any external service calls. A plugin built following Course 4’s
permission_callback hardening, this course’s honest handling of the adapter’s
limitations, and this lesson’s licensing and disclosure requirements is already
addressing the review team’s actual concerns, not just guessing at what they want.
Test it
Before submitting, run through your own plugin as if you were the reviewer: grep for any hardcoded API call that fires without a configured, opted-in API key, and confirm your readme actually names every external service your plugin can contact.
grep -rn "wp_remote_\|wp_ai_client_prompt" --include="*.php" . For every match, confirm it’s gated behind an explicit setting the site owner configured themselves, not something that runs by default on activation.
The difference between “a smaller free plugin plus a separately sold Pro plugin” and “one plugin that cripples itself after a trial” is entirely about whether the free listing’s own functionality stays complete forever. If your business model description uses the words “trial,” “unlocks after,” or “limited to N calls before upgrading” about functionality inside the free WordPress.org listing itself, stop and restructure it as a genuinely separate paid product instead.
Recap
A commercial MCP plugin on WordPress.org needs GPL-compatible licensing across every bundled file, a freemium or SaaS model rather than trialware (the free listing’s own abilities must keep working, indefinitely, not lock after a trial or quota), and clear, opt-in disclosure of every external call, whether that’s an MCP client connecting in or your own code calling out to an AI provider. Every plugin gets examined before approval, and the checks map directly onto the security and honesty practices this whole track has built toward.
That’s the full track. Starting from the basic shape of an ability in Course 1 through to a publishable, production-grade, commercially viable MCP plugin here, you’ve now covered the entire WordPress AI development stack this track set out to teach.
Resources & further reading
- Detailed Plugin Guidelines, developer.wordpress.org
- WordPress.org Plugin Directory guidelines, wordpress.org
- The WordPress.org Plugin Directory, Plugin Handbook, developer.wordpress.org