MCP servers overview
This page explains what MCP is, what a hosted MCP server on the Crusoe AI Platform gives you, and how it compares to the big clouds. By the end you will know when to reach for one and where to go next.
What is MCP?
MCP (Model Context Protocol) is an open standard that lets an AI model call your code. A piece of callable code is a tool — a function with a name, a description, and typed inputs, like get_forecast(city). An MCP server is a small web service that lists its tools and runs them when asked. An MCP client is anything that speaks the protocol on the other side: an AI agent, a chat app, or a coding assistant.
The conversation between them is plain HTTP. The client sends a JSON message like "what tools do you have?" (tools/list) or "run get_forecast with city=Reykjavik" (tools/call), and the server answers with JSON. That is the whole idea: a standard way for any AI to discover and call any tool, without custom glue code for every pairing.
What the platform gives you
On the Crusoe AI Platform, an MCP server is a fully managed service. You do not write server code, JSON schemas, or authentication. You write one Python function, decorate it with @crusoe.tool, and publish it. The platform:
- Builds it into an immutable version. Every publish takes a snapshot of the server's whole tool set as a numbered version, tied to one exact container image. Immutable means it can never be edited afterward: version 3 today is byte-for-byte version 3 forever.
- Keeps one instance warm. An MCP server runs at least one instance at all times, and scales out to ten under load. That floor of one is a reachability requirement rather than a tuning preference: callers are routed straight to the running instances, and nothing wakes a stopped server on the first request — with no instance running there is nothing to route a tool call to, so it is refused rather than queued. An idle MCP server therefore is not free — prefer several tools on one server over one server per tool.
- Locks the door by default. Every server gets its own bearer token — a secret string a caller presents to be let in, the way a ticket works. The format is
cai_mcp_followed by 64 hexadecimal characters. Requests without it are refused. The server also fails closed: if its own copy of the token is somehow missing, it refuses everyone rather than serving openly. - Handles credentials safely. Tools declare the names of the secrets they need — those names are called credential keys. The values live in your project's secret store and are fetched at the moment of the call, using a short-lived token. They are never baked into the image or stored on the server.
- Lets you roll back. Something broke in version 4? Point the server back at version 3 with one call. Nothing is rebuilt; the platform reuses the image it recorded for version 3.
The 30-second mental model
You publish tools; the platform turns them into versions; one version serves at the endpoint; clients call it with the server's bearer token; secrets arrive only at call time.
The lifecycle at a glance
A server's state field moves through pending (created, no tools built yet) → building → deploying → ready, or lands on failed. Beside it, every server carries a ready boolean — the same field, meaning the same thing, on every resource the platform hands you: can I use this right now. It is true exactly when state is ready, so branch on ready and show a human the word. Publishing a tool, or deleting one, starts a new build and creates the next version.
Builds run in the background. Your publish request returns straight away with 202 Accepted — the HTTP status meaning "I've taken this on, but it isn't done yet" — and a build_id. You then re-read the server every few seconds until its ready is true.
Where you manage it
- Console:
Compute → MCP serversin the web console — create servers, publish and edit tools, browse versions, roll back. - API: everything under
POST /v1/projects/{projectID}/mcpservers— see the API reference. - CLI:
platformctl mcp—create,list,get,delete,tools set|list|delete,versions,rollback,yank,unyank.
Reading a project's MCP servers requires the project member role. Creating servers, publishing or deleting tools, rolling back, and retiring versions all require the project admin role. Every one of those actions is recorded in the project's audit log, under names like mcpserver.create, mcpserver.tool.publish, and mcpserver.version.rollback.
How it compares
The table below compares Crusoe MCP server management with traditional cloud platform workflows:
| Cloud | Closest thing | What you would still do yourself |
|---|---|---|
| Amazon | Self-host an MCP server on serverless functions or container services; managed agent tooling for tool calling | Write the server, wire auth, build your own versioning and rollback |
| Self-host on cloud containers; managed agent tooling | Same — hosting exists, the MCP server remains your code to maintain | |
| Microsoft | Self-host on serverless functions or container apps; managed AI tool integrations | Same — hosting exists, a managed MCP-server product does not |
Crusoe AI Platform simplifies MCP server deployment by building hosting, containerization, immutable versioning, per-server bearer authentication, and automated secret retrieval directly into the platform.
In this section
- Deploy an MCP server from source — the supported path from folder to endpoint.
- Publish your first tools — create a server and publish a complete weather tool.
- Versions and rollback — how immutable versions, rollback, and yank work.
- Connect agents and clients — point your agents and external MCP clients at the endpoint.
- Tutorial: weather tools over MCP — the full walkthrough.
- Troubleshooting — real error messages and fixes.