WordPress.com shipped an official WordPress.com Claude Connector. I have been hand-rolling custom REST API bridges for this exact job for years, so my first reaction was relief. Giving a model live context about a site used to mean application passwords or a scraper that fell over regularly. The connector uses a standardized protocol instead, so Claude can query your site data without any boilerplate on your side.
A decade of authentication race conditions and transient storage bugs will make you appreciate a clean OAuth 2.1 implementation, and this one is clean. The practical difference is that Claude stops guessing about sites in general and starts answering about your site in particular. The plumbing underneath is the Model Context Protocol (MCP), which is on its way to being the standard way models reach external data sources.
What the WordPress.com Claude Connector changes
A client asking for a summary of their last 50 comments used to mean a custom script, pagination handling, and making sure the Authorization: Bearer header did not expire halfway through the run. The WordPress.com Claude Connector removes that whole middle layer. Claude gets read-only access to a specific set of tools that the WordPress.com MCP server defines.
The connector runs on OAuth 2.1, a long way from the OAuth 1.0a flows we dealt with in the early days of the Jetpack API. The part that matters is granular permission scoping: Claude can read your traffic and your content, and it cannot delete your homepage or change the admin password. I have written more about where these protocols are heading in my notes on the WordPress MCP Adapter.
How the flow works
Enabling the connector makes Claude an MCP client. It asks the WordPress.com server which “tools” are available, and those tools are wrapper functions around REST API endpoints that already exist. A server-side definition looks roughly like this:
{
"name": "get_site_traffic",
"description": "Returns traffic stats for the last 30 days",
"inputSchema": {
"type": "object",
"properties": {
"site_id": { "type": "string" },
"days": { "type": "number", "default": 30 }
}
}
}Ask Claude to show your traffic and it calls that tool, takes the JSON payload back from the WordPress.com API, and writes up what the numbers say. Without the connector you would be exporting CSVs and uploading them by hand, which nobody keeps doing for long.
Setting it up
No terminal involved, which my non-dev clients will be glad to hear. Enable MCP in your WordPress.com settings, pick the site, then authorize the connection from Claude’s connector directory. The handoff is a proper secure one rather than the old “copy-paste your API key” routine that leaked so many credentials.
One thing to know before you plan around it: the connector is read-only for now. Claude will not publish posts or refactor your CSS through it. What it does well is analysis, so finding stale content, summarizing engagement, spotting traffic patterns. If you want agents to locate specific data points faster for heavier editorial work, optimizing your site search via REST API is still worth doing.
If this is eating hours you would rather spend on billable work, I can take it on. I have been working with WordPress since the 4.x days.
Where this leaves AI-native WordPress
Anthropic and Automattic working together on this says something about where WordPress is going, toward a platform that assumes AI clients are part of the audience. Standardizing on MCP and OAuth 2.1 means the agentic workflows we build sit on shared plumbing instead of one-off integrations. The MCP Documentation and the WordPress.com OAuth 2.1 Guide have the official details. Your site already generates the data, and this is a straightforward way to start asking it questions.
