Skip to main content

MCP Tunnels

What is it?

Securely connect Claude to MCP servers running in your private network without opening inbound ports or exposing services to the internet. MCP Tunnels is currently in private beta and relies on Cloudflare’s Tunnel service.

How it works

MCP Tunnels create a connection between Claude and your internal MCP servers that is encrypted in transit with multiple layers of security.

When Claude needs to reach an MCP server in your private network, the request travels through a secure tunnel. You deploy two components on your side:

  • cloudflared (Cloudflare's tunnel agent)

  • MCP Gateway (provided by Anthropic)

Cloudflared initiates an outbound-only connection to Cloudflare's edge. No inbound ports need to be opened in your firewall. The MCP Gateway terminates an inner TLS layer, validates upstream IPs to prevent SSRF, and routes each request to the correct MCP server based on subdomain.

The connection is secured with three independent layers: outer mTLS between Anthropic and Cloudflare (with IP validation), inner TLS that encrypts payloads end-to-end from Anthropic's backend to your gateway (designed so Cloudflare doesn't have access to MCP payloads), and OAuth authentication at the application layer on each MCP server.

What you deploy

cloudflared

Cloudflare's tunnel agent. Initiates outbound-only connections — no inbound ports needed.

MCP Gateway

Anthropic-provided component that terminates inner TLS, validates IPs, and routes requests to your MCP servers.

Key security properties

  • No inbound ports required. cloudflared initiates outbound connections only — your firewall stays closed.

  • End-to-end encryption. Traffic is encrypted in transit from Anthropic's backend to your gateway. MCP payloads cannot be read by Cloudflare.

  • Defense in depth. Multiple authentication layers: mTLS, inner TLS, and OAuth at the application layer.

  • SSRF protection. The gateway validates upstream IPs to help prevent request forgery attacks.

This guide provides reference deployments via Helm (for Kubernetes) and Docker Compose. You are responsible for adapting them to meet your organization's security requirements.

Shared responsibility

Keeping this system secure is a shared responsibility between Anthropic and your organization.

Anthropic is responsible for:

  • Ensuring only Anthropic can access tunnels

  • Validating your CA certificate before connecting to your gateway

  • Ensuring Claude only sends requests to tunnels owned by your organization

You are responsible for:

  • Following the guidance in this document and any subsequent guidance

  • Securing the tunnel token and TLS private keys

  • Configuring your MCP servers to use OAuth authentication as described in the MCP spec

  • Restricting access to your gateway hosts and MCP servers to appropriate personnel

  • Notifying Anthropic if you suspect the system has been compromised (see Responding to a suspected breach)

⚠️ Credential risk. If an attacker obtains your tunnel token and either one of your TLS private keys, they could impersonate your gateway and read MCP request payloads, including OAuth tokens. Protect these credentials according to your organization's security requirements—including file permissions, encryption at rest, and secrets management.


Prerequisites

  • A deployment target — a Kubernetes cluster (for Helm) or a VM with Docker and Docker Compose.

  • An Anthropic API token for the Tunnels API — generate one from claude.ai → Organization Settings → Connectors → Tunnels API. Setup uses this token to provision the tunnel and register your CA certificate. The gateway does not need it at runtime. Revoke it once you finish setup.

  • Network access — outbound connectivity per the table below.

  • MCP servers — one or more MCP servers running in your private network that the gateway can reach.

Network requirements

Component

Destination

Purpose

Setup (one-time)

api.anthropic.com:443

(port 443)

Tunnel provisioning

cloudflared

Cloudflare edge, port 7844 TCP/UDP (198.41.192.0/19, 2606:4700:a0::/44)

Tunnel connection

MCP Gateway

Your MCP servers

Upstream traffic

See Cloudflare's tunnel firewall documentation for the authoritative IP list. Helm users can enforce this egress restriction by enabling the chart's networkPolicy value.


Choose your deployment method

MCP Tunnels can be deployed via Helm (Kubernetes) or Docker Compose. Choose the method that fits your infrastructure.

⎈ Helm / Kubernetes

Recommended for most customers. Automates tunnel provisioning and certificate renewal. Stores credentials as Secrets.

