Bolt

Bolt builds your frontend in a browser WebContainer. Connect it to Xano’s MCP server and the same agent also authors your backend as XanoTS — tables, APIs, functions, triggers — and ships it with npx xanots deploy, without you pasting an API key. The MCP server never runs the CLI. It hands the agent the exact command to run and mints a short-lived credential to run it with; Bolt runs the command in its own WebContainer.

agent: xanots_start_here          → orientation + the ordered steps
agent: xanots_docs("release")     → which environment, and how the frontend is wired
agent: (authors xano/index.ts)
agent: xanots_deploy_command      → the exact command + its environment prelude
agent: xanots_cli_token           → a credential, valid minutes not hours
agent: npx xanots deploy …        → runs in Bolt's WebContainer

Using Lovable instead? It has its own Xano connector, which handles OAuth through Lovable’s gateway and preloads the knowledge files rather than serving them as tools — see Lovable.

Add the connector

Open Bolt's connector settings

Add a custom connector.

Point it at the XanoTS mount

Field	Value
URL	`https://mcp.xano.com/xanots`
Transport	`HTTP`
Authentication	`OAuth`

The path matters. https://mcp.xano.com (no path) serves Xano’s general developer tooling — XanoScript validation, the Meta API, observability. The XanoTS release tools live on /xanots.

Authorize

There is no key to paste. Bolt discovers Xano’s authorization server from /.well-known/oauth-protected-resource, opens Xano’s consent screen, and you sign in.At the consent screen you pick an instance and a workspace. That choice is baked into the token — every credential the connector mints later is bound to it, and the agent cannot deploy anywhere else. Pick a different workspace by reconnecting.

Check the tools are live

Bolt discovers the tools automatically and enables them all by default. Ask the agent to run xanots_whoami; it reports the workspace you are acting on and confirms Xano is reachable.

What the agent gets

Six tools, all prefixed xanots_:

Tool	What it does
`xanots_start_here`	Orientation and the ordered flow. The agent calls this before any backend work.
`xanots_docs`	One knowledge document — `overview`, `cli`, or `release`.
`xanots_deploy_command`	The exact, correctly quoted CLI command plus its environment prelude.
`xanots_cli_token`	Mints the short-lived credential and maps it onto the three `XANO_*` variables.
`xanots_whoami`	Diagnostic — tells an expired credential from an unreachable Xano, and names the target workspace.
`xanots_version`	The server’s version and the `@xanots/sdk` release its guidance was checked against.

These cover reaching Xano and deploying — deliberately not authoring. The authoring documentation ships inside the installed package, and the agent reads it from node_modules/@xanots/sdk/llms.txt. See Coverage & agent grounding.

How a deploy runs

The agent asks for the command first and the credential second. That order is deliberate: the credential’s lifetime is measured in minutes and building the command spends none of it. xanots_cli_token returns three values, which the agent passes to the CLI process only:

XANO_INSTANCE_URL="https://xare-rvr8-mnnt.xano.io" \
XANO_WORKSPACE_ID="165" \
XANO_META_TOKEN="<the minted token>" \
  npx xanots deploy ./xano/index.ts

XANO_META_TOKEN is the secret. It is short-lived by design — it is never written to .env, project source, or Git, and it is discarded when the command finishes. If a run fails on authentication, the fix is minting a fresh credential, not a longer-lived one. XANO_INSTANCE_URL and XANO_WORKSPACE_ID are not secrets and are safe to write into project configuration.

Mints are rate-limited per user. An agent that loops on minting will be told to wait rather than served a stream of credentials.

Ephemeral by default

A deploy goes to an ephemeral environment unless you say otherwise — a disposable tenant with its own URL and its own database, expiring on its own. Nothing that already exists is touched, so a mistake costs a redeploy.

You say	Target	Command
”deploy”, “try it”, or nothing about where	Ephemeral	`xanots deploy`
”release”, “go live”, “my real workspace”	The workspace you chose at consent	`xanots release`

A release merges into your real workspace and overwrites what is live there. Because of that, the connector may have releases disabled — xanots_deploy_command then refuses to produce a release command and says so. The agent is told not to work around that refusal by assembling the command by hand or running a package.json script that performs one.

Pointing the frontend at the backend

Bolt serves the frontend itself, so nothing injects window.XANO_HOST the way Xano’s own static hosting does. Set the backend URL as a build-time variable instead — on a Vite frontend:

VITE_XANO_HOST=https://xare-rvr8-mnnt.xano.io/tenant/abc123

XanoTS frontends resolve the host in this order, so the variable is used when the injected global is absent:

const HOST = (typeof window !== "undefined" && window.XANO_HOST) || import.meta.env.VITE_XANO_HOST;

An ephemeral environment answers only at its tenant-scoped URL — https://<instance>.xano.io/tenant/<name>, including the /tenant/<name> segment. Take it verbatim from what the CLI printed for that deploy, not from instance_url; the bare instance URL reaches a different environment or 404s. Ephemeral URLs change, so re-read it after any deploy that may have created a new environment.

Stored files have the same trap: a file column’s own url addresses the instance host without the tenant segment. Build file URLs from the file’s path and the same HOST — fileUrl(row.avatar, HOST) from @xanots/sdk. See The typed frontend surface.

When something fails

Symptom	What it usually means
The agent reports an authentication failure from the CLI	The credential expired between minting and running. Mint again and retry once.
`xanots_whoami` says your token names no workspace	Consent finished without an instance and workspace selected. Reconnect the connector and pick both.
A release command is refused	Releases are disabled on this server. Deploy to an ephemeral environment instead.
API calls from the deployed frontend 404	`XANO_HOST` is unset, empty, or missing its `/tenant/<name>` segment.
The CLI fails on your code	The SDK indexes its own errors in `node_modules/@xanots/sdk/llms/errors.md`. Fix the def, mint a fresh credential, redeploy.

Tool names are a public interface and Bolt remembers which tools you enabled, so they are added to, never renamed.

Get Started

Authoring

Shipping

Connectors

Migrating an existing workspace

Add the connector

What the agent gets

How a deploy runs

Ephemeral by default

Pointing the frontend at the backend

When something fails

​Add the connector

​What the agent gets

​How a deploy runs

​Ephemeral by default

​Pointing the frontend at the backend

​When something fails

Add the connector

What the agent gets

How a deploy runs

Ephemeral by default

Pointing the frontend at the backend

When something fails