Skip to main content
Glama
mainwp

MainWP MCP Server

Official
by mainwp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Official MainWP MCP Server

The MainWP MCP Server connects Claude, Cursor, OpenAI Codex, VS Code Copilot, and other MCP-compatible AI tools to MainWP, the self-hosted dashboard for managing many WordPress sites, 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?"

"Check what we know about this client's sites before you update anything."

It runs on your own computer, next to your AI tool. Nothing new is installed on your Dashboard or your child sites.

You stay in control

  • Changes wait for your approval. By default, deleting a site, plugin, or theme shows you a preview first and runs only after you say yes. On Dashboard 6.3 and later, updates work the same way.

  • Safe mode blocks those destructive operations outright, with no approval prompt, while you get comfortable.

  • You choose the tools. Allow and block lists decide which tools your AI can see at all.

  • Your credentials stay with you. The server signs in with a WordPress Application Password that you can revoke at any time, and it talks only to your Dashboard.

How it all works: Safety & Permissions.

Related MCP server: WP Pinch

What you can do

  • Sites: list, sync, check connectivity, add, reconnect, or remove child sites

  • Updates: see pending core, plugin, theme, and translation updates across the network, and apply them

  • Plugins and themes: see what is installed, activate, deactivate, or delete

  • Clients and tags: manage client records, assign sites, and track costs

  • Knowledge: agency, client, and site notes, skills, and memories your AI reads before it works (Dashboard 6.3 and later)

  • Guided workflows: network summaries, site reports, security audits, and update plans

Around 70 tools in all, depending on your Dashboard version. See Tools & Resources.

Built for agencies and freelancers who manage many WordPress sites and want AI help with updates, maintenance, and client work.

Requirements

  • Node.js 20.19 or later on the computer that runs your AI tool

  • MainWP Dashboard 6.0 or later, reachable over HTTPS (some tools need a newer Dashboard; the Quickstart lists which)

  • An MCP-compatible AI client

Get started

1. Create an Application Password. In your MainWP Dashboard, go to Users > Profile > Application Passwords, add one named "MainWP MCP Server", and copy it. It is separate from your login password, and you can revoke it at any time. A dedicated administrator account for API access keeps the audit trail clean.

2. Add the server to your AI tool. For Claude Desktop and most other MCP clients:

{
  "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"
      }
    }
  }
}

3. Restart your AI tool and ask "List all my sites". A working setup returns your child sites by name and URL.

Config file locations for each client are in the client setup guide. Every setting is in the Configuration Reference.

Using Claude Code? The plugin installs the server, an agent skill, and ten /mainwp:* workflow commands:

/plugin marketplace add mainwp/mainwp-mcp
/plugin install mainwp@mainwp-mcp

Credentials still come from your environment. See Claude Code plugin.

Documentation

Full documentation lives at docs.mainwp.com/mcp-server:

Community

Contributing

Bug reports and pull requests are welcome. Please report security issues privately as described in SECURITY.md.

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 formatting

CI runs lint, format check, type check, tests, and build on every pull request. When you change a configuration option, update the docs-site configuration reference in the same change. .agents/skills/mainwp-dashboard is the canonical copy of the agent skill; see docs/plugin.md.

License

GPL-3.0. See LICENSE.

Available Tools

2 tools
mainwp_configureA
Destructive

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
usernameYesWordPress admin username on the Dashboard
dashboard_urlYesHTTPS URL of the MainWP Dashboard, for example https://dashboard.example.com
application_passwordYesWordPress Application Password for that user

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_statusA
Read-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. If the Dashboard rejected the credentials, this reports which user was rejected and where each value came from.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: it retries a failed connection and reports which user was rejected plus the provenance of each credential value, which an agent could not infer from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly-scoped sentences, front-loaded with the core purpose and the call-first directive. Every sentence adds a distinct condition (no connection, retry, credential rejection) with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no parameters, the description carries the burden of describing returns and does so — setup instructions to surface to the user, rejection details, credential provenance. A brief note on the shape of the returned instructions would close the remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description correctly implies a no-argument diagnostic call.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — reports whether the MainWP MCP server is connected to a Dashboard and returns setup instructions. It is clearly distinguishable in spirit from mainwp_configure, though it never names that sibling, so the differentiation is implied rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear triggering condition: 'Call this first when MainWP tools are missing.' It also explains the retry case (credentials present but Dashboard unreachable). It stops short of naming mainwp_configure as the alternative for acting on the reported status.

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.

  1. 2 tool updatesv1.2.0
    • First observedmainwp_configure
    • First observedmainwp_get_setup_status
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency4/5

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).

Tool Count3/5

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.

Completeness3/5

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.

Maintenance

ActivityMaintained
ResponsivenessSlow

Resources

Related MCP Connectors

Related MCP Servers