🐳 Docker Compose

For single-host or VM deployments.


Helm / Kubernetes deployment

1. Fetch the chart values

Download the default values file. It includes comments explaining each field.

Shell

helm show values \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 0.1.0 > values.yaml

2. Configure your routes

Edit values.yaml and add at least one route under gateway.config.routes. Each route maps a subdomain prefix to an upstream MCP server URL.

3. Review the rendered manifests

Render the chart with a placeholder token to inspect the Kubernetes resources before installing. The chart requires api.token to render, but helm template does not call the API.

Shell

helm template mcp-tunnel \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 0.1.0 \
-n mcp-tunnel \
-f values.yaml \
--set api.token=placeholder > rendered.yaml

Review rendered.yaml according to your organization's practices for vetting third-party manifests.

4. Install the chart

Store your API token in an environment variable, then install. A dedicated namespace is recommended for isolation.

Shell

# Paste your API token (input is hidden)
read -rs API_TOKEN && export API_TOKEN

helm install mcp-tunnel \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 0.1.0 \
--namespace mcp-tunnel --create-namespace \
-f values.yaml \
--set api.token="$API_TOKEN"

⚠️ Important: Revoke the API token once install completes. Passing the token via --set keeps it out of your values file, but Helm still records it in the release history (sh.helm.release.v1.* Secrets). Kubernetes Secrets are not encrypted at rest by default, so the token remains recoverable from the cluster until you revoke it.

5. Retrieve your tunnel domain

The setup Job writes the tunnel domain to a Secret. You'll need this to configure MCP servers in Claude.

Shell

kubectl get secret mcp-tunnel -n mcp-tunnel \
-o jsonpath='{.data.tunnel-domain}' | base64 -d

Once the tunnel is up and running, connect to Claude.

Optional: Enable NetworkPolicy

Set networkPolicy.enabled: true in your values file to restrict the tunnel pod's egress at the network level. Configure networkPolicy.mcpServers with pod label selectors or CIDR ranges for your upstream MCP servers. The policy already includes egress rules for cloudflared to reach Cloudflare's edge. Your cluster's CNI must support NetworkPolicy—see the values file for an example.

Optional: Gateway configuration

Fields under gateway.config.* are passed through to the gateway's config file. See Appendix: Gateway configuration for the full list. Common adjustments include upstream.allowed_ips, log_level, and upstream.tls for https:// routes. To mount additional files the config references (such as a CA bundle for upstream.tls.ca_file), use gateway.extraVolumes and gateway.extraVolumeMounts.

Upgrades

Always specify --version on helm upgrade. Without it, Helm pulls the latest chart version from the registry, which may not be what you reviewed.

For config changes (routes, replicas, NetworkPolicy, etc.), no API token is needed. The setup Job is skipped on upgrades unless you pass api.token:

Shell

helm upgrade mcp-tunnel \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 0.1.0 \
-n mcp-tunnel \
-f values.yaml

For tunnel token rotation, increment tunnel.tokenVersion in your values file, generate a fresh API token, and upgrade:

Shell

# Paste your API token (input is hidden)
read -rs API_TOKEN && export API_TOKEN

helm upgrade mcp-tunnel \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 0.1.0 \
-n mcp-tunnel \
-f values.yaml \
--set api.token="$API_TOKEN"

Revoke the API token once the upgrade completes.

Maintain a complete values file rather than relying on --reuse-values. Helm deep-merges map fields, so deleting a route with --reuse-values silently fails.

Using helm template with kubectl or kustomize

If you prefer to render manifests and apply them yourself (via kubectl apply or kustomize overlays), use external mode (setup.enabled: false). Provision the tunnel separately (see Appendix: Tunnels API) and supply the credentials as pre-created Secrets referenced by external.tunnelTokenSecretName and external.serverCertSecretName. If you issue your own certificates rather than using the setup binary, see Appendix: Certificate requirements.

Docker compose deployment

1. Prepare the deployment directory

Shell

mkdir -p mcp-gateway/{config,tunnel-data}
cd mcp-gateway
sudo chown 65532:65532 tunnel-data

