Mantle Builder

Build WebMCP services from business workflows—agent-ready and Cloudflare-ready.

Comment

Mantle Builder uses WebMCP to rapidly create your own WebMCP-enabled business service and take it to Cloudflare. Describe the workflow in agent chat; the agent builds and validates the Mantle contract, previews its API, MCP, WebMCP, and Admin surfaces, then hands it to a coding agent to finish the frontend, authentication, and production deployment.

Inspiration

Companies adopting agent workflows quickly run into business-logic gaps. Agents can reason and browse, but the organization's real rules—who can do what, which records exist, how an order or request moves, and which operations are public or staff-only—are still trapped in documents and bespoke code.

Conventional app builders also make the human perform every configuration step through a visual editor. We wanted a shared workspace where a person supplies intent and approval while an agent supplies structured implementation.

What it does

Mantle Builder lets a person describe a workflow and lets their agent build the service behind it through WebMCP.

What is Mantle?

Mantle is the open-source, config-as-code runtime beneath the Builder. An agent writes four atoms—Schema, View, Procedure, and Trigger—in one YAML Manifest; Mantle validates the contract and carries the runtime complexity. The same contract can power real consumer-facing services such as commerce, reservations, and application flows while immediately producing API, MCP, WebMCP, and Admin surfaces. Agents get the tools missing from their workflows, while operations teams get one place to manage customers, orders, requests, and queues.

The agent works through four typed WebMCP tools:

  • builder_get_started — inspect the active project, Mantle grammar, presets, and exact next calls.
  • builder_apply_preset — start from a tested business workflow.
  • builder_apply_manifest_patch — compile and safely activate confirmed changes.
  • builder_execute_preview — run the service as a mock actor, inspect mutations, and follow the result in Admin.

The prompt requires the agent to interview the user about actors, data, operations, permissions, and entry points, summarize the proposal, and wait for confirmation before changing the project.

Every accepted change immediately appears inside an embedded Mantle Admin developer console. The person can inspect schemas, procedures, triggers, interfaces, and operational Admin views. The agent can execute the service as an anonymous visitor, member, or owner, compare canonical entries before and after mutations, and watch Admin follow the affected View, collection, or record.

When the contract is ready, the user downloads a coding-agent handoff containing the complete Manifest, pinned Mantle references, a frontend WebMCP registration example, and deployment guidance. A coding agent can then add the consumer-owned frontend, authentication, provider configuration, and production wiring.

Why WebMCP

WebMCP turns Mantle Builder from a one-way generator into a shared control surface for people and agents.

An agent can author the service, seed data, and exercise public, member, and staff workflows through typed preview tools. Each action updates the same persistent sandbox the human is viewing, while the embedded Admin console follows the affected page, collection, or record. The agent acts; the human can watch, inspect, and approve the result as it happens.

This closes the loop from intent to implementation to verification. Teams can create MCP and WebMCP services that fill gaps in existing agent workflows, while operations still gets a trusted interface for managing customers, orders, requests, and queues.

How we built it

The React host registers Mantle-derived capabilities with document.modelContext. WebMCP calls enter one serialized mutation path where inputs and project revisions are validated. Valid Mantle resources compile into a runtime plan; a browser-hosted adapter and mock environment power the service preview.

Mantle Admin runs in a same-origin iframe and talks to the host runtime over a constrained message bridge. Project Manifests and canonical preview entries autosave to IndexedDB. The production host is deployed as a Cloudflare Worker.

What we learned

A useful agent interface needs more than tool registration. The tools must expose enough grammar and current state for an agent to act reliably, mutations need optimistic revision checks, invalid candidates must never replace the last working project, and the human needs a visual way to verify what the agent created.

Built during the challenge

The implementation began on September 2, 2026. The WebMCP authoring flow, Mantle preview, project persistence, coding-agent handoff, browser testing, and Cloudflare production deployment were all created during the submission period. The public commit history distinguishes this work from the pre-existing Mantle Core dependency.

Current limitations

Builder project Manifests and preview records persist only in the current browser; they are not production data or synced across devices. Preview authentication is intentionally mocked. The Builder supports declarative Views and builtin Procedure handlers; custom handler refs, a consumer frontend, production authentication, and provider wiring are completed after the coding-agent handoff.

Built With

Share this project:

Updates

Submission history