Consider simplifying the process to expose Docker MCP getaway to Docker Sandbox

[pawelpabich]

Hey,

Currently, there doesn't seem to be an easy way to expose Docker MCP gateway to Docker Sandbox.
It feels that steps 2-5 of our current process could be automated by Docker Desktop, in the same way it adds MCP_DOCKER entry to the user's Claude settings file. What is more, if we add additional config to the sandbox's startup process, step 6 could also be eliminated.

Our current process

1. Create your own Docker MCP profile and test it locally as per Docker MCP documentation.
2. Create a secret token for Docker MCP gateway, e.g. dmcp{secret_value}
3. Add the secret to Docker sandbox via sbx secret set -g dockermcp
4. Set MCP_GATEWAY_AUTH_TOKEN env variable to the value of the secret token so the Docker MCP gateway can use it for authentication, e.g. export MCP_GATEWAY_AUTH_TOKEN=dmcp{secret_value} or $env:MCP_GATEWAY_AUTH_TOKEN=dmcp{secret_value}
5. Run Docker MCP gateway: docker mcp gateway run --profile your_profile_name --transport streaming --port PORT
6. Create a sandbox with the following kit:

spec.yaml

schemaVersion: "1"
kind: mixin
name: docker-mcp
network:
  allowedDomains:
    - "host.docker.internal:PORT"
    - "localhost:PORT"
  serviceDomains:
    "localhost:PORT": dockermcp
  serviceAuth:
    dockermcp:
      headerName: Authorization
      valueFormat: "Bearer %s"
credentials:
  sources:
    dockermcp:
      env:
        - DOCKER_MCP_API_KEY
environment:
  proxyManaged:
    - DOCKER_MCP_API_KEY

files/workspace

{
  "mcpServers": {
    "MCP_DOCKER": {
      "type": "http",
      "url": "http://host.docker.internal:PORT/mcp",
      "headers": {
        "Authorization": "Bearer ${DOCKER_MCP_API_KEY}"
      }
    }
  }
}

[evidai]

Sharing how we ended up designing this for LemonCake (https://lemoncake.xyz) — production x402 gateway, live since early 2026.

Gateway shape: /g/<id> — single endpoint, x402-native (402 + accepts[] advertising both buyUrl for humans and mintUrl for agents)

Credential model (this is the part that maps to "non-human identity + short-lived scoped credentials"):

• Buyer Key (bk_…) — long-lived, hashed at rest, scoped to one seller. The agent's "permission to spend up to caps". Revocable via the dashboard (a single column flip on lc_buyer_keys).
• Pay Token (pt_…, JWT) — short-lived (minutes-to-hours), single-use, embedded budget + expiry. The actual "wallet for one task".

Why two layers: the agent never holds a credential that can directly move money. It holds a Buyer Key (capped) and presents it to mint Pay Tokens. The gateway is the enforcement point for caps (per-mint / daily / monthly), idempotency (charge_ref unique), and revocation.

Hosted production observability (for the deployment / observability angles in this thread):

• lc_agent_charges keeps every charge with charge_ref, used for both idempotency and cap-window aggregation
• Stripe off-session adapter is env-gated (LC_PAYMENT_ADAPTER=stripe) so test → live is a flag flip, not a code change
• Self-healing connect/status routes recover from stale acct ids

Production: $1 off-session card charge through the full loop verified 2026-06-02.
30-second demo (no signup): https://lemoncake.xyz/demo

(Disclosure: I'm working on LemonCake — sharing as a reference implementation, not pitching.)