Secure MCP Connector for Claude, ChatGPT and other AI providers

Add a custom connector pointing at your MCP endpoint, https://YOUR-SITE/wp-json/mosmcp/v1/mcp. The client discovers the OAuth endpoints automatically, registers itself, walks you through logging in to WordPress and approving access, and then connects. The site must be reachable over HTTPS (cloud clients cannot reach localhost); for local development, expose the site through an HTTPS tunnel such as ngrok or cloudflared.

Yes. To run the OAuth server it creates three database tables for registered clients, short-lived authorization codes, and access/refresh tokens. Tokens and client secrets are stored only as keyed hashes, never in plaintext. A single options row holds the plugin's hash salt. All of this is removed when the plugin is deleted.

Some Apache configurations strip the Authorization header before it reaches PHP. Add the following to your WordPress root .htaccess: RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

The Abilities API does not record which plugin registered a given ability. The namespace prefix (the part before the slash in the ability name) is the most reliable indicator of where an ability comes from.

The NHI (Non-Human Identity) Registry is where you create and manage named, role-based ability policies for AI clients. Each NHI maps WordPress roles to the abilities those roles may invoke. When an AI client makes an MCP request, the effective set of allowed abilities is the union — across every enabled NHI — of the abilities granted to the connecting user's role(s). So two users connecting the same client to the same site can see different tools, based on their roles. You can create as many NHIs as you need and toggle them on or off independently.

There are two levels of control. First, use the per-ability toggle on the Abilities screen to exclude an individual ability from being exposed as an MCP tool entirely — this applies regardless of any NHI policy. Second, use the NHI Registry to grant abilities per role: only the abilities mapped to the connecting user's role(s), across enabled NHIs, are reachable. The builder also flags "capability conflicts" — granting a role an ability whose required WordPress capability the role lacks — and blocks saving until they are resolved, so a grant can never silently do nothing.

Yes. Every NHI has an enable/disable toggle in the NHI Registry screen. A disabled NHI has no effect on MCP requests but its name and ability list are preserved, so you can re-enable it at any time without reconfiguring it.