Connect your agent

Any MCP-capable agent can create, deploy, share, and inspect your artifacted apps — no CLI install. Sign-in uses the same device approval as npx artifacted login.

Cursor

Paste into .cursor/mcp.json (or Cursor Settings → MCP):

{
  "mcpServers": {
    "artifacted": {
      "url": "https://artifacted.cloud/mcp"
    }
  }
}

Claude

Paste into Claude's MCP config (Desktop or claude.ai custom connectors):

{
  "mcpServers": {
    "artifacted": {
      "type": "http",
      "url": "https://artifacted.cloud/mcp"
    }
  }
}

Codex / Gemini CLI

Point an HTTP MCP server at the URL below; approve in the browser when asked:

# Add an HTTP MCP server pointing at:
https://artifacted.cloud/mcp
# Your agent will open a browser to approve access (same device sign-in as the CLI).

What the agent can do

• list_apps — apps you own or can open
• create_app — new private app + URL
• deploy — upload files (static apps; ~5 MB per call — bigger apps: npx artifacted deploy)
• rollback — restore a previous deployment (last 20 kept)
• share — invite someone by email
• get_app — stats and last deploy
• get_stats — visits, visitors, and usage against the app's limits
• set_secret / remove_secret — environment variables for the app's code
• set_schedule / clear_schedule — run a server app on a cadence
• read_errors — recent app errors for the fix-it loop
• put_file / list_files / delete_file — the app's files, without redeploying

Every tool result includes the app URL so your agent can paste it back to you.

For a report that refreshes, deploy the page once and have it read its data from /__files (for example fetch('/__files/data/latest.json')). Then each day your agent only calls put_file with the new data — same link, same sharing, no new deployment. For a scheduled job instead of an agent, create an upload token in the app's Settings → Data uploads; it can only send that app's files, and the dialog shows the exact command for PowerShell, curl or npx artifacted files put.

For a dashboard over skill results: upload an Agent Skills folder and an AI key in Settings → Skills, set the trigger to run when new data arrives (or on a schedule), and have the page read results/<build>/… from /__files (for example fetch('/__files/results/latest/report.html')). artifacted runs the skills in the provider's sandbox and writes the outputs there — the page never talks to the AI provider itself.

Build a single HTML file, a single React component file (.jsx or .tsx — artifacted lowers it and builds the page around it), or a small fetch-handler worker — no frameworks; if you're deploying an existing framework project, build it to static output first and deploy that folder.

Data endpoints for the apps your agent builds

These are not MCP tools — the APP calls them from its own pages, which are already signed in. Put the app's data in the right place:

Structured data the team shares — lists, settings, records — goes to the app's own origin one key at a time, so a page never has to hold all of it:

curl -X PUT https://<app>.artifacted.cloud/__storage/todos -d '[{"id":1,"done":false}]'
# GET the same URL to read it back

≤512KB per value, ≤5MB per app, and everyone the app is shared with sees the same data — the owner and anyone invited as an editor can change it, viewers only read it; no database setup.

Files, images and exports go to /__files instead:

curl -X PUT https://<app>.artifacted.cloud/__files/logo.png --data-binary @logo.png

≤25MB per file, ≤500MB per app; never base64 a file into a storage value.

When keys aren't enough there's a real SQL database, no setup:

POST https://<app>.artifacted.cloud/__db/query
{"sql":"CREATE TABLE IF NOT EXISTS todos(id INTEGER PRIMARY KEY, title TEXT, done INTEGER)","params":[]}
{"sql":"INSERT INTO todos(title,done) VALUES (?,?)","params":["buy milk",0]}
{"sql":"SELECT * FROM todos ORDER BY id"}

One statement per call, values ALWAYS as ? placeholders in params — never interpolate values into the SQL text. ≤100MB per app; a query answers at most 5,000 rows — page big reads with WHERE id > ? ORDER BY id LIMIT 500. The database follows the app's shared-or-per-person setting: shared by default; if the app is set to per-person data, each person gets their own database automatically.

Any HTML page you deploy gets its localStorage backed by that same shared storage automatically, whether you deploy the folder or import it through the dashboard, so an app that already saves with localStorage becomes shared without a rewrite. Build for the shim:

• Persist with localStorage, indexedDB, or sessionStorage — never cookies or the Cache API for app data; those stay on one device.
• Keep each saved value under 512 KB.
• Store collections as JSON arrays of objects with a stable id field, one key per collection (todos, votes) — the shape the concurrent-write merge understands best. A single state object also merges: field by field, with id-keyed arrays inside it merging item by item; values with no structure the merge understands (plain strings, arrays without ids) take the server's version on conflict.
• Read through localStorage synchronously as usual; the first read after load is already populated.
• Other people's saves are pushed into every open page live as window storage events — listen for them and re-render from localStorage when one fires; without a listener the page reloads itself so their changes still show.
• Server apps that render HTML at runtime must call /__storage directly instead.

Endpoint

https://artifacted.cloud/mcp