Skip to content
BuildPressBeta
Reference

MCP Endpoint and Resources

The endpoint, transport, and the context your AI receives automatically over MCP.

BuildPress speaks the Model Context Protocol from a single endpoint on your own site. There is no proxy, no relay, and no external BuildPress account in the path. This page is the quick reference for that endpoint, the transport it uses, and the context your AI gets over MCP without any setup from you.

Endpoints

BuildPress exposes two REST routes under the buildpress/v1 namespace. The first is the MCP endpoint your client connects to. The second is a public health check you can open in a browser to confirm the site is reachable.

Endpointstext
https://your-site.com/wp-json/buildpress/v1/mcp https://your-site.com/wp-json/buildpress/v1/status

The /status route is a GET with no authentication, so it is a fast way to check that the REST API is up before you debug a connection. The /mcp route is the one your AI client talks to, and it always includes the /v1 segment.

Transport

The endpoint uses MCP Streamable HTTP and accepts POST only. GET and DELETE return a 405 by design, which keeps clients on POST so they do not fall back to the deprecated SSE transport. Most clients do not connect to the raw URL at all. They run the Automattic bridge (@automattic/mcp-wordpress-remote), which speaks WordPress REST with Application Password Basic Auth and reads the endpoint from the WP_API_URL environment variable.

You almost never paste the raw URL

The config your client generates points at the Automattic bridge over npx, not at a raw HTTP transport. The MCP endpoint goes into the WP_API_URL env var alongside your WordPress username and Application Password.

For the full per-client setup, see Connect your AI client.

What your AI receives

Beyond the build tools, BuildPress supplies your AI with context automatically over MCP. At session start it loads your capabilities and active integrations, your design system state, your Project Memory, and the build guidance that keeps work on-brand. You do not write or configure these prompts yourself. To see how that context shapes a build, read How it works.

  • Capabilities and active integrations, so your AI knows which tools are live (WordPress core, Elementor, JetEngine, ACF, and the rest auto-detect).
  • Your design system state, so every widget binds to your tokens instead of hardcoded colors or sizes.
  • Project Memory, so your brand voice, design direction, and prior decisions carry across sessions.
  • Build guidance, the always-on quality floor that keeps pages looking designed rather than generic.

Check the connection from your client

Ask your AI to list the available BuildPress tools, or run your client's own list command. If the tools appear, the endpoint, transport, and context are all wired up.

Your AI clientConnected
$claude mcp list buildpress
wp_create_postready
elementor_create_pageready
elementor_add_elementready
elementor_update_elementready
design_system_get_tokensready
buildpress_rememberready
wp_check_frontend_renderready
figma_sync_to_elementorready
/wp-json/buildpress/v1/mcp over MCP Streamable HTTP (POST).
An MCP client listing the BuildPress tools and confirming a live connection to the wp-json/buildpress/v1/mcp endpoint.
Share