The chown lets the container (which runs as UID 65532) write to the bind-mounted directory.

2. Create docker-compose.yaml

YAML

services:
# One-time provisioning. Run with: docker compose run --rm setup
setup:
image: us-docker.pkg.dev/anthropic-public-registry/images/mcp-gateway@sha256:62ddf0897778c80997ca789189a8a0bd63df241659d661ff9d5b0e06b5ee1dcd
entrypoint: ["/setup"]
command:
- init
- --api-url=https://api.anthropic.com
- --output=dir:/data
- --token-version=1
environment:
- API_TOKEN
volumes:
- ./tunnel-data:/data
user: "65532:65532"
read_only: true
security_opt:
- no-new-privileges:true
cap_drop:
- ALL
profiles: ["setup"]

cloudflared:
# Verify digest at https://hub.docker.com/r/cloudflare/cloudflared/tags
image: cloudflare/cloudflared@sha256:6b599ca3e974349ead3286d178da61d291961182ec3fe9c505e1dd02c8ac31b0
command: tunnel --no-autoupdate --config /etc/cloudflared/config.yaml run
environment:
- TUNNEL_TOKEN
volumes:
- ./config/cloudflared-config.yaml:/etc/cloudflared/config.yaml:ro
restart: unless-stopped
user: "65532:65532"
read_only: true
security_opt:
- no-new-privileges:true
cap_drop:
- ALL
stop_grace_period: 30s
logging:
options:
max-size: "10m"
max-file: "3"

mcp-gateway:
image: us-docker.pkg.dev/anthropic-public-registry/images/mcp-gateway@sha256:62ddf0897778c80997ca789189a8a0bd63df241659d661ff9d5b0e06b5ee1dcd
volumes:
- ./config/mcp-gateway.yaml:/etc/mcp-gateway/config.yaml:ro
- ./tunnel-data:/data:ro
restart: unless-stopped
user: "65532:65532"
read_only: true
security_opt:
- no-new-privileges:true
cap_drop:
- ALL
# Should match shutdown_timeout in mcp-gateway config
stop_grace_period: 30s
logging:
options:
max-size: "10m"
max-file: "3"

Security measures: non-root execution (UID 65532), read-only filesystem, no privilege escalation, all Linux capabilities dropped, image pinning by SHA256 digest.

3. Provision the tunnel

Shell

# Paste your API token (input is hidden)
read -rs API_TOKEN && export API_TOKEN

docker compose run --rm setup

The setup command creates a tunnel via the Tunnels API, generates a CA and server certificate, registers the CA with Anthropic, and writes all outputs to ./tunnel-data/.

Retrieve your tunnel domain for the next step:

Shell

sudo cat tunnel-data/tunnel-domain

⚠️ Important: Revoke the API token before proceeding.

4. Configure the gateway

Create config/mcp-gateway.yaml:

YAML

listen_addr: ":8080"
log_level: info
shutdown_timeout: 30s

# Your tunnel domain from Step 3
tunnel_domain: abcd1234.tunnel.anthropic.com

tls:
cert_file: /data/tls.crt
key_file: /data/tls.key

routes:
# Replace with your actual MCP servers.
# With tunnel_domain set, keys are subdomain prefixes.
docs: http://docs-mcp.internal:8080
search: http://search-mcp.internal:8080

upstream:
allowed_ips:
- 10.0.0.0/8

See Appendix: Gateway configuration for all available fields.

Create config/cloudflared-config.yaml:

YAML

ingress:
- service: http://mcp-gateway:8080

5. Deploy

Shell

export TUNNEL_TOKEN=$(sudo cat tunnel-data/tunnel-token)
docker compose up -d
docker compose logs -f

Directory structure:

mcp-gateway/
├── docker-compose.yaml
├── config/
│ ├── cloudflared-config.yaml
│ └── mcp-gateway.yaml
└── tunnel-data/
├── tunnel-id
├── tunnel-domain
├── tunnel-token
├── token-version
├── ca.crt
├── ca.key
├── tls.crt
└── tls.key

Consider moving the CA private key and tunnel token to secure storage.

