Runs onWrit CloudDesktop
On this page
Every workflow, a tool.
The writ-cloud MCP server turns your account into tools an AI agent can call: twenty-five built-in tools for recording, workflows, data, crawls, monitors and automations — plus one tool per saved workflow. Auth is a wt_ API key.
connect ▸ one url
One server for the whole account.
Transport is Streamable HTTP: every message is a POST to /mcp on api.usewrit.app — JSON-RPC 2.0, a single object or a batch array per request. GET /mcp is a health probe. Authenticate with Authorization: Bearer and a wt_ API key; this endpoint takes no OAuth.
| Property | Value |
|---|---|
| Transport | Streamable HTTP — JSON-RPC 2.0 over POST /mcp, single object or batch array |
| Protocol version | 2025-03-26 |
| Server name | writ-cloud |
| Auth | Authorization: Bearer — a wt_ API key; no OAuth on this endpoint |
| Health | GET /mcp |
mcp-client config
{
"mcpServers": {
"writ-cloud": {
"type": "http",
"url": "https://api.usewrit.app/mcp",
"headers": {
"Authorization": "Bearer wt_xxxxxxxxxxxx"
}
}
}
} tools-list.sh
# Confirm the server is reachable and see the tools it exposes
curl -X POST https://api.usewrit.app/mcp \
-H "Authorization: Bearer $WRIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}' GET /api/mcp/connect-info hands you both ready-made blocks: the npm connector one-liner — claude mcp add writ-cloud -e WRIT_API_KEY=… -- npx -y writ-mcp — and a direct {"type":"http"} URL-plus-header block. Either way the key rides in an environment variable, never in argv.
tools ▸ twenty-five built in
Twenty-five tools, every account.
The built-in set covers the loop an agent actually runs: find a workflow, run it, read and search what it collected, schedule it, expose it, crawl, watch, automate.
| Tool | What it does |
|---|---|
writ_list_workflows | List saved workflows — id, name, inputs, schedule. |
writ_run_workflow | Run a workflow by id or name; waits by default and returns the extracted data. |
writ_workflow_data | The data a workflow has accumulated, as columns and rows. |
writ_search_data | Keyword search across everything your workflows collected. |
writ_export_data | The full table as CSV or JSON. |
writ_workflow_runs | Run history for a workflow. |
writ_set_schedule | Schedule a workflow: every_minutes, or daily/weekly with a time and days. |
writ_expose_workflow_api | Expose a workflow as a REST endpoint; returns the URL. |
writ_crawl_site | Start a distributed crawl; save_as makes it reusable. |
writ_saved_crawls | List saved crawls. |
writ_run_saved_crawl | Run a saved crawl — or serve its recent data via max_age. |
writ_saved_crawl_data | Read-only access to a saved crawl’s last results. |
writ_crawl_status | Progress of a running crawl. |
writ_create_automation | Create an automation. |
writ_create_monitor | Watch a page for changes. |
writ_wire_monitor | Choose what a detected change triggers — run a workflow, or notify. |
writ_browser_use | Open a real browser for any web task; returns a live page observation. |
writ_record_website | Start recording a website task, to be replayed later. |
writ_website_to_api | Turn a site with no practical API into a callable one — proposes your own workflows and ready-made marketplace APIs before recording anything. |
writ_build | Build a reusable workflow for any repeatable web task, when no more specific start tool applies. |
writ_browser_act | Drive the session — navigate, click, fill, select, extract — and get the next observation. Every replayable action is recorded. |
writ_browser_context | Read the current cleaned DOM, fields and links on demand. |
writ_browser_network | Search the requests the page made, captured while you drive. |
writ_browser_save | Finish the session and save its steps as a reusable workflow. |
writ_browser_cancel | End the session without saving anything. |
Cadence is enforced, not adjusted. A monitor interval below your plan’s floor is rejected with a 402 interval_too_short error — never silently clamped. The agent retries with a longer interval.
The connected client is the AI. A recording session runs on the same key: start it, drive it turn by turn with writ_browser_act, then finish with writ_browser_save — or writ_browser_cancel to drop it. Recording is automatic and saving is on demand, so a saved workflow replays afterwards with no model in the loop. For a sensitive value set data_key and the saved step keeps a placeholder rather than the value. Two things differ from the desktop connector, because the browser is ours and not yours: a start tool REQUIRES a url (it is screened against the SSRF and domain policy before the browser opens), and a site whose sign-in asks for a one-time code needs a persona_id — the code is minted server-side from that saved identity and never reaches the model. An open session holds a real cloud browser, so its wall-clock counts against your execution allotment until you save or cancel; one left idle is reclaimed automatically.
tools ▸ one per workflow
Each saved workflow is its own tool.
tools/list also carries one run_<name> tool per saved workflow, its input schema derived from the workflow’s declared inputs. Names are slugified; a collision dedupes to _2, _3; the built-in writ_* names always win. Every run tool takes the same three controls:
| Control | Default | What it does |
|---|---|---|
wait | true | Block until the run settles and return the extracted data. |
timeout_seconds | 120 | Longest the call waits before handing back a still-running run. |
max_age | 0 | Serve a recent successful result instead of re-running; 0 always runs fresh. |
Reuse applies to successful results only and is keyed on the exact inputs. Responses carry _cache.hit and _cache.age_seconds, so an agent can always tell a cached answer from a fresh one.
rules ▸ no side door
A tool call is an API call.
MCP adds a protocol, not a side door. Every tool call executes under exactly the rules of the REST API called with the same key: tenant isolation, key scopes, plan limits and metering all apply unchanged.
publish ▸ /mcp/{slug}
Published servers at /mcp/{slug}.
Publishing also mints standalone MCP servers at /mcp/{slug} — Streamable HTTP on POST /mcp/{slug}, with optional SSE at GET /mcp/{slug}/sse. They accept a wt_ key or an OAuth access token, so you can hand one workflow to a client without handing over an account key.
OAuth for MCP clients
A rejected call answers with WWW-Authenticate whose resource_metadata points at …/.well-known/oauth-protected-resource/mcp/{slug} — standard MCP OAuth discovery. The authorization-server metadata lives at GET /api/oauth/.well-known/oauth-authorization-server, and clients self-register through RFC 7591 dynamic registration at POST /api/oauth/register — public PKCE clients only, no client secret. Built for Claude custom connectors, Cursor, and any client that speaks the flow.
Tool configuration
Each published tool is a small contract; the server slug is always derived from the name.
| Field | Rule |
|---|---|
tool_name | matches ^[a-zA-Z_][a-zA-Z0-9_]*$ — at most 100 characters |
description | at most 500 characters — what the model reads to decide when to call |
input_schema | JSON Schema; null derives it from the workflow’s inputs |
timeout_seconds | 5–300 seconds, default 30 |
Published MCP tools are capped per plan (the max_mcp_tools limit) — a cap on how many tools you publish, never on how often they are called:
| Plan | Published MCP tools |
|---|---|
| Free | 2 |
| Starter | 5 |
| Pro | 15 |
| Growth | 40 |
| Scale | 100 |
| Enterprise | Unlimited |
faq