Remote MCP modes

Status authority: Canonical Remote Relay status is the authoritative source for current maturity and outstanding release gates. This document describes architecture, operation, or evidence requirements and must not be read as an independent readiness claim.

EasyEDA MCP Pro supports three deployment modes. The modes share the same tool semantics, but they have different network and security boundaries.

Mode matrix

Mode	Primary use	Public endpoint	EasyEDA runs in	Recommended users
Local	Desktop MCP clients and development	No	User browser	Local-only users and developers
Hosted Remote	Managed connector/app experience	Maintainer-operated domain	User browser extension session	Claude Web, ChatGPT app, managed teams
Self-hosted Remote	User-managed remote MCP server	User domain/tunnel/VPS	User browser extension session	Power users, enterprises, private deployments

Local Mode

Local Mode keeps the current workflow:

MCP client
  ↓
localhost MCP server
  ↓
EasyEDA bridge extension
  ↓
Open EasyEDA Web project

This mode keeps safe local defaults and binds the EasyEDA bridge listener to loopback unless the operator explicitly configures otherwise. It is the default fallback and is not started when MCP_BRIDGE_BACKEND=remote_relay is selected.

Hosted Remote Mode

Hosted Remote Mode is the product-grade remote path:

Claude Web / ChatGPT / remote MCP client
  ↓
https://mcp.example.com/mcp
  ↓
Remote MCP Gateway
  ↓
Session Router
  ↓
Relay
  ↓
EasyEDA bridge extension
  ↓
Open EasyEDA Web project

The extension opens an outbound relay connection. The hosted gateway never connects directly to a user's local network.

Self-hosted Remote Mode

Self-hosted Remote Mode lets the operator expose their own endpoint:

Remote MCP client
  ↓
https://mcp.user-domain.example/mcp
  ↓
User-managed tunnel, reverse proxy, or VPS
  ↓
EasyEDA MCP server
  ↓
EasyEDA bridge extension
  ↓
Open EasyEDA Web project

Tunnels provide reachability only. They do not replace authentication, pairing, origin validation, rate limiting, or approval controls.

Common user journey

1. The user opens EasyEDA Web in a browser window.
2. The user activates the EasyEDA bridge extension.
3. The extension is placed in Local, Hosted Remote, or Self-hosted Remote mode.
4. The user pairs the extension session with the remote MCP client or hosted account.
5. Remote tool calls route to the paired EasyEDA project.
6. Read operations can run after auth and pairing.
7. A write/export/destructive call first requests approval in an EasyEDA confirmation dialog.
8. After approval, the client retries the identical MCP invocation with the returned remoteApprovalId; rejection, timeout, changed input, and replay fail closed.

Security responsibilities

Responsibility	Local	Hosted Remote	Self-hosted Remote
Keep local binding safe	Project	Project	Operator
Operate public TLS endpoint	N/A	Maintainer	Operator
Enforce auth	Optional local profile	Maintainer gateway	Operator server
Enforce pairing	Optional local profile	Required	Required
Approve risky actions	User	User + gateway	User + operator server
Audit remote calls	Optional	Required	Recommended/required for production

Related documents

• Remote security model
• Relay protocol
• Tool approval policy
• Self-hosted setup
• Claude Web connector setup
• ChatGPT app integration plan
• Observability model