Documentation
Build, deploy, and operate MCP servers from one workspace.
MCPCloud gives teams one place to design servers, manage deployments, control runtime access, and package reusable assets. Start with this overview when you need the product model first, then move to API Reference when you are ready to automate it.
How the product fits together
MCPCloud is organized around a small set of durable objects. Most teams move from project setup to server composition to deployment operations, then automate pieces of that lifecycle once those concepts are stable.
Create a project
Projects hold the teams, servers, skills, and settings that make up a single MCPCloud workspace.
Shape one or more servers
A server collects runtime configuration, auth behavior, tools, and distribution settings before you deploy it.
Deploy and verify access
Deployments capture runtime versions, URLs, access modes, and protected runtime requirements.
Automate with the API surface
Once the app model is clear, the API docs cover API keys, runtime token exchange, and machine-facing auth flows.
Use this overview before API Reference
The public API surface is intentionally narrow today. It covers authentication, runtime token exchange, API-key lifecycle, and the adjacent OAuth runtime-grant flow. This overview explains the product concepts those endpoints depend on.
Machine flows depend on deployment identifiers and organization context that are created and managed in the workspace.
The current contract is built around personal API keys and short-lived runtime tokens rather than general service accounts.
Core resources
Projects
The organizational root for environments, teams, servers, and lifecycle history.
Servers
A server is the deployable MCP unit where tools, auth, runtime bindings, and registry metadata converge.
Deployments
Deployments are immutable runtime releases with distinct ids, URLs, access modes, and auth boundaries.
Skills and marketplace assets
Package reusable behavior, curate artifacts, and ship distribution-ready building blocks from the same workspace.
Runtime access model
Every deployment has an explicit access mode. That distinction matters because the runtime auth flow changes depending on whether the endpoint is public or protected.
Public
Call the deployed runtime directly when the server is intentionally open.
privateOrg
Use MCPCloud-issued short-lived runtime tokens 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.
Next steps
Once the project, server, deployment, and access model are clear, continue to API Reference for the exact wire contract and machine-facing auth flows.