[Feature Request] Support the E2B-compatible mcp Sandbox option

Problem / Motivation

CubeSandbox already implements most of the E2B-compatible Sandbox creation API, but the mcp option is currently only represented as a compatibility field. It does not provide an MCP Gateway, MCP server startup, or an SDK method for retrieving the MCP endpoint.

As a result, applications that use the E2B MCP workflow cannot switch to CubeSandbox without a custom integration. They can create a regular Sandbox, but they cannot declare MCP servers in the creation request or obtain the MCP URL through the SDK.

The expected use case is an Agent running inside a Sandbox and using one or more MCP servers while retaining the E2B request and SDK shape.

E2B Reference Format

E2B accepts an MCP server configuration map in the Sandbox creation options. Each key identifies an MCP server and its value contains that server's configuration.

The corresponding Python API is:

from e2b import Sandbox

sandbox = Sandbox.create(
    mcp={
        "duckduckgo": {},
        "arxiv": {"storagePath": "/"},
    }
)

mcp_url = sandbox.get_mcp_url()

The exact set of built-in server names and server-specific properties should follow the upstream E2B SDK where practical. Unknown server-specific properties should remain forward-compatible.

Proposed Solution

Add E2B-compatible MCP configuration and data-plane behavior to CubeSandbox:

1. Support the mcp field in POST /sandboxes as a map keyed by MCP server name.
2. Validate the supported configuration shapes and return a clear parameter error for invalid values.
3. Start or configure an MCP Gateway inside the Sandbox after creation.
4. Add SDK methods with E2B-compatible semantics:
   • Python: sandbox.get_mcp_url()
   • JavaScript/TypeScript: sandbox.getMcpUrl()
   • Go: an equivalent GetMCPURL method if the Go SDK exposes the feature.
5. Route the MCP URL through CubeProxy to the corresponding Sandbox while applying the existing Sandbox authentication, domain, and network policies.
6. Return the non-sensitive MCP configuration in Sandbox information/connect responses so SDK clients can restore their state. Secrets must never be returned in plaintext.
7. Preserve MCP availability across pause/resume, clone, and snapshot restore, or return an explicit reconnect state when a new MCP session is required.
8. Add Python, Go, and Node SDK tests for request serialization, URL generation, and error handling, plus at least one CubeSandbox E2E MCP test.

An initial compatible payload could look like this:

{
  "templateID": "tpl-...",
  "mcp": {
    "duckduckgo": {},
    "arxiv": {
      "storagePath": "/"
    }
  }
}

For custom servers, the payload may eventually support fields such as:

{
  "mcp": {
    "server-name": {
      "installCmd": "npm install",
      "runCmd": "npm run start",
      "envs": {
        "EXAMPLE_TOKEN": "..."
      }
    }
  }
}

The installation, startup, and credential-delivery mechanism needs an explicit security design. Credentials should preferably be delivered through CubeEgress or another platform-managed mechanism instead of being persisted as long-lived secrets in the Sandbox configuration or API responses.

Alternatives Considered

• Install MCP servers manually in the Sandbox image: This works for a single image, but callers cannot reuse the E2B mcp creation option or get_mcp_url() API, and the platform cannot manage the MCP lifecycle consistently.
• Expose an MCP server through a normal Sandbox port: Callers must define their own port, routing, and authentication conventions, which prevents direct E2B SDK compatibility.
• Implement MCP configuration only in the WebUI: This would support the Digital Assistant use case but would not solve API and SDK compatibility.

Additional Context

• The current OpenAPI schema already contains an mcp field, but it is defined as an unstructured value and does not describe functional MCP behavior.
• The CubeAPI model also retains an optional mcp value, but the end-to-end gateway and SDK behavior is not implemented.
• MCP server outbound traffic must remain subject to CubeSandbox allowOut, network rules, and CubeEgress policies.
• This should initially be released as a Preview feature with documented authentication, resource, and audit limitations.

E2B References

• E2B JavaScript SDK McpServer types
• E2B JavaScript SDK Sandbox API
• E2B MCP Gateway example