Problem

Studio already supports remote WordPress.com site operations in Studio Code, but that capability is only available inside the Studio Code agent runtime. External agents that connect through studio mcp only see the static local Studio MCP tool registry, so they cannot use Studio as a single WordPress capability surface for both local Studio sites and remote WordPress.com sites.

This creates downstream branching for integrations such as Build with WordPress / Codex plugins:

• Local site build and review workflows use Studio MCP.
• Live WordPress.com content, plugin, domain, DNS, and site-management workflows need a separate WordPress.com app/MCP surface.
• Skills then have to teach agents to route between two different tool planes instead of letting Studio broker the WordPress workflow.

cc @glendaviesnz @youknowriad for context.

Existing Studio prior art

This is not a request to invent remote WordPress.com support from scratch.

• #2992 added remote WordPress.com REST API support for Studio Code.
• In the initial #2992 implementation, remote-site mode created an MCP-shaped studio tool surface containing wpcom_request and take_screenshot; the prompt told the agent to call mcp__studio__wpcom_request.
• #3337 later unified the CLI agent onto the pi runtime. That preserved wpcom_request as an internal Studio Code tool, but removed the old Claude SDK MCP-server packaging (createRemoteSiteTools).
• The standalone studio mcp command still exposes only resolveStudioToolDefinitions(), which is a static local Studio registry and does not include wpcom_request.
• Studio Code: compose prompts and tools from resolved site capabilities #3333 is related: it proposes composing prompts/tools/schemas/gates from resolved WordPress.com site capabilities. This issue is narrower and downstream-facing: external agents should be able to access remote WordPress.com operations through the Studio MCP surface.

Relevant code today:

• apps/cli/ai/tools/wpcom-request.ts implements wpcom_request.
• apps/cli/ai/runtimes/pi/index.ts adds wpcom_request only when activeSite.remote && activeSite.wpcomSiteId && wpcomAccessToken.
• apps/cli/ai/mcp-server.ts starts the public Studio MCP server and lists/calls resolveStudioToolDefinitions().
• apps/cli/ai/tools/index.ts defines studioToolDefinitions, which does not include a remote WordPress.com request tool.

Why this matters

A single Studio MCP surface would let external tools use Studio as the WordPress broker:

external agent -> studio mcp -> local Studio tools + remote WordPress.com tools

That unlocks cleaner integrations for Codex, Claude Code, Cursor, and other Build with WordPress surfaces:

• One server to configure: Studio MCP.
• One vocabulary for local build, review, screenshot, validation, sync, and remote WordPress.com operations.
• Less branching in skills and prompts.
• Better reuse of Studio authentication and site selection.
• A path toward replacing broad prompt-heavy REST guidance with capability-aware, scoped remote tools.

Suggested short-term shape

Expose a scoped remote WordPress.com operation path through studio mcp.

One pragmatic first step could be making wpcom_request available through Studio MCP when the server can resolve the required context:

• authenticated WordPress.com token from studio auth login
• selected or explicitly provided remote WordPress.com site ID
• clear tool errors when no token/site context is available

This would not need to be the final architecture, but it would eliminate the immediate dual-MCP branching for external tools.

Longer-term direction

A better long-term contract is likely not a broad REST escape hatch as the primary tool. Studio should ideally expose a capability-aware remote WordPress.com tool layer that can be composed from resolved site capabilities, aligned with #3333, and eventually backed by curated WordPress.com MCP / Abilities semantics where appropriate.

That direction would let Studio expose product-shaped actions instead of asking external agents to infer endpoint semantics from prompts.

Acceptance criteria

• External MCP clients connecting to studio mcp can perform supported remote WordPress.com operations through Studio, not a separate WordPress.com app MCP.
• The remote tool path has an explicit site-selection or site-binding story.
• Missing auth/site context produces actionable errors.
• The implementation does not regress existing local Studio MCP tools.
• The issue is considered alongside Studio Code: compose prompts and tools from resolved site capabilities #3333 so prompt/tool/schema/runtime gates can converge instead of drifting.