WordPress CLI and MCP server
Prerequisites: Install the CLI
This skill drives the wordpress-cli binary. You must verify the CLI is installed before invoking any command from this skill. If it is missing, install it first:
- macOS / Linux:
bash <(curl -fsSL https://raw.githubusercontent.com/Servosity/msp-skills/main/skills/wordpress/install.sh) - Windows (PowerShell):
iwr -useb https://raw.githubusercontent.com/Servosity/msp-skills/main/skills/wordpress/install.ps1 | iex - Verify:
wordpress-cli --version - Ensure
~/.local/bin(macOS / Linux) or%LOCALAPPDATA%\Programs\msp-skills(Windows) is on$PATH.
The installer downloads the wordpress-cli and wordpress-mcp binaries into ~/.local/bin
(macOS / Linux) or %LOCALAPPDATA%\Programs\msp-skills (Windows). It does not
register the skill with your agent and writes no MCP client config - see
mcp-install.md for that wire-up.
If --version reports "command not found" after install, the runtime cannot see the binary directory on $PATH. Do not proceed with skill commands until verification succeeds.
Publish and manage WordPress pages, posts, media, and taxonomies via the REST API - built for AI agents authoring landing pages with on-page SEO.
Command Reference
categories - List, read, and create post categories
wordpress-cli categories create- Create a categorywordpress-cli categories get- Get one categorywordpress-cli categories list- List categories
media - Upload, list, read, update, and delete media library items (images, video, audio, PDF)
wordpress-cli media upload- Upload an image, video, audio, or document and return its media idwordpress-cli media delete- Delete a media itemwordpress-cli media get- Get one media item by idwordpress-cli media list- List media library itemswordpress-cli media update- Update media metadata (title, alt text, caption)
pages - Create, read, update, delete WordPress pages - the primary landing-page surface
wordpress-cli pages create- Create a page - pass full HTML content, optionally a blank/canvas template and SEO metawordpress-cli pages delete- Delete a page (trash, or force-delete)wordpress-cli pages get- Get one page by idwordpress-cli pages list- List pages (filter by status, search, slug, parent)wordpress-cli pages update- Update a page (WordPress accepts POST for updates)
posts - Create, read, update, delete blog posts with categories and tags
wordpress-cli posts create- Create a postwordpress-cli posts delete- Delete a postwordpress-cli posts get- Get one post by idwordpress-cli posts list- List postswordpress-cli posts update- Update a post
settings - Read and update site-level settings (limited; requires admin auth)
wordpress-cli settings get- Get site settingswordpress-cli settings update- Update site settings
tags - List, read, and create post tags
wordpress-cli tags create- Create a tagwordpress-cli tags get- Get one tagwordpress-cli tags list- List tags
users - List and read users (for author assignment)
wordpress-cli users get- Get one user by idwordpress-cli users list- List users
Finding the right command
When you know what you want to do but not which command does it, ask the CLI directly:
wordpress-cli which "<capability in your own words>"
which resolves a natural-language capability query to the best matching command from this CLI's curated feature index. Exit code 0 means at least one match; exit code 2 means no confident match - fall back to --help or use a narrower query.
Auth Setup
Run wordpress-cli auth setup to print the URL and steps for getting a key (add --launch to open the URL). Then set:
export WORDPRESS_BASIC_AUTH="<your-key>"
To persist credentials, use wordpress-cli auth set-token <token>. Stored secrets live in credentials.toml under the data dir, not in config.toml.
Run wordpress-cli doctor to verify setup.
Agent Mode
Add --agent to any command. Expands to: --json --compact --no-input --no-color --yes.
Pipeable - JSON on stdout, errors on stderr
Filterable -
--selectkeeps a subset of fields. Dotted paths descend into nested structures; arrays traverse element-wise. Critical for keeping context small on verbose APIs:wordpress-cli categories list --agent --select id,name,statusPreviewable -
--dry-runshows the request without sendingOffline-friendly - sync/search commands can use the local SQLite store when available
Non-interactive - never prompts, every input is a flag
Explicit retries - use
--idempotentonly when an already-existing create should count as success, and--ignore-missingonly when a missing delete target should count as success
Response envelope
Commands that read from the local store or the API wrap output in a provenance envelope:
{
"meta": {"source": "live" | "local", "synced_at": "...", "reason": "..."},
"results": <data>
}
Parse .results for data and .meta.source to know whether it's live or local. A human-readable N results (live) summary is printed to stderr only when stdout is a terminal AND no machine-format flag (--json, --csv, --compact, --quiet, --plain, --select) is set - piped/agent consumers and explicit-format runs get pure JSON on stdout.
Paths and state
Agents should treat the CLI's path resolver as part of the runtime contract:
Use
--home <dir>for one invocation, or setWORDPRESS_HOME=<dir>to relocate all four path kinds under one root.Use per-kind env vars only when a specific kind must diverge:
WORDPRESS_CONFIG_DIR,WORDPRESS_DATA_DIR,WORDPRESS_STATE_DIR,WORDPRESS_CACHE_DIR.Resolution order is per-kind env var,
--home,WORDPRESS_HOME, XDG (XDG_CONFIG_HOME,XDG_DATA_HOME,XDG_STATE_HOME,XDG_CACHE_HOME), then platform defaults.configcontains settings likeconfig.tomland profiles.datacontainscredentials.toml,data.db, cookies, and auth sidecars.statecontains persisted queries, jobs, andteach.log.cachecontains regenerable HTTP/cache files.Stored secrets live in
credentials.tomlunder the data dir. Existing legacyconfig.tomlsecrets are read for compatibility and leaveconfig.tomlon the first auth write.Run
wordpress-cli doctor --fail-on warnto surface path and credential-location warnings.agent-contextexposes a schema v4pathsblock for agents that need the resolved dirs.For MCP, pass relocation through the MCP host config. The MCP binary does not inherit CLI flags:
{ "mcpServers": { "wordpress": { "command": "wordpress-mcp", "env": { "WORDPRESS_HOME": "/srv/wordpress" } } } }
Fleet precedence: an inherited per-kind env var overrides an explicit --home for that kind. Use WORDPRESS_HOME or per-kind vars as durable fleet levers, and use --home only for a single invocation. Relocation is not reversible by unsetting env vars; move files manually before clearing WORDPRESS_HOME, or doctor will not find credentials left under the former root.
Agent Feedback
When you (or the agent) notice something off about this CLI, record it:
wordpress-cli feedback "the --since flag is inclusive but docs say exclusive"
wordpress-cli feedback --stdin < notes.txt
wordpress-cli feedback list --json --limit 10
Entries are stored locally as feedback.jsonl under the resolved data dir. They are never POSTed unless WORDPRESS_FEEDBACK_ENDPOINT is set AND either --send is passed or WORDPRESS_FEEDBACK_AUTO_SEND=true. Default behavior is local-only.
Write what surprised you, not a bug report. Short, specific, one line: that is the part that compounds.
Output Delivery
Every command accepts --deliver <sink>. The output goes to the named sink in addition to (or instead of) stdout, so agents can route command results without hand-piping. Three sinks are supported:
| Sink | Effect |
|---|---|
stdout |
Default; write to stdout only |
file:<path> |
Atomically write output to <path> (tmp + rename) |
webhook:<url> |
POST the output body to the URL (application/json or application/x-ndjson when --compact) |
Unknown schemes are refused with a structured error naming the supported set. Webhook failures return non-zero and log the URL + HTTP status on stderr.
Named Profiles
A profile is a saved set of flag values, reused across invocations. Use it when a scheduled agent calls the same command every run with the same configuration - for example a nightly job that always lists draft pages on one client's site.
wordpress-cli profile save briefing --json
wordpress-cli --profile briefing categories list
wordpress-cli profile list --json
wordpress-cli profile show briefing
wordpress-cli profile delete briefing --yes
Explicit flags always win over profile values; profile values win over defaults. agent-context lists all available profiles under available_profiles so introspecting agents discover them at runtime.
Exit Codes
| Code | Meaning |
|---|---|
| 0 | Success |
| 2 | Usage error (wrong arguments) |
| 3 | Resource not found |
| 4 | Authentication required |
| 5 | API error (upstream issue) |
| 7 | Rate limited (wait and retry) |
| 10 | Config error |
Argument Parsing
Parse $ARGUMENTS:
- Empty,
help, or--help→ showwordpress-cli --helpoutput - Starts with
install→ ends withmcp→ MCP installation; otherwise → see Prerequisites above - Anything else → Direct Use (execute as CLI command with
--agent)
MCP Server Installation
- Install the MCP binary (run the install script from the Prerequisites section, or see mcp-install.md for per-agent wire-up).
- Register with Claude Code:
claude mcp add wordpress-mcp -- wordpress-mcp - Verify:
claude mcp list
Direct Use
- Check if installed:
which wordpress-cliIf not found, offer to install (see Prerequisites at the top of this skill). - Match the user query to the best command from the Unique Capabilities and Command Reference above.
- Execute with the
--agentflag:wordpress-cli <command> [subcommand] [args] --agent - If ambiguous, drill into subcommand help:
wordpress-cli <command> --help.