A field-service platform built from your AI editor over MCP

What we are building

A regional HVAC company dispatches thirty technicians. Office staff raise work orders, assign them to a technician and a time window, and track them to completion. Technicians work from a phone: today's jobs, directions, parts used, before-and-after photos, and a customer signature at the end. Supervisors approve anything over a cost threshold. Customers get an SMS when the technician is on the way.

We built it without opening the dashboard. That part is not the interesting one. The interesting one is that the agent doing the building was not allowed to tell us it worked: it validated the bundle against the live platform rather than against its own assumptions, deployed to a throwaway URL, and had to prove the running app loaded and read data before it could take a public address.

Connecting the editor — and what your key can do

Supero exposes an MCP server speaking JSON-RPC 2.0 over a single Streamable HTTP endpoint. Every initialize, tools/list and tools/call is a POST to the same path; there is no per-tool route and no domain segment in the URL, because scope comes entirely from the credential.

# Claude Code — no config file to edit
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 be listed 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 — those three simply have first-class instructions.

A project-admin key that targets a different project's project_uuid is refused with an explicit error rather than a bare permission failure — which is what you want when an agent is choosing arguments on your behalf. Replacing a project's entire app additionally requires a domain-admin key.

A build session, tool by tool

The tool surface is bigger than one session needs. Grouped by what stage it belongs to:

The app is a directory bundle with a fixed shape

The agent is not inventing a project layout. A Supero app has exact paths the CLI expects — it does not scan for scripts or infer structure. Knowing which files are yours and which are regenerated is the difference between a productive session and an afternoon of edits that silently vanish.

• Bundle limits: 300 files, 2 MB per file, roughly 8 MB inline. Past that — or when your model's output cap truncates a large file — use build_stage_bundle for an out-of-band upload and pass the returned file_id as files_ref.
• Put the same namespace literal on every schema dict; it must be a plain string, not a variable or an f-string.
• In config.py, "workflows" must be the last entry in services if the list is non-empty.
• Read appNamespace and publicSchemas from window.__SUPERO_CONFIG rather than hardcoding them — a hardcoded value diverges from schemas.py and the runtime cannot reconcile the two.

What the agent actually assembles

Have the agent call build_get_service_contract for each of these before it writes any UI. It returns the real state machine, the operation names and the default UI schemas — which is precisely the information a model would otherwise hallucinate.

The approval threshold is a workflow, not a code branch: bind @update:field:work_order, condition on the cost, and call approval when it exceeds the limit. The technician's photos go through the attachment service (which owns its own upload/scan/archive lifecycle) into your own S3 bucket. The "on my way" SMS is a service_call step.

Three gates, and what each one actually catches

An agent that writes code and declares victory is a liability. The gates exist so "it works" is a checked claim rather than an assertion.

For a change request on an app you already published, have the agent start from build_get_bundle rather than re-authoring from scratch. That pulls the current published files — including any hand-tuned UI — so edits build on top of prior work instead of quietly discarding it.

What this build does not give you

• Offline is yours to build. Technicians work in basements and dead zones, and nothing here queues a job update, a photo or a signature for later. The generated mobile app is online-first. If your engineers lose signal daily, that is the first thing you will add and it is not a small feature.
• Agent-driven sessions are less predictable than the guided builder: one can converge in two hours or need three attempts. The gates are what stop an unlucky session from becoming a broken deploy — do not skip them to save time.
• build_go_live needs a plan that includes cloud hosting; it refuses with a billing message otherwise.
• The behavioural test gate is off unless your deployment enables it.
• build_replace_project is destructive and needs a domain-admin key. Keep production in live mode so it is refused there.

How to run the session

Time to deliver

What the gates cover, and what they never will

The gates are the whole argument, and they are also the part you can verify without trusting us: deliberately break a deploy and run build_smoke_test against it. Watch it refuse once, early, and the rest of the session becomes an ordinary engineering loop rather than an act of faith.

What no gate covers is judgement. Nothing here checks that the work-order model matches how your dispatchers actually work, and no smoke test was ever going to tell you the technicians needed offline capture. The agent removes the typing. The specification is still yours.