For AI product teams, platform teams, and SaaS operators who need stable execution — not brittle browser automation.
FastWebMCP turns real product routes, dialogs, uploads, callbacks, and job flows into agent-usable capabilities without forcing a product rewrite or raw source exposure.
Built from real reference pressure: melogen-web, redol-style admin flows, GitHub Packages release artifacts, and CI-safe consumer templates.
Most teams already have a real product. The hard problem is exposing the right product capabilities to agents without turning every important workflow into brittle browser choreography.
The product problem
Dialogs, file uploads, session-bound mutations, async generation, and payment-state polling are fragile if the integration surface is only “click these selectors in order.”
The FastWebMCP answer
FastWebMCP gives teams a route-aware runtime, bridge contracts, browser execution helpers, and adapter templates so the stable unit of integration becomes a capability boundary — not a lucky DOM script.
Use the dedicated WebMCP page when you need the precise distinction between in-page tools, backend MCP, and raw browser automation.
The repo is credible because the beta already covers runtime orchestration, browser execution, React integration, bridge contracts, adapter defaults, release artifacts, and consumer install guidance.
What you get in one surface
FastWebMCP is strongest when teams need to move from “can an agent theoretically use this?” to “can we ship this safely inside a real product?”
The runtime is what turns product routes into manageable rollout surfaces instead of ad-hoc per-page scripts.
React teams don’t need to hand-wire runtime state into every page. The provider layer makes registration and readiness manageable.
This is where FastWebMCP starts paying for itself: dialog forms, file import, callbacks, async jobs, and polling-heavy routes already have reusable defaults.
The product isn’t credible if it only works in a sibling checkout. FastWebMCP already includes a path for publishing and consuming the SDK in remote build environments.
The delivery motion should mirror how real teams ship: identify the route, select the bridge mode, wrap it as an adapter, then verify and release.
Identify the real product surface: a form, dialog, upload, async job, or high-value mutation path.
Choose the smallest stable execution surface: markup for UI flows, callback for product-owned client logic, endpoint for protected jobs and mutations.
Use the default templates or define a custom adapter so the capability lives behind a stable contract.
Typecheck, test, build, package, and then roll the published SDK into consumer apps and deploy pipelines.
The important question is not which bridge sounds elegant. It is which bridge leaves the smallest and safest surface area for this product behavior.
Use selectors and field kinds when the product already has a stable form surface and you want the lowest integration overhead.
Admin forms, modal submissions, checkbox toggles, file inputs, and page-scoped actions with predictable UI state.
The page logic already lives in client callbacks or server-side jobs with richer status semantics.
Use callback bridges when the product already owns a meaningful client-side function and you want to expose that function directly.
Generation tasks, upload processing, and flows with product-specific client logic that should not be re-encoded as DOM actions.
You actually need a protected server mutation with pending/success/failure state tracking.
Use endpoint bridges when the capability is really a server-side job or mutation that must expose durable status semantics.
Payments, publishing, background jobs, report generation, and long-running tasks with explicit lifecycle states.
The flow is actually just a stable local form and would be over-engineered as a job endpoint.
These examples matter because they forced the SDK to support the awkward edges that real products actually have.
Generation-heavy products need more than one submit button. They have uploads, callbacks, async jobs, and multi-output delivery.
Blend callback and async job patterns so the agent sees a stable capability boundary instead of hidden page choreography.
The SDK improved its callback and multi-output posture because these flows demanded it.
Admin tools often hide critical flows in dialogs, file imports, and stateful result pages that are easy to break with browser-only automation.
Use dialog-form, file-import, and endpoint polling patterns to match how the product really works.
The SDK now supports dialog openers, file fields, and richer endpoint status semantics because this category forced the issue.
A local-only SDK does not count as a product if downstream teams deploy from remote GitHub Actions and Docker builds.
Ship the SDK through GitHub Packages and consume it through reproducible install templates.
FastWebMCP now has a credible publish-and-consume path instead of depending on sibling checkouts.
A strong landing page should answer two questions fast: which packages matter for my case, and what is the shortest path from install to route-level rollout?
Install the core integration path
npm install @fastwebmcp/core @fastwebmcp/browser @fastwebmcp/react
Bootstrap the runtime
import { createFastWebMCPClient } from '@fastwebmcp/core'void createFastWebMCPClient({controlPlaneBaseUrl: 'https://control.example.com',siteId: 'site_xxx',environment: 'prod',apiKey: 'fwmcp_site_xxx_prod_xxx',autoObserveRoutes: true,})
Hydrates config, tracks routes, mounts adapters, and emits telemetry.
Runs markup, callback, and endpoint bridge helpers in the product environment.
Adds provider + hooks so React teams can register tools and react to readiness cleanly.
Provides dialog form, file import, callback task, async job, and multi-output defaults.
The trust argument is simple: ship the package set, prove the bridge defaults, show the consumer path, and then connect all of it to how downstream teams actually deploy.
Core, browser, React, bridge-contracts, and adapters all build, typecheck, test, and pack as release artifacts.
Dialog openers, checkbox/file fields, callback registries, async jobs, and custom polling states are already implemented and unit-tested.
The repo already includes GitHub Packages publishing flow plus Docker/GitHub Actions consumer templates for remote deployment.
A strong landing page should remove doubts for engineering leads, platform owners, and product evaluators — not just explain the protocol vocabulary.
The goal is constrained retrofitting, not product rewrite. Teams attach runtime, choose a bridge mode per route, and expose capability boundaries where needed.
Pick the smallest stable execution surface: markup for stable UI flows, callback when product-owned client logic already exists, and endpoint for protected or polling-heavy mutations.
Yes. The current beta already includes GitHub Packages publishing and consumer templates for GitHub Actions plus Docker BuildKit secret installation.
Because the package set, bridge defaults, adapter templates, tests, pack artifacts, and reference-app-driven improvements are already in place and verifiable.
WebMCP is the page-level capability model: websites expose JavaScript tools inside shared UI context. FastWebMCP is the product and SDK layer that helps teams retrofit real routes, bridges, adapters, and release workflows around that model.