Skip to main content
This page is for the person deciding whether to trust the MainWP MCP Server with Dashboard credentials. The user-facing guardrails (confirmation flow, safe mode) are explained on Safety & Permissions; this covers what is underneath.

​
Trust model

The AI assistant has the same access as the WordPress user whose credentials you configure. Every tool call executes with that user’s capabilities. The server itself is a passthrough: it stores nothing, caches responses only briefly, and holds credentials only in memory during execution. The Dashboard enforces the permission boundary, whatever the AI asks for. MainWP tools require the manage_options capability, which WordPress administrators have, so a user without it gets a permission error on every MainWP tool call. A limited WordPress role therefore does not work as a restriction. To limit which operations the AI can run, use tool filtering and safe mode.

​
Credential management

Application Passwords are the authentication method. They can be revoked without touching your login password, each application gets its own password for auditing, and WordPress logs which application made each request. Practices worth following:
  • Use a dedicated WordPress user for MCP access, not your main admin account.
  • Create a unique Application Password per AI tool and label each clearly (“MainWP MCP - Claude”).
  • Keep production and development credentials separate.
  • If you use a settings.json file, restrict it with chmod 600 and keep it out of version control.

​
What gets logged

The server logs to stderr: destructive-operation audit messages, tool execution start and end (tool name, duration, outcome), safe mode blocks, resource limit violations, and configuration warnings. Credential-rejection diagnostics can include the configured username and the source of each connection setting. Setup status also identifies settings overridden by environment variables. See Rejected credentials. The server does not log passwords or tokens, tool arguments (which may contain sensitive data), response content (which may contain PII), or preview data for destructive operations. A username value that looks like an Application Password is withheld from rejection diagnostics. WordPress separately logs Application Password usage, so your Dashboard’s admin shows which application authenticated and when.
Web server logs can contain operation inputs. The current MCP server sends inputs for read-only GET requests and destructive, idempotent DELETE requests in the URL query string. Other write operations use a POST JSON body. Query-string inputs can appear in your Dashboard web server’s access logs; authentication credentials travel in headers. Restrict access-log visibility and set retention accordingly.MainWP Dashboard also supports a JSON body for DELETE requests through its Abilities input handling. Direct integrations can use that option to keep DELETE inputs out of URLs, but this Dashboard capability does not change the current MCP server’s query-string behavior.

​
Destructive-operation classification

The server classifies each ability as destructive or not from the destructive annotation the Dashboard declares. The stance is fail-closed: only a literal false counts as non-destructive. A missing or malformed annotation classifies the ability as destructive, which routes it into safe mode blocking and the confirmation gate. An ability that is classified destructive but declares no usable confirm parameter cannot complete the confirmation flow and is refused with CONFIRMATION_UNSUPPORTED rather than executed. The same classification gates the mainwp://site/{id} resource and completions. The practical consequence: a new, third-party, or misannotated ability defaults to blocked or gated, never to silently executable.

​
SSL/TLS

Certificates are verified by default and plain HTTP is refused. The skipSslVerify and allowHttp overrides exist for isolated local development only; both make credential interception possible. If you see SSL errors against a valid certificate, check that the chain is complete, the system CA store is current, and the certificate matches the domain in MAINWP_URL.

​
Pre-production checklist

  • Created a dedicated WordPress user for API access
  • Generated a unique Application Password for this integration
  • Confirmed the WordPress user has the manage_options capability
  • Configured tool filtering to expose only needed operations
  • Set appropriate resource limits
  • Verified SSL certificates are valid (no skipSslVerify)
  • Tested in safe mode first