1. Choose a runtime
WordPress for WooCommerce operations. Local for development work. Cloud only when a remote web client must reach Local.
Docs
From install to verified work.
MCPDO separates execution authority by runtime. Use the smallest setup that completes the job, then keep approvals and verification at the runtime that owns the capability.
2. Connect a client
WordPress uses its site-hosted OAuth/MCP endpoint. Local can be used directly by a compatible local client, or through Cloud for remote web clients.
3. Keep authority local
Inspect first, preview/propose mutations, require exact approval where policy demands it, execute only in the owning runtime, then verify independently.
Troubleshooting
Use these checks before changing configuration.
Cloud health: open
/health. Production should report ok:true, the trusted MCP URL, and the configured relay transports.Remote Local device offline: confirm MCPDO Local is running, the device remains paired, and outbound HTTPS is allowed. Hostinger production intentionally uses polling rather than incoming WebSockets.
Approval required: this is expected for destructive or privileged operations. Approve the exact pending operation in the runtime that owns it, then retry with that operation id.
WordPress write unavailable: confirm WooCommerce support, connection scope, per-tool policy, global write safety, fresh target state, and WordPress-admin approval. MCP OAuth does not create a WordPress login session.