Skip to main content

MCP servers overview

This page explains what MCP is, what a hosted MCP server on the Crusoe Agent 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 Agent Platform, an MCP server is a hosted, managed primitive. 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 snapshots the server's whole tool set into a numbered version, pinned to an exact container image. Version 3 today is byte-for-byte version 3 forever.
  • Serves it scale-to-zero. The endpoint runs zero machines while idle and wakes on the next request, so an unused server costs nothing to keep around.
  • Locks the door by default. Every server gets its own bearer token (format cai_mcp_ followed by 64 hex characters). Requests without it are refused — the server fails closed, meaning if the token is somehow missing it refuses everyone rather than serving openly.
  • Handles credentials safely. Tools declare the names of secrets they need (credential keys). Values live in your project's secret store and are fetched at call time with 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. No rebuild — the platform reuses version 3's recorded image.

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 status field moves through: pending (created, no tools built yet) → building → deploying → ready, or failed. Publishing a tool, or deleting one, starts a new build and mints the next version. Builds run in the background — you get a 202 Accepted with a build_id and poll the server's status.

Where you manage it​

  • Console: Compute → MCP servers in 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: not yet. platformctl has no MCP commands in this alpha; use the console or the API.

Reading a project's MCP servers requires the project member role. Creating servers, publishing or deleting tools, rolling back, and yanking versions require the project admin role. Every one of those actions is recorded in the project's audit log (actions like mcpserver.create, mcpserver.tool.publish, mcpserver.version.rollback).

How it compares​

Honest answer: as of this writing, none of the big three clouds sells a managed "publish a Python function, get a versioned MCP endpoint" primitive. What they have instead:

CloudClosest thingWhat you would still do yourself
AWSSelf-host an MCP server on Lambda or ECS; Bedrock Agents "action groups" for tool callingWrite the server, wire auth, build your own versioning and rollback
GCPSelf-host on Cloud Run; Vertex AI agent toolingSame — Cloud Run hosts your container, but the MCP server is your code to maintain
AzureSelf-host on Azure Functions or Container Apps; Azure AI Foundry tool integrationsSame — hosting exists, a managed MCP-server product does not

To be equally honest the other way: the big clouds offer global regions, formal SLAs, and large catalogs of prebuilt connectors. This platform is in alpha — the win here is that MCP hosting, versioning, auth, and secret handling are one built-in primitive instead of a weekend project.

Next steps​