llms

llms.txt

If you are an agent deploying a canvas, start here. canvas-drop serves a single plain-text contract at {base}/llms.txt — no markup chrome, designed to be dropped straight into context. It is public (served from the docs band, readable without a session) so you can learn the API before you hold credentials.

Deploy in two steps

1. Get a per-canvas API key — the canvas owner creates the canvas in the dashboard (the api create method mints the canvas plus a one-time secret key) and hands you that key, shown once.

2. Push your artifact with the Bearer key and a ZIP body:

   PUT {base}/v1/canvases/{id}/deploy
   Authorization: Bearer <secret-key>
   Content-Type: application/zip
   

   This publishes a new live version directly — no draft loop. Read-back and companion routes: GET /v1/canvases/{id}, GET /v1/canvases/{id}/versions, GET /v1/canvases/{id}/files, POST /v1/canvases/{id}/rollback, POST /v1/canvases/{id}/unpublish. For large or repeat deploys, the staged content-addressed flow (POST /uploads → PUT /uploads/{uploadId}/blobs/{hash} → POST /uploads/{uploadId}/finalize) sends only changed blobs. See the Deploy API.

{base} is the instance origin. The key is verified per-canvas; it only deploys to the one canvas it belongs to.

Connect over MCP (no key to paste)

If your host speaks the Model Context Protocol, add {base}/mcp instead of handling keys. You sign in once through the instance's normal org login (OAuth, with automatic client registration) and then get identity-scoped tools across every canvas you own: whoami, list_canvases, create_canvas, get_canvas, list_versions, deploy_canvas, begin_deploy/add_files/finalize_deploy, get_canvas_file, rollback_canvas, delete_version, unpublish_canvas, plus the full management surface (update_canvas settings/sharing/previewMode, set_canvas_preview custom cover, set_capabilities, set_canvas_slug, regenerate_deploy_key, archive_canvas/unarchive_canvas, delete_canvas, clone_canvas, get_canvas_usage, the access tools list_access/grant_access/ invite_to_canvas/revoke_access, the team tools list_teams/ create_team (omit orgId for a personal team)/rename_team/delete_team/ add_team_member/remove_team_member/cancel_team_invite/list_team_members/ list_shared_canvases (plus update_canvas with access: "team" + teamIds to share a canvas with a team), and the editor draft loop get_draft/ read_draft_file/write_draft_file/delete_draft_file/rename_draft_file/ publish_draft/restore_draft). The MCP is at full parity with the dashboard — anything an owner can do in the UI, an agent can do here. The full table is in the MCP server reference. Owner-scoped management tools only touch canvases you own; list_shared_canvases returns non-owned canvases already accessible to you. Typical flow: create_canvas then deploy_canvas. list_canvases takes a forgiving query (matches title + description + tags + slug, case/accent/whitespace-insensitive, multi-word AND) and a tags any-match filter; update_canvas sets the single description (max 2000) and the canvas's unified tags (max 20, ≤50 chars each — one set used for both owner-list filtering and public gallery display, no separate "gallery summary"/"gallery tags"). For Team and Whole-org shares, update_canvas.discoverability is link_only by default; set it to listed only when people who already have access should find the canvas in Shared. When the instance has an org boundary configured, whoami also returns your orgs, your teams, and an isGuest flag; pass an org id as create_canvas's orgId to home a canvas in the org so it can be shared org-wide (omit for personal). With no org configured these are no-ops. If an admin has disabled a canvas it becomes read-only: reads keep working but every mutation tool fails with DISABLED: <reason>. Every deploy publishes immediately (no draft step). The live URL is access-controlled (org sign-in), so don't verify a deploy by fetching it — an unauthenticated GET returns a login page. Verify through the server: the returned {version, fileCount}, list_versions, or get_canvas_file (reads back the live files/content). Strongly prefer curl for the file transfer — the MCP deploy tools inline bytes into the model, so when you can run shell commands, curl the staged Deploy API and PUT each blob's raw bytes instead (ask for command permission if needed). Reserve MCP deploys for a small first publish without shell access. create_canvas returns a deploy block with the exact curl endpoints (incl. a readback URL) so you never probe for the API host. Use the readback URL from that block to confirm the live files, or call get_canvas_file (no path lists the manifest; a path reads back content, capped at 256 KiB). Full reference: MCP server.