CloudCrane

npx add-mcp 'https://cloudcrane.ai/api/build/mcp'

The workspace MCP

POST /api/build/mcp opens a whole workspace rather than one tool, and there are two ways in. Sign in: add the URL to your agent with no key, and an owner approves it on a CloudCrane page. Or paste a build key, which starts cc_build_ and is a different thing from a serving key. Either way only an owner can let an agent in, every plan includes it, and any request carrying an Origin header is refused outright, because a credential that opens a whole workspace has no business in a web page.

1. 1 Claude Find CloudCrane in Claude's connectors directory (claude.ai/directory/cloudcrane) and connect. Or add it yourself: Settings → Connectors → Add custom connector, with the URL https://cloudcrane.ai/api/build/mcp, keeping *Sign in now* and *Register automatically*.
2. 2 ChatGPT Add a custom MCP server with the same URL and choose *OAuth* for authentication. It's yours alone; nobody else in ChatGPT sees it.
3. 3 Cursor Add it to ~/.cursor/mcp.json with the key url (below), then choose *Needs login* beside it in Cursor's MCP settings.
4. 4 Cline Customize → MCP → Add MCP Server: remote, Streamable HTTP, the same URL. Cline opens the sign-in in your browser.

Cursor (~/.cursor/mcp.json) and Cline (cline_mcp_settings.json)

// Cursor
{ "mcpServers": { "cloudcrane": { "url": "https://cloudcrane.ai/api/build/mcp" } } }

// Cline
{ "mcpServers": { "cloudcrane": { "transport": { "type": "streamableHttp", "url": "https://cloudcrane.ai/api/build/mcp" } } } }

What signing in does. The client finds our sign-in from the server's first answer and opens a CloudCrane page where an owner picks the workspace and what the app may do: read, or read and build if the app asked. It starts on read. The page leads with where it will send you back, because an app's name is only what it calls itself. The app gets a token that lasts an hour and renews itself. Each app you approve becomes a build key in Developers, marked as signed in with OAuth, with the same limits and the same rules as any key. Revoke it there and it stops at once. Build tools are marked as changing data, so a client that honours that, Claude among them, asks you before each one.

Every key gets seventeen read tools: list_datasets, get_dataset, list_contracts, get_readiness, list_review_items, get_receipts, list_value_sets and get_run to find its way around; list_tools, list_scenarios, get_tool_insights, list_drift_alerts, get_usage and get_next_actions to watch what is deployed and what needs doing (the same list a person sees on Home); list_events, for an agent nothing can send a webhook to, to read every event a webhook would carry from a cursor, kept 30 days; and list_approvals and get_approval to follow what it asked a person for. Read-only, and not by convention. They run inside a read-only database transaction, so a write cannot happen even if something tried. list_contracts includes each value's definition and examples, what the field is for, where its definitions come from, and the PDFs it reads.

A key made to build gets thirteen more. Choose *Read and build* when you make the key: create_dataset (a table as CSV, TSV or JSON), create_field, update_field, create_value_set, import_value_set_version, start_run, publish_release and request_approval to build; and deploy_tool, update_tool, create_tool_key, create_scenario and run_scenarios to put it into service. A tool it deploys lets callers exclude any safety value and opens nothing else until it says; a tool key's secret is returned once, and only to a build key allowed to read records, since a tool key reads them; a scenario only ever adds a check, and no agent can remove one. Each goes through the same checks as the dashboard, so an agent can't make a field the editor would refuse, and a refused call leaves nothing half-made. Each change is recorded as made by that key, never as a person, and definitions an agent writes are marked as drafted in the field's history. On a safety field an agent can add values but never remove one or make it a normal field. A read-only key is never offered these tools, and is refused if it calls one.

An agent publishes only when the accuracy gate passes by itself: the dataset has a published answer key, today's fields have been measured on it, and no safety value is found less often than in the last release. It can't give the reason a person gives to publish past the gate, and without an answer key there's no gate to pass, so a person publishes. The release names the key that published it, and a tool with scenarios still holds it back if they fail. When it needs more, it asks: request_approval files the release for a person, who approves it with the reason the release keeps.

A secret is shown once. It's stored only as a hash, so it can't be shown again. Lost one? Give the key a new secret in the dashboard: the key keeps its name, access and limits, and the old secret stops working at once.

Record contents are off by default. list_review_items will not return the record itself unless the key was explicitly granted that. An agent can triage a queue by field and reason without ever reading your data.

A refusal says what to do next. Besides the sentence and a stable code, a refused call carries next when there is something to do: { "action": "request_approval", "tool": "request_approval", "kind": "publish_past_gate" } when only a person may publish, { "action": "upgrade", "url": … } past a plan's limit, ask_owner when the key itself can't, retry_later when measuring hasn't finished. The REST API's errors carry the same next.