Skip to main content
Cargo speaks Model Context Protocol in two ways: The UUID path is Cargo’s address for a workspace resource — not an MCP protocol requirement. Linear and Notion use /mcp the same way the platform server does. Keep curated servers on the UUID path; OAuth tokens are audience-bound to that exact URL. Agent skills over the cargo-ai CLI stay the right surface for building: project deploys, schema changes, and large batches.

Connect the platform MCP

Hosted clients that speak HTTP (ChatGPT custom connectors, Claude.ai, Cursor over HTTP) connect to:
The client discovers Cargo’s authorization server, opens a browser for you to sign in, and then calls the server with a short-lived access token. If you belong to more than one workspace, the consent screen asks which one to bind. Workspace API tokens still work as Authorization: Bearer. On the MCP servers page, Connect Cargo shows this URL and the live OAuth grants against it.

What it can do

The platform server is a small, stable tool list. It does not dump every CLI command or every workspace tool into the client’s picker.
  • whoami / get_usage — signed-in user, workspace, and recent credit usage
  • search_actions — search connector, native, tool, and agent actions
  • get_action_schema — input and output JSON schemas for those actions, without running anything
  • execute_action / execute_action_batch — run one input or a batch (credits apply)
  • get_run / get_batch / list_runs — poll a run or batch; get_run returns the last node output (not computed configs or traces); a finished batch carries a time-limited download URL for its output CSV
  • list_models / describe_model / query_models — the model catalog, one model’s columns and its dataset.model reference, and one read-only SQL SELECT over them (joins and aggregates allowed; small row cap, so aggregate rather than page)
  • map_context / search_context / browse_context / read_context — read the workspace’s context: map_context lists every indexed file with its title and summary, search_context returns matching lines, read_context returns a line range. Read-only — the platform server never writes to the context
config on a top-level action must be {}. Inputs go in data (single) or records (batch). Never fan execute_action out record-by-record — that is what execute_action_batch is for.

Connect a coding agent

cargo-ai mcp serves the platform server over stdio with the credentials the CLI already has:
Pass --server <uuid> to bridge a curated server instead. With no --server, the bridge uses CARGO_MCP_SERVER_UUID if set, otherwise the platform /mcp.
stdout carries the MCP protocol and every log goes to stderr, so nothing else may write to stdout around the bridge.

Define a curated MCP server

Each member is passed by handle — the same rich refs an agent accepts:
mcp/crm.ts

Deploy

Connect a remote MCP client

OAuth accepts any https callback, plus loopback for local clients. On the MCP server page, Connected apps lists each live OAuth grant. Revoke a grant to sign that client out; it will need to authorize again.

MCP or the agent skills?

Rule of thumb: more than a handful of records, or anything worth re-running, belongs in the CLI. Never fan an MCP tool out record-by-record over a list — that is what a batch is for, and it is cheaper and observable.

From the CLI

Servers can also be created and edited without a project:
Actions take kind: "tool" or kind: "agent" — an agent can be exposed as a callable MCP tool. update replaces the --actions, --resources, and --capabilities arrays wholesale rather than merging, so read the current server first and pass the full array back. Capabilities such as webSearch and context become MCP tools on the server.