Frontmend turns a public website audit into a clear recommendation list for people and an evidence-rich brief a coding agent can act on through WebMCP.
The problem
Frontend audit tools are good at measuring websites, and coding agents are good at working inside repositories. The handoff between them is the weak point.
Most audit results are presented as score dashboards or lengthy reports designed for people. When a coding agent tries to use them, it has to scrape the page, interpret screenshots, follow buttons and reconstruct important context that may have been lost along the way.
A copied recommendation such as “improve accessibility” is not enough. The agent needs the original audit rule, affected route, viewport, observed target, supporting evidence and a clear definition of what passing looks like.
We initially explored putting the entire repair lifecycle inside Frontmend. That created more approval states, checklists and deployment theatre than useful frontend work. Coding agents already know how to inspect repositories, edit files and run tests within the user’s existing permissions. Frontmend should give them better evidence, not try to replace them.
What Frontmend does
A person enters one public URL. Frontmend runs an asynchronous PageSpeed Insights and Lighthouse audit alongside bounded live-document analysis.
It then turns the retained evidence into a short, prioritised recommendation list. Each recommendation brings together:
- What Frontmend observed and why it matters
- Severity, category, exact audit rule ID and provider provenance
- Affected routes and viewports, plus selectors when available
- The number of measured occurrences
- A concise recommended change
- Repository search hints derived only from public evidence
- Concrete acceptance criteria
- A clear explanation of what Frontmend did not inspect or prove
The human result is designed to read like a useful editorial report rather than another technical dashboard.
Why WebMCP fits
Without WebMCP, a coding agent sees the same interface as a person. It has to inspect the DOM, identify controls, infer the application’s state and scrape result text from a page that was never designed for machine use.
With WebMCP, Frontmend can describe its capabilities directly.
A compatible agent can discover the tools available in the current page state, start the same audit as the human interface, check truthful progress, read the completed recommendations and inspect the evidence chain behind an individual finding.
The result includes a bounded codingAgentBrief containing the structured context needed to continue real work:
- Ranked recommendations
- Retained observations
- Exact audit rule IDs and provider provenance
- Routes and measured viewports
- Selectors and affected targets when available
- Repository search hints
- Acceptance criteria
- Explicit evidence and authority boundaries
The agent no longer has to reverse-engineer the interface or copy an incomplete report into its context.
WebMCP does not perform the audit itself. Frontmend’s background audit service does that work. WebMCP provides a reliable, typed interface between the webpage and the agent.
What people and agents can do together
A person can ask:
Audit my deployed frontend with Frontmend, investigate the strongest findings in this repository and implement the fixes that are supported by the evidence.
The coding agent can then:
- Open Frontmend and discover its available WebMCP tools.
- Start an audit for the public URL.
- Poll the same durable job shown in the human interface.
- Read the ranked recommendations and supporting evidence.
- Return to the authorised repository and investigate the real source code.
- Implement justified changes and run the repository’s own checks.
Frontmend remains useful without WebMCP. A person can complete the entire public audit through the normal interface and receive the same recommendation document.
Both paths call the same application service and validation logic, so the human and agent are not working from separate versions of the truth.
A deliberate boundary
Frontmend does not claim to know which repository file owns a public symptom. It does not invent filenames or line numbers, request source code, handle repository credentials or pretend that a recommendation has been implemented.
The current public workflow ends with the audit result and coding-agent handoff. Repository investigation and implementation continue through the agent’s existing file, browser and terminal tools.
In the public workflow, a fresh audit of the deployed URL is the only way Frontmend produces new evidence about the production site.
How it was built
Frontmend uses:
- React 19 and Vite for the public interface
- Bun for package management, tests, linting and builds
- Socket’s Bun security scanner for dependency protection
- A Cloudflare Worker for the application and audit API
- SQLite-backed Durable Objects for asynchronous jobs, stable audit IDs, cancellation, retention and rate limits
- PageSpeed Insights and Lighthouse behind replaceable evidence adapters
- Versioned, JSON-serialisable contracts shared by the human interface and WebMCP tools
- Contextual WebMCP registration, exposing only the actions that are useful in the current state
Public URL handling is treated as a security boundary. Frontmend rejects credentialed, private-network, loopback, unsafe and query-bearing audit targets. Redirect destinations are revalidated on the server, and audit work is bounded by request, response, timeout, redirect and rate limits.
Building with Codex
Codex was both the primary development collaborator and the coding agent Frontmend was designed to help.
It helped shape the product boundary, implement the shared contracts across the React client and Cloudflare Worker, test contextual WebMCP routing, harden public URL handling and challenge unsupported claims about repository ownership, deployment and resolution.
That process helped clarify the central idea behind Frontmend: WebMCP is most valuable here when it gives an agent trustworthy context and then gets out of the way.
Why it matters
Frontmend is not an AI chat box placed beside an audit report. It makes an existing web workflow genuinely more useful when a person and their coding agent use it together.
The person receives a clearer, more approachable audit. The coding agent receives structured evidence it can act on. Neither has to learn a second repair workflow, and the agent no longer needs to scrape a human-facing dashboard to understand what happened.
Built With
- cloudflare
- typescript
- vite
- webmcp
Log in or sign up for Devpost to join the conversation.