For multi-VM deployments: copy the mcp-gateway/ directory to each host. The same tunnel token and certificates work across all replicas.

Once the tunnel is up and running, connect to Claude.

Certificate renewal (Compose)

The server certificate has a 90-day validity. Renew before expiry:

Shell

docker compose run --rm setup renew-cert --output=dir:/data

The gateway polls the certificate file every 30 seconds and reloads it automatically when it changes. See Appendix: Setup CLI reference for flags that make this command safe to run on a schedule.

Tunnel token rotation (Compose)

Edit docker-compose.yaml to increment --token-version, then re-run setup with a fresh API token:

# Paste your API token (input is hidden)
read -rs API_TOKEN && export API_TOKEN

docker compose run --rm setup

export TUNNEL_TOKEN=$(sudo cat tunnel-data/tunnel-token)
docker compose up -d cloudflared

Revoke the API token once rotation completes.


Connect to Claude

Once the tunnel is running, register your MCP servers in Claude so they're available to users.

1. Add MCP servers

An organization admin navigates to Organization Settings → Connectors → Add → Custom → Web in claude.ai.

Enter each MCP server using its tunnel hostname. For example, docs.abcd1234.tunnel.anthropic.com. The subdomain prefix matches the route key from your gateway config.

2. Users connect

Individual users navigate to Settings → Connectors and click Connect for each MCP server they want to use.

Adding more servers later? Add a new route to your config, apply the change (helm upgrade, or docker compose restart mcp-gateway), and register the new hostname in Claude. No certificate or cloudflared changes needed. The wildcard certificate covers all subdomains.

Security best practices

  1. Require OAuth on your MCP servers. The tunnel and TLS layers protect the transport, but if those are ever compromised, OAuth at the application layer still prevents unauthorized tool invocation. Configure each MCP server to require OAuth authentication as described in the MCP spec.

  2. Enable SSO for your claude.ai organization. Tunnel tokens are generated from the claude.ai Console. With SSO enforced, your identity provider's session controls govern admin sessions.

  3. Restrict allowed_ips. Use the smallest CIDR ranges that cover your MCP servers.

  4. Monitor logs. Set up alerting on warnings, errors, and unusual patterns.

  5. Rotate credentials. Rotate certificates on a regular schedule, or immediately if compromise is suspected.

  6. Keep images updated. Apply gateway updates promptly. Pin images by SHA256 digest.

  7. Limit network access. The gateway and cloudflared should have only the required network access.

  8. Limit MCP server scope. MCP servers should only expose necessary functionality.

  9. Protect credentials at rest. Apply appropriate file permissions, encryption at rest, and secrets management to the tunnel-data/ directory (Compose) or the credentials Secret (Helm).

Responding to a suspected breach

If you suspect your tunnel credentials, TLS keys, or some other aspect of the system has been compromised:

  1. Stop the deployment immediately (helm uninstall or docker compose down --timeout 0)

  2. Remove MCP servers from Claude (Organization Settings → Connectors)

  3. Archive the tunnel via the API (see Teardown, step 3)

  4. Contact Anthropic so they can investigate

  5. Rotate credentials — re-provision a fresh tunnel, rotate OAuth tokens on your MCP servers

  6. Review logs before restoring service


Troubleshooting

IP validation failures

"IP validation failed" in gateway logs means the upstream resolved to an IP outside allowed_ips. Check the resolved IP:

Shell

dig +short docs-mcp.internal

If the IP is legitimate, update allowed_ips in your gateway config to include the correct CIDR range.

Tunnel not connecting

Check cloudflared logs for errors. Common causes:

  • Invalid tunnel token

  • Firewall blocking outbound port 7844 TCP/UDP to Cloudflare edge

Verify outbound connectivity to Cloudflare's IP ranges: 198.41.192.0/19 and 2606:4700:a0::/44.

UDP buffer size warnings

cloudflared may log failed to sufficiently increase receive buffer size. This is a QUIC transport tuning issue — see the quic-go UDP buffer documentation to adjust.

Certificate errors

