Connect Cursor to Your WordPress MCP Server

Cursor is a code editor with an AI agent built in, which makes it a genuinely useful client for a WordPress MCP server: you can ask it to update a page while you’re looking at the theme code that renders it. The connection mechanics are close to what you just did with Claude Desktop, same URL, same Application Password, different settings surface.

What you'll learn in this lesson

Adding a server through Cursor's MCP settings

The UI path for pointing Cursor at a remote server URL.

The mcp.json file format

Configuring the same connection at the project or global level instead.

Where project-level config beats global

When to scope a WordPress connection to one repo versus your whole editor.

Verifying tool calls from inside the editor

What a successful call looks like in Cursor's agent chat.

Prerequisites

The same working MCP server from Course 2 you used in the previous lesson, its endpoint URL, and an Application Password for a WordPress user scoped to the capabilities the agent should have. Cursor installed and updated to a version with MCP support.

Step 1: decide project-level or global

Cursor supports MCP server configuration at two scopes: a project-specific mcp.json that only applies inside that repo, and a global one that’s available across every project you open. If you’re managing a specific WordPress theme or plugin’s codebase in Cursor, project-level config keeps that connection tied to the relevant work. If you want the same WordPress site available no matter what you’re working on, use the global config instead.

Step 2: add the server through Cursor’s settings

Adding a server via the UI

Open Cursor Settings

Find the section for MCP servers, it lists any already-configured servers and an option to add one.

Add a new server

Provide a name for the connection and your MCP endpoint URL from Course 2.

Supply the auth header

Enter your WordPress username and Application Password as Basic auth, or paste the equivalent Authorization header value if Cursor asks for a raw header instead of separate fields.

Confirm the server shows as connected

Cursor performs the same initialize and tool-list handshake any MCP client does.

Step 3: or configure it directly in mcp.json

If you’d rather manage this as a file (useful for sharing a project’s MCP setup with teammates, minus the actual secret), create or edit mcp.json:

// File: .cursor/mcp.json
{
  "mcpServers": {
    "wordpress-site": {
      "url": "https://yoursite.com/wp-json/mcp/mcp-adapter-default-server",
      "headers": {
        "Authorization": "Basic YWdlbnQtYXNzaXN0YW50OmFiY2QgMTIzNCBlZmdoIDU2NzggaWprbCA5MDEy"
      }
    }
  }
}

For a global connection available in every project, the equivalent file lives outside any single repo, in Cursor’s own configuration directory rather than a project’s .cursor folder. The mcpServers object’s shape is identical either way.

Keep secrets out of committed project config

If .cursor/mcp.json sits inside a repo you share with a team, don’t commit the real Application Password into it. Add the file to .gitignore, or reference an environment variable if your version of Cursor supports variable substitution in this file, and share the base config as a template instead.

Step 4: test it in the agent chat

Open Cursor’s agent chat (not a plain code-completion prompt) and ask it to use the connection directly:

You: "Using the WordPress MCP server, list the tools you can call."

Then try an actual ability call, phrased naturally:

You: "Create a draft post on the WordPress site titled 'Cursor test post'
with one paragraph of placeholder text."

Signs the connection actually works

Cursor references the WordPress server by name

Matching the name you gave it in mcp.json or settings.

The agent chat shows a tool call, not a guess

You should see it invoking a specific tool with arguments, not generating fictional output.

wp-admin shows the real result

The draft post exists, created by the Application Password's user account.

How this compares to Claude Desktop

Connecting Claude Desktop versus Cursor to the same MCP server
Aspect	Claude Desktop	Cursor
Config surface	Settings UI or `claude_desktop_config.json`	Settings UI or `mcp.json`, project or global
Config key	`mcpServers`	`mcpServers`
Auth mechanism	Header, typically Basic auth with your Application Password	Same, header-based Basic auth
Typical use	General conversation and admin tasks	Tasks tied to the codebase you have open

The underlying protocol doesn’t care which client you’re using, this is the same point Lesson 8 in this course expands on: your WordPress MCP server serves tools, it has no idea which LLM or app is on the other end of the connection.

Cursor caching an old tool list

If you add a new ability to your server after Cursor already connected, Cursor may keep showing the old tool list until you reconnect or restart it. If a tool you just registered doesn’t show up, disconnect and reconnect the server entry rather than assuming the registration failed.

Recap

Cursor connects to your WordPress MCP server through the same URL-plus-header pattern as Claude Desktop, configured either through its settings UI or an mcp.json file at the project or global level. A working connection lets you ask Cursor’s agent chat to call your registered abilities directly, with results you can verify in wp-admin.

Resources & further reading

MCP Adapter repository, GitHub
Model Context Protocol specification, modelcontextprotocol.io