Quick start

Choose only the runtimes you need.

MCPDO does not require a three-part installation. Start with WordPress, Local, or Local + Cloud. Combine them only when the workflow actually needs both site operations and development operations.

WordPress only
Standalone

Best for WooCommerce operational audits and bounded site changes from an MCP client.

  1. Install and activate MCPDO in WordPress.
  2. Run Store Health from MCPDO → Overview.
  3. Open Connections, choose your MCP client, and complete OAuth + PKCE.
  4. Keep writes disabled until you need a supported preview → approve → apply → verify flow.
The WordPress.org submission is still under manual review. Do not replace the submitted package unless reviewer feedback or a material compliance/security correction requires it.
Local only
No Cloud required

Best for AI-assisted local development with files, Git, terminal, tests, browser tooling, Docker, and project policy.

  1. Install MCPDO Local on the Mac.
  2. Register the project roots you want MCPDO to expose.
  3. Connect a local MCP-compatible client using MCPDO Local client setup.
  4. Approve destructive or privileged work locally when MCPDO requests it.
The verified free macOS build is currently ad-hoc signed. Public Developer ID signing/notarization remains an external Apple credential gate.
Local + Cloud
Remote access

Best when a web MCP client must securely reach the Mac from outside the local process boundary.

  1. Start MCPDO Local and pair the device with MCPDO Cloud.
  2. Connect the web MCP client to the Cloud endpoint below.
  3. Complete OAuth authorization.
  4. Cloud relays the request to Local; Local still owns policy, approval, execution, verification, and activity.
https://mcpdo.tophive.dev/mcp
WordPress + Local + Cloud
Power-user setup

Use both execution runtimes when one workflow spans development and a live WordPress/WooCommerce site.

  1. Connect the WordPress runtime using the site's own MCP endpoint.
  2. Connect MCPDO Cloud for the paired Local device.
  3. Use WordPress tools for store/business operations and Local tools for code/files/Git/terminal work.
  4. Do not duplicate capabilities between runtimes; each runtime keeps its own approval and verification boundary.
The current V1 does not silently merge the two endpoints into one capability namespace. They are compatible MCPDO runtimes with intentionally separate execution authority.