If TLS handshake fails, check that:

  • The server certificate hasn't expired (90-day validity)

  • The certificate's SAN matches *.<tunnel-domain>

  • The CA certificate is registered with Anthropic via the API

  • For Compose, certificate files are readable by UID 65532

Routing OAuth through the tunnel (auth server behind IP allowlist)

Problem: Your auth server sits behind a source IP allowlist. Claude's backend needs to reach it for OAuth discovery, client registration, and token exchange, but you'd rather not whitelist Anthropic's egress IP ranges.

Solution: split-endpoint configuration. Route the backend-to-backend OAuth calls through the tunnel. Keep the browser-facing /authorize endpoint on your existing allowlisted hostname. This works because Claude reads the authorization_endpoint from your discovery metadata and redirects the user's browser there. It doesn't need to reach that URL itself.

Step 1: Add a gateway route for your auth server

YAML — mcp-gateway.yaml

routes:
mcp: http://your-mcp-server:8080
auth: http://your-auth-server:8080

Step 2: Serve split-endpoint discovery metadata

Your auth server's /.well-known/oauth-authorization-server must return:

JSON

{
"issuer": "https://auth.<tunnel-id>.tunnel.anthropic.com",
"authorization_endpoint": "https://<your-allowlisted-host>/authorize",
"token_endpoint": "https://auth.<tunnel-id>.tunnel.anthropic.com/token",
"registration_endpoint": "https://auth.<tunnel-id>.tunnel.anthropic.com/register",
"code_challenge_methods_supported": ["S256"]
}

Only authorization_endpoint points at your existing hostname. Everything else uses the tunnel URL.

Step 3: Point your MCP server at the tunnel issuer

Your MCP server's /.well-known/oauth-protected-resource:

JSON

{
"resource": "https://mcp.<tunnel-id>.tunnel.anthropic.com",
"authorization_servers": [
"https://auth.<tunnel-id>.tunnel.anthropic.com"
]
}


Teardown

How to decommission a tunnel when it's no longer needed.

1. Get the Tunnel ID

Helm

TUNNEL_ID=$(kubectl get secret mcp-tunnel -n mcp-tunnel \
-o jsonpath='{.data.tunnel-id}' | base64 -d)

Compose

TUNNEL_ID=$(sudo cat tunnel-data/tunnel-id)

2. Stop the deployment

Helm: helm uninstall mcp-tunnel -n mcp-tunnel (note: the credentials Secret was created by the setup Job, not Helm, so it survives uninstall)
​Compose: docker compose down

3. Archive the tunnel

Generate a fresh API token first and revoke it when finished.

Shell

read -rs API_TOKEN && export API_TOKEN

curl -X POST "https://api.anthropic.com/v1/tunnels/${TUNNEL_ID}/archive" \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24"

4. Remove stored credentials

Helm: kubectl delete secret mcp-tunnel -n mcp-tunnel
​Compose: sudo rm -rf tunnel-data

Getting help

Contact your Anthropic account team for assistance.


Appendix: Gateway configuration

The gateway reads its configuration from a YAML file. In Docker Compose, you write this file directly as config/mcp-gateway.yaml. In Helm, set these fields under gateway.config.* in your values file—the chart manages listen_addr, tls, and tunnel_domain for you.

Field

Description

Default

listen_addr

Address and port to listen on

Required

log_level

Logging verbosity: debug, info, warn, error

info

shutdown_timeout

Wait time for in-flight requests during graceful shutdown

30s

tunnel_domain

Base domain for prefix route resolution

None

tls.cert_file

Path to TLS certificate

Required

tls.key_file

Path to TLS private key

Required

routes

Hostname (or prefix) to upstream URL mapping

Required

upstream.allowed_ips

CIDR ranges the gateway may connect to

RFC 1918 private ranges

upstream.disable_ip_validation

Disable IP validation entirely

false

upstream.tls.ca_file

CA bundle for validating upstream TLS

None

upstream.tls.include_system_cas

Trust the system CA bundle for upstream TLS

false

For https:// routes, set at least one of upstream.tls.ca_file or upstream.tls.include_system_cas.


Appendix: Tunnels API

For custom provisioning workflows, you can call the Tunnels API directly. All requests require these headers:

