MainWP MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MAINWP_URL | No | Base URL of your MainWP Dashboard | |
| MAINWP_USER | No | WordPress admin username | |
| MAINWP_SAFE_MODE | No | Block destructive operations. Default false. | false |
| MAINWP_ALLOW_HTTP | No | Allow HTTP URLs (credentials sent in plain text). Default false. | false |
| MAINWP_MAX_RETRIES | No | Total retry attempts including initial request. Default 2. | 2 |
| MAINWP_APP_PASSWORD | No | WordPress Application Password | |
| MAINWP_ALLOWED_TOOLS | No | Whitelist of tools to expose (string, e.g., comma-separated). | |
| MAINWP_BLOCKED_TOOLS | No | Blacklist of tools to hide (string). | |
| MAINWP_RETRY_ENABLED | No | Enable automatic retry for transient errors. Default true. | true |
| MAINWP_RETRY_MAX_DELAY | No | Maximum delay between retries in milliseconds. Default 2000. | 2000 |
| MAINWP_SKIP_SSL_VERIFY | No | Skip SSL verification (dev only). Default false. | false |
| MAINWP_RETRY_BASE_DELAY | No | Base delay between retries in milliseconds. Default 1000. | 1000 |
| MAINWP_SCHEMA_VERBOSITY | No | standard or compact. Default standard. | standard |
| MAINWP_REQUIRE_USER_CONFIRMATION | No | Require two-step confirmation for destructive operations. Default true. | true |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| mainwp_get_setup_statusA | Report whether the MainWP MCP server is connected to a Dashboard yet, and return the setup instructions to show the user. Call this first when MainWP tools are missing. If the server has credentials but could not reach the Dashboard, this retries the connection. If the Dashboard rejected the credentials, this reports which user was rejected and where each value came from. |
| mainwp_configureA | Connect this server to a MainWP Dashboard using credentials the user supplied in chat. Requires all three values at once. The credentials are verified against the Dashboard, then saved to ~/.config/mainwp-mcp/settings.json on this machine with owner-only permissions; the password is scrubbed from server logs and never echoed back. Only usable before the server is connected. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct roles: one is a read-only status/diagnostic reporter and the other performs the one-time configuration write. An agent can unambiguously pick between 'tell me the state' and 'set up the connection' without overlap.
Both names use the same mainwp_ snake_case prefix, which is consistent. The only minor deviation is the verb form: one uses the get_ verb convention while the other is a bare action name (mainwp_configure).
Two tools is very thin for a server branded as full MainWP management; the surface only covers connection onboarding (status + configure). It is defensible if the scope is intentionally setup-only, but it sits at the borderline-thin end of the range.
Onboarding is covered by status and configure, but there is no way to disconnect, reset, or update credentials once connected (configure is explicitly only usable before connection). That leaves a notable lifecycle gap with no recovery path for bad or rotated credentials.