Skip to main content

​
Runtime access

Every deployment has an explicit access mode. This distinction matters because the way a client reaches the runtime changes depending on whether the endpoint is open or protected.

​
Access modes

public

The server is intentionally open. Clients call the deployed runtime URL directly.

privateOrg

Protected. Clients must present a short-lived MCPCloud runtime token issued after an authenticated exchange tied to the organization and deployment.

unlisted

The runtime URL is not the security boundary. Treat it like a protected deployment and use runtime auth.
An unlisted URL being hard to guess is not a security control. Always use runtime auth for unlisted and privateOrg deployments.

​
Control-plane auth vs runtime auth

These are two different credential systems — keep them straight:

​
Runtime token exchange

For protected deployments, a client exchanges credentials for a short-lived runtime token before calling the server. The exchange is tied to a specific deployment id and organization — both of which originate in the workspace.
The token is then presented to the runtime endpoint (/api/v1/runtime/auth/token underpins this flow). Because tokens are short-lived, a leaked token has a small blast radius compared to a long-lived secret.
Deployment ids and organization context are created and managed in the app. The public API surface is intentionally narrow today: authentication, runtime token exchange, API-key lifecycle, and the adjacent OAuth runtime-grant flow.

​
OAuth connections

Servers can bind OAuth 2.0 connections for upstream providers. Manage them with:
See the API reference for the exact wire contract, and transports & auth for how this fits with transports.