LABSCO SUMMARY
Permissions come from WordPress, not from a config flag.
Assuming a WordPress user and letting that user's roles decide which primitives exist is the design decision worth noting — it means a mistake in a prompt cannot reach an operation the account could not perform in wp-admin either. Direct database access is the trade: it skips REST entirely and keeps the business logic, but it also means the server needs credentials to your WordPress database, so the stdio mode belongs on a machine you trust.
What it is
A WordPress server built on @rnaga/wp-node that talks to the database directly rather than through wp-admin. It runs as a local stdio server, as an Express-based Streamable HTTP server, or through a CLI proxy that bridges the two.
What you get
- Posts — create, update, read and delete posts and their revisions
- Comments — moderate threads or add generated replies
- Users — onboard contributors, adjust roles, disable accounts, with native capability checks
- Terms — categories, tags and custom taxonomies
- Metadata — inspect, create, update and delete post, user, comment, term and site meta
- Settings and options — site-level configuration
- The tool list is filtered by the WordPress user you assume: an administrator sees everything, a subscriber sees a fraction.
npx @rnaga/wp-mcp -- utils list-primsprints the primitives with the capabilities and roles each needs
Requirements
The npm package @rnaga/wp-mcp, version 1.0.9, run as npx -y @rnaga/wp-mcp -- local start. LOCAL_USERNAME picks the WordPress user whose capabilities gate the tools. Database access is required: WP_DB_HOST, WP_DB_NAME, WP_DB_USER and WP_DB_PASSWORD, with WP_DB_PORT defaulting to 3306; local config-set walks through them and can add SSL CA, cert and key paths. The HTTP server supports OAuth or a WordPress Application Password for remote clients.
Setup effort
One command plus credentials — npx @rnaga/wp-mcp -- local config-set, then supply credentials
USE CASES
01
Writing a post in conversation and publishing it
Draft, refine, and land it in the database without a trip through the admin screen.
02
Auditing who can do what
Inspect users, roles and capabilities to produce an access report for a site you inherited.
03
Cleaning up taxonomies and meta
Fix categories, tags and custom fields in bulk instead of clicking through the admin.
04
Letting a client connect without database access
Host the Streamable HTTP server and point the CLI proxy at it, so clients without OAuth support still work.
BEFORE YOU INSTALL
What to know first
Requires
- npx on PATH
- WP_DB_PASSWORD in your environment
- LOCAL_USERNAME in your environment
Where it runs
Both documented setups run the server on your machine.
INSTALLATION
Connect your client
Server setup
TERMINAL
npx @rnaga/wp-mcp -- local config-setMCP Clients
Claude Desktop — local stdio
CLAUDE DESKTOP — LOCAL STDIO · JSON
{
"mcpServers": {
"wp-mcp": {
"command": "npx",
"args": [
"-y",
"@rnaga/wp-mcp",
"--",
"local",
"start"
],
"env": {
"LOCAL_USERNAME": "wp-admin"
}
}
}
}wp-admin is a sample; yours is your WordPress username, and its role decides which tools appear. The block does not carry the database connection (WP_DB_HOST, WP_DB_NAME, WP_DB_USER, WP_DB_PASSWORD): run npx @rnaga/wp-mcp -- local config-set first, which saves them, or export them before the server starts.
Claude Desktop — remote proxy
CLAUDE DESKTOP — REMOTE PROXY · JSON
{
"mcpServers": {
"wp-mcp": {
"command": "npx",
"args": [
"-y",
"@rnaga/wp-mcp",
"--",
"remote",
"proxy"
],
"env": {
"REMOTE_AUTH_TYPE": "oauth",
"REMOTE_URL": "<YOUR_WP_URL>/mcp"
}
}
}
}No database access on this machine: the proxy relays to a wp-mcp HTTP server that you or your host already run. <YOUR_WP_URL>/mcp is that server's URL. Sign in once before starting it — npx @rnaga/wp-mcp -- remote login oauth, or npx @rnaga/wp-mcp -- remote login password with a WordPress Application Password — and set REMOTE_AUTH_TYPE to oauth or password to match.