I finally got Codex talking to this WordPress site through MCP. The short version: the local config was close, the WordPress endpoint itself was fine, but the thing that actually made the tools show up here was setting it up through the web interface as a plugin and then reloading the client.
What did not work at first
I started with a local MCP server entry in the Codex config pointing at this site’s Easy MCP AI endpoint:
[mcp_servers.wordpress]
enabled = true
url = "https://example.com/wp-json/easy-mcp-ai/v1/mcp"
bearer_token_env_var = "WORDPRESS_MCP_TOKEN"
That looked right on disk, but it did not make the WordPress tools appear in the running chat. The config was present, the server was enabled, and the endpoint URL was correct, but Codex’s live tool list still only showed the built-in app/plugin resources. In other words: configured is not the same thing as loaded.
The token/header trap
The other easy mistake was treating the token name as if it were the header name. Putting a value under a header called WORDPRESS_MCP_TOKEN is not the same thing as setting an environment variable named WORDPRESS_MCP_TOKEN, and it is not the same thing as sending Authorization: Bearer ....
When I tested the WordPress endpoint directly with a bearer token, the MCP initialize request came back clean. The server identified itself as easy-mcp-ai and advertised tools/resources for managing posts, pages, media, comments, users, and site settings. So the WordPress side was alive. The problem was getting Codex to expose it as an actual callable tool in the session.
What finally worked
The working path was to add it through the web interface as a plugin, then reload the Codex client and resume the chat. After that, the WordPress MCP namespace appeared immediately, with tools like:
wp_list_postswp_get_postwp_create_postwp_update_postwp_list_mediawp_get_site_settings
The first real verification was intentionally boring: list one recent post. That returned a scheduled post and proved the connection was not just installed-looking, but actually usable.
The practical checklist
- Install and configure the Easy MCP AI plugin on WordPress.
- Generate a token from the WordPress side.
- Add the MCP endpoint through the web/plugin interface, not just local config, if you want it available inside this Codex session model.
- Reload the Codex client after adding it.
- Verify with a read-only call first, like listing posts or reading site settings.
That last bit matters. A connector can be present in a settings screen, reachable over HTTPS, and still not be available to the model as a tool. The only test that counts is whether the WordPress tools actually show up and a harmless read works.
Net result: this post was created from Codex through the WordPress MCP plugin, which is probably the cleanest possible proof that the setup is working.
Leave a Reply