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.
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.
- 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-prims` prints the primitives with the capabilities and roles each needs
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.
One command plus a key — npx @rnaga/wp-mcp -- local config-set, then supply credentials