Hackathon build Updated on

Hackathon build (The WebMCP Challenge, 3 to 10 September 2026); outcome not recorded.

AgentReady: scoring whether the web is ready for agents

For The WebMCP Challenge I built AgentReady, a benchmark that scores a site 0 to 100 on whether agents can complete tasks; it registers 13 WebMCP tools, runs real audits through headless Chrome on Cloudflare, and reports every score with a 95% confidence interval over N runs.

95% CIN runs per site, 8-category failure taxonomy, 13 WebMCP tools

Context

WebMCP lets a site register tools that an agent can call instead of driving the UI. The challenge asked for something built on it. I wanted a number, not a demo: a way to say how ready a given site is, with error bars, and a way to see what an agent fails at when it is not ready.

Constraint: eight days, a serverless budget, and audits that must never bypass a login or a CAPTCHA; a failure has to be recorded as a failure.

Problem

Site owners and agent builders had no shared measure of agent readiness; claims came from single demos with no repetition and no confidence interval.

What I built

I built a readiness dashboard that registers 8 WebMCP tools, a demo store with 5 tools and a shared human-and-agent cart, live agent-call analytics, and an instrumentation SDK that wraps registerTool so any site can report tool calls.

The audit runner drives Playwright and an LLM agent against a site N times in UI mode and N times in WebMCP mode, computes success rates with 95% confidence intervals, classifies each failure into one of 8 categories, and publishes the rubric with the score. queue_live_audit triggers a real serverless audit: Cloudflare Queues to Browser Rendering (headless Chrome on the edge over CDP) to a Workers AI agent (Llama 3.3 70B) to D1. Synthetic sample rows are labelled as synthetic; CAPTCHAs and logins are recorded as failures, never bypassed.

Architecture

vinext (Cloudflare’s Vite-based Next.js API reimplementation) on Cloudflare Workers; D1 for results; Workers AI for the agent; Browser Rendering for headless Chrome; Queues for audit jobs; R2 pre-wired. Security: same-origin audit restriction, a daily run budget, payload caps, prompt-injection awareness. MIT licensed.

  1. Dashboard or WebMCP tool call: queue_live_audit
  2. Cloudflare Queue, daily run budget and payload caps enforced
  3. Browser Rendering: headless Chrome over CDP, same-origin only
  4. Workers AI agent (Llama 3.3 70B) attempts the task N times, UI mode and WebMCP mode
  5. D1: per-run outcome, failure category, 95% confidence interval, readiness score
Audit path: a tool call enqueues a job; the worker opens the target in headless Chrome, lets the agent attempt the task repeatedly in both modes, and stores each outcome so the score carries a confidence interval.

Stack TypeScript, Cloudflare Workers, vinext, D1, Workers AI, Browser Rendering, Cloudflare Queues, Playwright, WebMCP

Results

13 WebMCP tools live, a published rubric, and scores that come with 95% confidence intervals over N runs and an 8-category failure taxonomy; the whole thing is live at agentready.prescalesystems.workers.dev with the source on GitHub. Built and submitted in 18 commits between 3 and 10 September 2026; outcome not recorded.

AgentReady, what the benchmark measures
ElementValue
WebMCP tools registered13 (8 on the dashboard, 5 in the demo store)
Runs per site per modeN, configurable
Confidence interval on success rate95%
Failure categories8
Readiness score100 x (0.70 x best success rate + 0.15 x has WebMCP + 0.15 x efficiency)
Build window3 to 10 September 2026, 18 commits

Hackathon build; the sample rows shown on the dashboard are labelled synthetic where they are.

What I'd do differently

I published the rubric but not a metric table of real audits. Next time I would run N=10 audits on five public sites in both modes before submitting and commit the JSONL with the README table, because a benchmark without its own baseline results asks the reader to take the method on faith.