Shell

-H "Authorization: Bearer $API_TOKEN"
-H "anthropic-version: 2023-06-01"
-H "anthropic-beta: mcp-tunnels-2026-02-24"

Create a tunnel:

curl -X POST https://api.anthropic.com/v1/tunnels \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24" \
-H "Content-Type: application/json" \
-d '{}'

List tunnels:

curl https://api.anthropic.com/v1/tunnels \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24"

Register a CA certificate:

curl -X POST "https://api.anthropic.com/v1/tunnels/${TUNNEL_ID}/certificates" \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24" \
-H "Content-Type: application/json" \
-d "{\"ca_certificate_pem\": $(jq -Rs . < ca.crt)}"

See Appendix: Certificate requirements for what the CA and server certificates must contain.

List CA certificates:

curl "https://api.anthropic.com/v1/tunnels/${TUNNEL_ID}/certificates" \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24"

Revoke a CA certificate:

curl -X POST "https://api.anthropic.com/v1/tunnels/${TUNNEL_ID}/certificates/${CERT_ID}/revoke" \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24"

Reveal the tunnel token:

curl -X POST "https://api.anthropic.com/v1/tunnels/${TUNNEL_ID}/reveal_token" \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24"

Rotate the tunnel token:

curl -X POST "https://api.anthropic.com/v1/tunnels/${TUNNEL_ID}/rotate_token" \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24"

Archive a tunnel:

curl -X POST "https://api.anthropic.com/v1/tunnels/${TUNNEL_ID}/archive" \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24"


Appendix: Certificate requirements

If you use the setup binary (setup init / setup renew-cert), it generates compliant certificates automatically and you can skip this section. These requirements apply if you issue certificates through your own PKI.

CA certificate — upload via POST /v1/tunnels/{id}/certificates. A tunnel holds at most two active CA certificates at a time, allowing rotation without downtime.

  • PEM-encoded, single certificate, at most 8 KB

  • BasicConstraints extension with CA:TRUE, marked critical

  • SubjectKeyIdentifier extension present

  • KeyUsage includes keyCertSign

  • Within validity period

  • RSA 2048-bit or larger, or ECDSA P-256 or larger; SHA-256 or stronger signature

Server certificate — presented by the gateway during the inner TLS handshake. Not uploaded to Anthropic.

  • Signed directly by a CA registered on the tunnel

  • AuthorityKeyIdentifier extension present, matching the CA's SubjectKeyIdentifier

  • SAN includes a DNS name matching <route>.<tunnel-domain> (a wildcard *.<tunnel-domain> covers all routes)

  • If an ExtendedKeyUsage extension is present, it includes serverAuth

  • Within validity period

  • RSA 2048-bit or larger, or ECDSA P-256 or larger; SHA-256 or stronger signature

Reference: the setup binary generates an ECDSA P-256 CA (5-year validity) and an RSA 4096-bit server certificate with a wildcard SAN (90-day validity).


Appendix: Setup CLI reference

The setup binary runs inside the gateway container via docker compose run --rm setup <subcommand> (Compose) or as a Helm hook and CronJob (Kubernetes).

setup init — creates a tunnel via the Tunnels API, generates a CA and server certificate, registers the CA, and writes all outputs.

Flag

Description

Default

--api-url

Anthropic API base URL. Also read from API_URL.

required

--api-token

API token with tunnel scope. Also read from API_TOKEN.

required

--output

Output destination: dir:/path or k8s-secret:NAME

k8s-secret:mcp-gateway

--cert-duration

Server certificate validity period

2160h (90 days)

--token-version

Change-detection string; a new value triggers tunnel token rotation

none

setup renew-cert — issues a new server certificate signed by the stored CA. No API call required.

Flag

Description

Default

--output

Output destination: dir:/path or k8s-secret:NAME

k8s-secret:mcp-gateway

--cert-duration

New certificate validity period

2160h (90 days)

--renew-before

Skip if the existing certificate has more than this long until expiry

0 (always renew)

Setting --renew-before=720h makes the command a no-op when more than 30 days remain, suitable for running on a schedule.

Did this answer your question?