MainWP MCP Server
OfficialClick on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MainWP MCP ServerWhat sites need updates?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MainWP MCP Server
A MainWP Labs project, powered by MainWP
Manage your whole WordPress network by talking to your AI assistant. MainWP MCP Server connects Claude, Cursor, OpenAI Codex, VS Code Copilot, and other MCP-compatible tools to your MainWP Dashboard, so you can ask in plain English:
"Which sites have pending plugin updates?"
"Update WooCommerce everywhere it's behind."
"Which client sites are disconnected right now?"
The server is a small program that runs on your own computer, alongside your AI tool. Nothing new is installed on your Dashboard or your child sites. Your Dashboard stays in control: it exposes only the tools you allow, and by default anything classified as destructive stops for your confirmation before it runs.
What You Can Do
Site Management: List sites, check connection status, sync data, add or remove child sites
Update Management: See pending updates across all sites, apply core/plugin/theme updates
Plugin and Theme Control: View installed plugins and themes, activate or deactivate them
Client Organization: Manage client records, assign sites to clients, track costs
Bulk Operations: Sync, reconnect, or check connectivity across dozens of sites at once
Built for WordPress agencies and site managers who want AI assistance with their MainWP workflows.
Related MCP server: WP Pinch
Documentation
Full documentation lives at docs.mainwp.com/mcp-server:
Quickstart with screenshots, if this is your first MCP server
Setup for every AI client: Claude Desktop, Claude Code, Cursor, VS Code Copilot, OpenAI Codex, ZenCoder, and others
Safety & Permissions: the confirmation flow, safe mode, and tool filtering
Prompt Cookbook: ready-to-use prompts by task
Quick Start
Requirements: Node.js >=20.19.0 and MainWP Dashboard 6.0+
1. Create an Application Password. This is a separate password WordPress issues for tools like this one; it never changes your login and you can revoke it at any time.
Log into your MainWP Dashboard as an administrator
Go to Users > Profile (click your username in the top right)
Scroll to the Application Passwords section
Enter a name like "MainWP MCP Server" and click Add New Application Password
Copy the generated password immediately (it is only shown once; spaces are fine either way)
Tip: Create a dedicated WordPress user for API access rather than using your main admin account. It keeps the audit trail clean and is easy to revoke later.
2. Add the server to your AI tool. For Claude Desktop and most other MCP clients, the config block looks like this:
{
"mcpServers": {
"mainwp": {
"command": "npx",
"args": ["-y", "@mainwp/mcp"],
"env": {
"MAINWP_URL": "https://your-dashboard.com",
"MAINWP_USER": "admin",
"MAINWP_APP_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx"
}
}
}
}Config file locations and variants for each client are in the client setup guide. Prefer a central credentials file, or manage several Dashboards? See the configuration reference.
3. Restart your AI tool and ask: "List all my sites". A working setup returns your child sites by name and URL.
Start bounded. You don't have to expose every tool on day one. Grant the smallest set your workflow needs and widen from there. See Restrict Available Tools.
Claude Code plugin
Claude Code can install the server, an agent skill, and a set of /mainwp:* workflow commands in two steps:
/plugin marketplace add mainwp/mainwp-mcp
/plugin install mainwp@mainwp-mcpCredentials still come from your environment. The plugin carries no credential values; the server inherits MAINWP_URL, MAINWP_USER, and MAINWP_APP_PASSWORD from the environment Claude Code runs it in. If you already added a mainwp server by hand, move everything in its env block (credentials and any MAINWP_* settings such as safe mode or tool filters) into the environment that launches Claude Code, then remove that entry: Claude Code treats the plugin's server as a duplicate and never starts it, so the hand-added entry silently wins. Setup details are at docs.mainwp.com/mcp-server; the plugin's own conventions are in docs/plugin.md.
Alongside the server, the plugin installs the mainwp-dashboard agent skill. It loads automatically when a task involves managing sites through MainWP and teaches the agent how this server behaves: the tool catalog comes from your Dashboard at runtime, destructive operations stop for user confirmation, safe mode blocks destructive calls at execution, and tool filtering can remove tools on purpose. The plugin also registers ten workflow commands:
Command | What it does |
| Diagnose the MCP connection and configuration without exposing secrets |
| Show what your Dashboard exposes, grouped by capability |
| Executive summary of the network: site counts, update totals, health |
| Detailed report for one site: overview, updates, health, next actions |
| Diagnose one site: connectivity, sync health, pending updates, errors |
| Plan a safe update run: what to update, in what order, on which sites |
| Security-focused audit: outdated core, plugins, themes |
| Backup coverage and freshness across managed sites |
| Maintenance sweep across every site, ranked by urgency |
| Performance indicators for one site or the network, from Dashboard data |
For development, clone and build instead of npx:
git clone https://github.com/mainwp/mainwp-mcp.git
cd mainwp-mcp
npm ci
npm run buildFirst-run setup
If the server starts without a Dashboard URL or credentials, it does not fail to launch. It connects to your AI client in setup mode: the MainWP tools stay hidden and two setup tools take their place, so you can finish the configuration in the conversation instead of hunting through stderr.
mainwp_get_setup_statusreports what is missing and returns the setup instructions for your assistant to relay. If credentials are present but the Dashboard was unreachable at startup, calling it again retries the connection with the credentials already loaded.mainwp_configuretakes a Dashboard URL, username, and Application Password, verifies them against the Dashboard, and saves them.
Two ways to finish setup:
Adding the credentials yourself is the recommended path. Put MAINWP_URL, MAINWP_USER, and MAINWP_APP_PASSWORD in the env block of this server's entry in your MCP client config (see Quick Start) or in ~/.config/mainwp-mcp/settings.json, then restart the client. The password never passes through the conversation.
Pasting them in chat is also fine. Your assistant collects the three values and calls mainwp_configure. The server verifies them, writes them to ~/.config/mainwp-mcp/settings.json with owner-only permissions (0600, in a 0700 directory), and scrubs the password from its own logs and from every response. An Application Password is separate from your WordPress login password and you can revoke it from your profile at any time. Worth knowing before you choose: the password also becomes part of your chat history, which your AI client and provider may retain. If that bothers you later, revoke the password and create a new one.
Once configuration succeeds, the full tool list appears in the same session for clients that honor MCP list-changed notifications. Clients that do not refresh on their own need a reconnect or restart.
mainwp_configure refuses rather than saving something that would be ignored or overridden:
Any connection environment variable (
MAINWP_URL,MAINWP_USER,MAINWP_APP_PASSWORD,MAINWP_TOKEN) is set. Environment variables outrank the file it writes, so finish setup there.A
settings.jsonexists in the server's working directory. That file is loaded first and would permanently shadow the saved credentials.The server already has credentials loaded, whether or not they are currently working. Setup will not replace existing credentials from chat. If the connection is failing,
mainwp_get_setup_statusretries with the credentials already loaded; to change them, edit the config file or the client'senvblock.
It writes only those three connection fields, never security settings, and blocking mainwp_configure through MAINWP_BLOCKED_TOOLS removes chat-based setup entirely while leaving the manual path documented.
Why setup will not replace credentials you already have
Chat-based setup can get you connected the first time, but it can never overwrite a connection you set up yourself. That line is deliberate, and it is worth knowing where it costs you something.
The reason is that an assistant acts on text, and text can come from places you did not intend. A page it read, a site name, or an ability description returned by a server could carry instructions aimed at the assistant rather than at you. If setup could overwrite a working configuration, that kind of injected instruction could quietly repoint your server at someone else's Dashboard, and every command you ran afterwards would go there. Restricting setup to the case where there is nothing to overwrite removes that possibility, because a server that has no credentials has nothing worth stealing.
A tempting middle ground is to allow it when the stored credentials are provably wrong, since the Dashboard rejected them with an authentication error. We do not do that, because it would let the remote side decide when your local configuration may be replaced: a Dashboard that had been compromised, or a connection someone was tampering with, could reject a valid login on purpose to unlock the replacement path, without ever knowing your password.
The cost is real, and it lands in one place. If you rotate the Application Password in WordPress, or the stored one is wrong for any other reason, retrying will not help, because the retry reuses the same credentials the Dashboard is already refusing. You have to put the new password in ~/.config/mainwp-mcp/settings.json or your client's env block yourself and restart the client. That is the same edit you would have made to set the server up manually in the first place, and it takes a minute.
Configuration
Variable | Required | Default | Description |
| Yes | Base URL of your MainWP Dashboard | |
| For basic auth | WordPress admin username | |
| For basic auth | WordPress Application Password | |
| No | Compatibility only; the Abilities API is expected to reject bearer tokens. Use an Application Password | |
| No |
| Skip SSL verification (dev only) |
| No |
| Allow HTTP URLs (credentials sent in plain text) |
| No |
| Block destructive operations |
| No |
| Require two-step confirmation for destructive operations |
| No | Whitelist of tools to expose | |
| No | Blacklist of tools to hide | |
| No |
|
|
| No |
| Response JSON formatting: |
| No |
| Maximum API requests per minute ( |
| No |
| Request timeout in milliseconds |
| No |
| Maximum single response size in bytes (10MB) |
| No |
| Maximum cumulative session data in bytes (50MB) |
| No |
| Enable automatic retry for transient errors |
| No |
| Total retry attempts including initial request |
| No |
| Base delay between retries in milliseconds |
| No |
| Maximum delay between retries in milliseconds |
| No |
| Comma-separated ability namespace allowlist |
"Required" means required to connect to a Dashboard, not required to start. With no URL and no credentials the server still launches in setup mode and you can supply all three values from the conversation instead. See First-run setup.
⚠️ Security Warning: SSL Verification
Setting
MAINWP_SKIP_SSL_VERIFY=truedisables SSL certificate verification, making your connection vulnerable to man-in-the-middle (MITM) attacks. Only use for local development with self-signed certificates or isolated test environments. Never use in production or on untrusted networks.
Instead of environment variables, you can use a settings.json file in the working directory or ~/.config/mainwp-mcp/settings.json; environment variables override file settings. A working-directory settings.json cannot loosen security settings: requireUserConfirmation: false, skipSslVerify: true, and allowHttp: true are ignored there with a warning on stderr. Set those through environment variables or the per-user file. Field names, the settings-to-variable mapping, and per-setting detail are in the Configuration Reference.
Tools
Around 60 tools, organized by category (the exact count varies by Dashboard version):
Category | Tools | Reference |
Sites | 30 | |
Updates | 13 | |
Clients | 11 | |
Tags | 7 | |
Batch Operations | 1 |
Tool names drop the mainwp/ namespace and use underscores: the ability mainwp/list-sites-v1 is the tool list_sites_v1. Naming rules, the built-in MCP resources (mainwp://abilities, mainwp://status, and friends), and namespace prefixing for third-party abilities are covered in Tools & Resources.
Safety
Operations classified as destructive (the deletion tools, plus any ability that does not declare itself non-destructive) use a two-step flow by default: the server returns a preview and a one-time token, your AI shows you what will be affected, and only your explicit approval executes it. Disabling the flow (MAINWP_REQUIRE_USER_CONFIRMATION=false) removes that gate. Safe mode (MAINWP_SAFE_MODE=true) blocks destructive operations entirely, and tool filtering can remove them from the AI's view altogether. The full model, including what safe mode does and does not protect against, is on Safety & Permissions; the underlying trust and credential model is in the Security Model.
Contributing
npm ci # install dependencies
npm run dev # run in watch mode
npm run inspect # test with MCP Inspector
npm test # run tests
npm run lint # check code style
npm run format # fix formattingCI runs lint, format check, type check, tests, and build on every pull request.
When changing configuration options, update both the environment-variable table above and the docs-site configuration reference; they are maintained in parallel.
.agents/skills/mainwp-dashboard is the canonical copy of the cross-agent skill, read directly by Codex CLI and other agent-skills clients and mirrored into the Claude Code plugin by npm run sync-skill. Edit it there, never in plugins/. See docs/plugin.md.
License
GPL-3.0. See LICENSE.
Available Tools
2 toolsmainwp_configureADestructive
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.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | WordPress admin username on the Dashboard | |
| dashboard_url | Yes | HTTPS URL of the MainWP Dashboard, for example https://dashboard.example.com | |
| application_password | Yes | WordPress Application Password for that user |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses credential verification, file save path with owner-only permissions, password scrubbing from logs, and non-echo behavior—rich detail beyond the annotations' destructiveHint. This gives the agent a clear safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: purpose, requirements, verification, storage, security, and precondition are packed into a compact, front-loaded description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a configuration mutation with no output schema, the description covers prerequisites, side effects, security, and state constraints. No critical gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all three parameters with descriptions (100% coverage). The description adds the constraint that all three must be supplied together, which is a minor supplement beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Connect this server to a MainWP Dashboard'), clearly distinguishing the action from the sibling status-check tool. It states the goal unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: requires all three values at once and is only usable before the server is connected. It does not explicitly name the sibling alternative but the precondition implies when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mainwp_get_setup_statusARead-onlyIdempotent
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds meaningful behavioral context: the tool retries the connection if credentials exist but the Dashboard is unreachable, which is not evident from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, usage timing, and retry behavior. It is front-loaded with the primary purpose and remains compact without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, but the description covers the essential context: what it reports, when to call it, and the retry behavior. It is complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema coverage is 100%, so there is nothing for the description to add about parameter meanings. The baseline of 4 applies for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and names the resource (MainWP server connection to Dashboard), clearly distinguishing it from the sibling tool mainwp_configure. It also clarifies the dual purpose: reporting connection status and returning setup instructions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this first when MainWP tools are missing,' which is a clear when-to-use directive. It also notes the retry behavior when credentials exist but the Dashboard is unreachable. However, it does not explicitly contrast with the sibling mainwp_configure, leaving some ambiguity about when to use the configure tool instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v1.2.0- First observed
mainwp_configure - First observed
mainwp_get_setup_status
TDQS
The two tools have completely distinct purposes: one configures the connection, the other reports status. There is no overlap or ambiguity between them.
Both tools follow a consistent 'mainwp_' prefix followed by a verb phrase (configure, get_setup_status). The naming pattern is clear and predictable.
With only two tools, the set is minimal but appropriate for the specific setup/status functionality it covers. Each tool earns its place, though the overall server appears to be a thin slice of a larger domain.
For the stated domain of initial connection setup, the tools cover configuration and status checking without obvious gaps. A disconnect or update-credentials tool could be considered missing, but the core setup lifecycle is complete.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Security-first WordPress MCP server. 129 tools for Claude, ChatGPT, Gemini. Free on wp.org.
AI-powered design and management for Webflow Sites
Sync Lightroom, Figma, Dropbox & Canva assets to WordPress and Shopify via natural language.
Sync Lightroom, Figma, Dropbox & Canva assets to WordPress and Shopify via natural language.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI assistants to manage WordPress sites through natural conversation, supporting post creation, content updates, site queries, and draft-to-publish workflows via the WordPress REST API.9MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to manage and interact with WordPress sites through MCP, providing tools for content creation, moderation, WooCommerce operations, and governance.47GPL 2.0
- AlicenseCqualityCmaintenanceEnables AI assistants to manage WordPress content, design, SEO, WooCommerce, and more through natural language commands.100323MIT
- FlicenseNot gradedqualityDmaintenanceEnables AI agents to manage WordPress sites via ~74 capabilities including content, media, plugins, themes, and more.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mainwp/mainwp-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server