The same app, built from your editor over MCP

Connect Claude Code, Cursor or Copilot to Supero and build without opening a dashboard — one session, start to deployed.

MCPBuild estimate ~45 minutes6 min readAugust 25, 2026

If you already live in an editor, you do not need App Studio. Point your AI agent at Supero over MCP and it authors, validates and deploys the same app bundle — in your repo, under a key you scoped.

Start here

Why you might prefer this

App Studio and MCP produce the same thing: a Supero app bundle. The difference is where you sit while it happens.

Choose App Studio when	Choose MCP when
You want the guided flow with review gates	You already live in an editor and want the files local
You want a preview to show someone this afternoon	You want the app in your own repo, under your own version control
You are new to the platform	You want your agent to iterate on it like any other codebase

Step 1

Connect your editor

Create an API key for the project in the dashboard, then wire it in. For Claude Code there is no config file to edit:

bash

claude mcp add --transport http supero \
  https://api.supero.dev/mcp/v1/messages \
  --header "X-API-Key: ak_..."

# then check /mcp inside Claude Code — "supero" should show as connected

Cursor takes the same URL and header in ~/.cursor/mcp.json. VS Code Copilot takes it in .vscode/mcp.json with "type": "http", then Agent mode. Any MCP client that speaks Streamable HTTP and JSON-RPC 2.0 works.

One more thing to get right up front: what the key is allowed to do. A project-admin key can build into that one project — the right default. A domain-admin key can build into any project and create new ones. A tenant-scoped key is refused, and a plain JWT session is refused for every mutating build tool — create or update a project, publish, deploy, go live, tear down, and the data-source tools — though it can still run the read-only ones, including build_validate and build_doctor.

Step 2

Run the session

Tell your agent what to build in plain language. The one instruction worth giving explicitly is orient first — a model that skips the discovery tools writes plausible code against a platform shape it invented.

text

Build a Supero app for tracking client projects and time entries.

Start by calling build_whoami, then build_get_skills and build_get_examples
before you write anything. Use build_validate after each change, and run
build_doctor before publishing.

What the agent does, tool by tool

That is a whole first session. There are plenty more tools — data sources, service configuration, logs, teardown — and your agent discovers the full list itself with tools/list once connected.

What lands in your repo

The files are yours; the runtime is not

A Supero app is a directory with fixed paths. Knowing which files you own and which are regenerated is the difference between a productive session and an afternoon of edits that vanish.

File	Yours?	What it is
`schemas.py`	Yes	The data model — exports `ALL_SCHEMAS` and `PUBLIC_SCHEMAS`
`config.py`	Yes	One `AppConfig`: app identity, tenants, users, services
`setup.py`	Yes	Registers schemas and policies, seeds data
`ui/app.js`	Yes — required	Your UI entry point
`ui_schemas.py`	Optional	A declarative UI grammar `app.js` can render from
`__main__.py`, `requirements.txt`, `run.sh`, `.env.example`	Yes	Entry point, the `supero` dependency, launcher, config template
`ui/index.html`, `ui/config.js`, `ui/server.py`, `ui/.js` runtime*	No — regenerated every run	The SDK UI runtime (this does not mean your `app.js`)

Why to trust the result

The agent is not allowed to mark its own homework

Tool	When	What it catches
`build_validate`	Before publish	Bundle shape and platform contract violations. AST-only — your code is never executed
`build_doctor`	Before publish	The silent deploy-killers: things that validate cleanly and still render a blank page
`build_smoke_test`	After deploy	Whether the deployed URL actually loads and reads data — not whether it compiled

The pre-deploy gates check the bundle; only the post-deploy one checks the running app. Deploy to cloud_ephemeral first, smoke-test that, and only then call build_go_live — and take the hostname from the public_url it returns rather than constructing one.

Know the edges

What to expect

Sessions vary. One converges in twenty minutes; another needs three attempts. The gates are what stop an unlucky session becoming a broken deploy — do not skip them to save time.
Bundle limits are real: 300 files, 2 MB per file, roughly 8 MB inline. Past that your agent uses build_stage_bundle for an out-of-band upload.
Iterating on an existing app starts from `build_get_bundle`, not from scratch — that pulls the published files so edits build on prior work instead of quietly replacing it.
`build_go_live` needs a plan that includes cloud hosting. It refuses with a billing message otherwise.
Treat the key like a password. Keep it out of source control; Claude Code stores its MCP config outside the repo, and project-level Cursor/Copilot config files belong in .gitignore.

Want the guided version instead? From a paragraph to a deployed app.
Connect an existing database in the same session: Build on the data you already have.
A full agent-driven build with quality gates end to end: A field-service platform built from your AI editor.

Delivery estimates in this guide are for the scope described, built by one experienced developer with any vendor sandbox credentials already in hand. Treat them as a realistic starting point, not a commitment — and check the documentation for the authoritative behaviour of any API named here.

Build this on Supero

Describe it and get schemas, APIs, SDKs and a governed multi-tenant backend — or point your own AI editor at Supero over MCP and build it there.

Start building free →Talk to us