Mantle Docs

Appearance

Quickstart: Builder with your agent ​

Builder at mantle.tools/builder is a browser page that exposes WebMCP tools to your agent. This page is for people who want to design a Manifest without writing code first, then run it in Mantle Cloud or hand it to a coding agent.

1. Open Builder with your agent ​

Open Builder in a browser that supports WebMCP and ask your agent for what you need. To start another project, choose New project (Recipes or Blank), or let the agent pass projectId: "new" with baseRevision: 0 to builder_apply_preset or builder_apply_manifest_patch; the current project stays saved.

The agent must also be connected to that browser tab's WebMCP tools. A cloud coding session seeing the page URL or screenshots does not by itself have access to the tab's tools or browser draft. Builder's top document registers builder_get_started, builder_apply_preset, and builder_apply_manifest_patch; the embedded Admin's WebMCP indicator describes its own catalog.

Read the active project and revision with builder_get_started before editing. Browser drafts persist that revision with the Manifest across reopening and reload; legacy drafts start at revision 1. A stale edit or other tool failure returns a readable error; reread the project before deciding to retry. Saving a draft does not publish a service.

Without WebMCP, the page offers two explicit paths: open Builder with a ChatGPT Codex deeplink for the hosted coding-agent path, or copy a separate coding-agent prompt for Claude Code, Cursor, or another agent. The coding-agent prompt builds and runs the service locally; it does not contain Builder WebMCP tool calls. This is not ChatGPT Sites.

2. Describe the workflow ​

Tell your agent who uses the service, what they submit, what staff can do, and which changes need approval. The agent calls builder_get_started before editing. That call returns the pinned grammar summary (cms.mantle.aotter.net/v2), the preset list (with the official native recipes source), the active project and its revision, where it can be previewed, and the exact next tool calls. Reference sections overview, schema, view, procedure, trigger and auth return the corresponding full page from the installed @aotter/mantle handbook.

Builder accepts two kinds of edit:

ToolApplies toInput
builder_apply_presetAn empty project onlyrecipes loads the exact handler-free native docs/examples/recipes/manifests/recipes.yaml. Other workflow tabs are design briefs for the agent to turn into Manifest patches. blank skips the preset. Missing or unreadable Core examples fail closed; there is no host-owned Manifest fallback.
builder_apply_manifest_patchAny projectAn RFC 6902 JSON Patch against the committed Manifest; validated before it is committed.

Both require baseRevision. Builder rejects a patch whose base is older than the current revision, so an agent cannot overwrite work it has not seen.

Builder still pins @aotter/mantle 0.2.0-alpha.9 (these docs describe 0.2.0) and validates each edit with that native generator in a Worker, including grammar, references and SQL. A failed edit leaves the committed revision unchanged. Builder authors SQL Procedures only; ref handlers need TypeScript in a real project.

3. Try the service ​

The iframe Admin and builder_sandbox_* WebMCP tools share a native browser host using SQLite WASM and IndexedDB. Start the sandbox for the current project and revision, choose a simulated actor, and seed, invoke or observe data. An iframe edit can be read back through tools, and tool writes appear in the iframe. Reloading restores local test data.

These are local test identities, with native permission checks. Changing the Manifest requires an explicit sandbox reset before using previous test data. Legacy drafts are preserved but must be upgraded to native syntax before previewing.

For a separately hosted service:

  • Mantle Cloud. Connect your coding agent to Cloud MCP at https://cloud.mantle.tools/mcp. It creates a site, builds and verifies the handoff project locally, then pushes it; Cloud builds and publishes every push to main. Your sites and their status are listed at https://cloud.mantle.tools/app.
  • Self-host. Download the handoff below and let a coding agent run it locally with wrangler dev.

4. Hand off the service ​

Download the handoff ZIP from Self-host. Builder refuses to build it when the project has no atoms or when the project changed since the snapshot was taken.

What the handoff contains ​

  • manifests/site.yaml — the committed Manifest. This is the source of truth.
  • HANDOFF.md — the pinned @aotter/mantle version and source commit, links to the develop skill and grammar, and the steps a coding agent follows.
  • DEPLOY.md — local verification, pushing to GitHub, deploying with Wrangler, and production sign-in.
  • examples/register-webmcp.example.ts — a reference for registering the service's own WebMCP tools in a page; every placeholder must be replaced from the Manifest.

The ZIP is a coding-agent handoff, not a runnable application. It deploys nothing and contains no secrets.

From handoff to deployment ​

  1. Give the ZIP to a coding agent. It installs the pinned SDK packages, follows their installed native app-shell documentation, and runs mantle generate cloudflare-d1 generated manifests/site.yaml --admin.
  2. The agent runs mantle generate cloudflare-d1 generated manifests/site.yaml --admin --check and the project's checks, then starts Wrangler with local email OTP through the app-shell local console email sender. You enter the OTP from the Worker console at /admin/sign-in; the agent never bypasses sign-in or handles the OTP.
  3. Follow Deploy and operate for the deploy and the verify loop.
  4. Follow Authentication for production: replace console delivery with a real email sender, or a social or OAuth sign-in method. Admin and /mcp/admin fail closed until production auth is complete.

Source ​