WebMCP Hackathon: What Worked, What Shipped

You probably searched for “webmcp hackathon” to see what teams built and which setups actually worked. There isn’t a single public, canonical hackathon recap we can responsibly cite. So here’s the useful version: what a WebMCP hackathon looks like when it ships, with concrete projects, runnable code, a judging rubric, current ecosystem support, and production pitfalls to avoid.

TL;DR

• There’s no official public “WebMCP hackathon recap” yet; the ecosystem is early. You can still run a successful sprint today with a narrow scope and the right agent/browser targets.
• Build small, high‑leverage tools on real pages (cart, checkout, search). Return small JSON results and require explicit confirmation for sensitive actions.
• Test with agents and frameworks that work today: ChatGPT desktop “site tools”, ChatGPT Work, Vercel agent-browser, Stagehand, and Browser Use. See the ecosystem tracker.
• Great judging rubric: clear tool descriptions, correct side effects, guardrails, visibility (logs/telemetry), and a live demo across at least two agent runtimes.
• Production lessons: UIs drift, agents differ, and missing form semantics hurt. Health checks, analytics, and versioned configs reduce breakage.

What “counts” at a WebMCP hackathon

Hackathon projects that land well do three things:

• Expose a real action behind a page as a WebMCP tool (JSON‑schema input, async execute, small JSON result).
• Put guardrails on sensitive operations (payments, account changes, deletion) with user confirmation in page.
• Demo the tool being called by a real agent runtime that supports WebMCP today.

Quick refresher:

• WebMCP is an in‑page browser capability that lets a site register tools via document.modelContext (or legacy navigator.modelContext). Tools run in the user’s existing session—no new backend or API keys for the agent.
• This is different from MCP (Anthropic’s Model Context Protocol) which runs server‑side over stdio/HTTP. If that split is fuzzy, see what is the difference between MCP and WebMCP.
• Tools are JSON‑Schema described. Good descriptions tell an agent when to call the tool, required preconditions, and side effects. If you’re comparing scraping vs tools, read WebMCP vs agent browsers for a clear mental model.

What works today: agents, browsers, frameworks

WebMCP is early, and support varies. Before your event (or sprint), set clear targets using the public WebMCP support tracker. Highlights, verified by hand:

• Agents that work today: ChatGPT desktop app (native “site tools”), ChatGPT Work.
• Frameworks that work today: Vercel agent-browser (Chrome it launches), Stagehand (TypeScript, on a browser it launches), Browser Use (on their hosted agents).
• Browsers: Chrome and Edge in origin trial; Brave behind a flag; Firefox no support; Safari opposed; Lightpanda partial (old address).
• Some agents show no support or are behind flags (e.g., Claude for Chrome, Codex extension). Don’t plan your demo around them unless you’ve tested the exact build.

If your goal is a smooth demo, pick one of the “works today” options above and rehearse.

Starter projects that consistently impress

These are scoped, demo‑friendly, and show real value in under a day. Each maps to a single page template and 1–3 tools.

1. Cart actions for e‑commerce

• Tools: get_cart_summary (read‑only), add_to_cart (guarded), apply_coupon (guarded).
• Demo: Agent adds a product, applies a coupon, shows final total.
• Why it lands: visible UI change plus a JSON result; easy to test.

2. SaaS account preferences

• Tools: update_email_notifications (guarded), get_notification_settings (read‑only).
• Demo: Agent turns weekly digests on/off.
• Why it lands: clear side effects and a safe scope.

3. Search plus shortlist

• Tools: search_catalog (read‑only), add_to_shortlist (guarded), get_shortlist (read‑only).
• Demo: Agent searches and curates a shortlist; shows count and links.

4. Support flows

• Tools: create_support_ticket (guarded), get_ticket_status (read‑only).
• Demo: Agent files a ticket with a short description; returns ticket ID.

If you want deeper coverage for forms, see WebMCP forms basics and the form coverage checklist.

Runnable example: core cart tools with guardrails

The snippet below registers two tools. It feature‑detects the current and older WebMCP addresses, provides an in‑page confirmation for sensitive actions, and returns small JSON results.

// Feature-detect current and older WebMCP addresses
const mc = (document && document.modelContext) || (navigator && navigator.modelContext);

// Simple in-page confirm (avoid window.confirm for agents and UX)
function confirmInPage(message) {
  return new Promise((resolve) => {
    const wrap = Object.assign(document.createElement('div'), {
      style: 'position:fixed;inset:0;background:rgba(0,0,0,0.4);display:grid;place-items:center;z-index:9999;'
    });
    const box = Object.assign(document.createElement('div'), {
      style: 'background:#fff;padding:16px;border-radius:8px;max-width:360px;font:14px system-ui;'
    });
    box.innerHTML = `<div style="margin-bottom:12px;">${message}</div>
      <div style="display:flex;gap:8px;justify-content:flex-end;">
        <button id="no">Cancel</button><button id="yes">Confirm</button></div>`;
    wrap.appendChild(box); document.body.appendChild(wrap);
    box.querySelector('#no').onclick = () => { document.body.removeChild(wrap); resolve(false); };
    box.querySelector('#yes').onclick = () => { document.body.removeChild(wrap); resolve(true); };
  });
}

if (mc && mc.registerTool) {
  // Read-only: get_cart_summary
  mc.registerTool({
    name: 'get_cart_summary',
    description: 'Use to read the current cart. No changes. Returns item count and total.',
    inputSchema: { type: 'object', properties: {}, additionalProperties: false },
    async execute() {
      // Example: read from your page state; avoid secrets
      const items = Array.from(document.querySelectorAll('[data-cart-item]'));
      const total = document.querySelector('[data-cart-total]')?.textContent || '';
      return { ok: true, items: items.length, total_text: total };
    }
  });

  // Sensitive: add_to_cart (requires in-page confirmation)
  mc.registerTool({
    name: 'add_to_cart',
    description: 'Add a product to cart. Use only on product pages with a visible “Add to cart” button. Requires user confirmation in page.',
    inputSchema: {
      type: 'object',
      properties: { sku: { type: 'string', description: 'Product SKU shown on page' }, quantity: { type: 'integer', minimum: 1, default: 1 } },
      required: ['sku'], additionalProperties: false
    },
    async execute({ sku, quantity = 1 }) {
      const ok = await confirmInPage(`Add SKU ${sku} x${quantity} to cart?`);
      if (!ok) return { ok: false, cancelled: true };
      // Bind to your UI; e.g., set quantity input and click the button
      const qty = document.querySelector('[data-qty-input]'); if (qty) qty.value = String(quantity);
      const btn = document.querySelector('[data-add-to-cart]'); btn?.dispatchEvent(new Event('click', { bubbles: true }));
      return { ok: true, sku, quantity, note: 'Clicked add to cart' };
    }
  });
} else {
  console.warn('WebMCP not available. See https://agentlayer.tech/ecosystem/ for support.');
}

A few practices worth copying into every project:

• Results are small and JSON‑serialisable; the agent doesn’t need your whole DOM.
• Descriptions are explicit about when to call the tool and what it does.
• Sensitive actions force a visible, in‑page confirmation. Never pass secrets, payment tokens, or account credentials through parameters.

For a narrated, end‑to‑end build, see the practical WebMCP demo walkthrough.

Demo flow: how judges and agents see it

This diagram shows a typical demo path: agent discovers tools, calls one, your page asks the user to confirm, then executes and returns a concise result.

Minimal hackathon setup that actually works

Timebox yourself to an hour:

1. Pick one page template and one agent runtime that “works today” (ChatGPT desktop or Vercel agent-browser are safe bets). Double‑check versions right before the event using the ecosystem status.
2. Add a single script with your tool registrations. Feature‑detect document.modelContext then fall back to navigator.modelContext.
3. Implement one read‑only tool and one guarded write tool. Keep inputs small, and avoid complex nesting in JSON schema.
4. Rehearse the demo: open the page in the chosen runtime, ask the agent to perform the action, accept the in‑page confirmation, and show the result payload to judges.
5. Stretch goal: add basic analytics so you can say which agent called which tool and how long it took. If you need this out‑of‑the‑box plus drift checks and versioned configs, Agent Layer provides that layer without changing your app code.

If you need a deeper primer on enabling WebMCP on a production site, read the how‑to guide.

A pragmatic judging rubric

Use this to score or self‑assess projects on signal, not sizzle.

• Tool design and descriptions
  • Inputs are minimal and validated by JSON Schema.
  • Descriptions state preconditions, when to use the tool, and side effects.
• Safety and consent
  • Sensitive actions require explicit, in‑page confirmation.
  • No secrets or tokens passed via tool parameters.
• UX and observability
  • Visible, predictable UI changes after execution.
  • Clear JSON results that summarise what happened.
  • Basic telemetry: success/error and duration, at least to the console. If you want production‑grade analytics and which agents called what, Agent Layer can provide this.
• Interop and realism
  • Demo works in at least two runtimes from the “works today” list.
  • Tools run with the user’s existing session; no contrived backdoors.
• Maintainability
  • DOM bindings are isolated and well‑named (e.g., data- attributes) to reduce drift.
  • Versioned configs and quick rollback are a plus in real deployments.

Why teams succeed or stall in one day

Patterns we’ve seen across internal sprints and early adopters:

• Narrow scope beats ambition. One page, two tools, one awesome demo.
• Read‑only first. A successful get_* tool proves the wiring. Add guarded writes second.
• Honest tool descriptions make agents smarter than complex architectures. The description text is your UX for the model.
• Feature detection prevents “it works on my machine” failures. Some agents still look at navigator.modelContext.
• Real UI events make for impressive demos. Dispatch the same click you would as a user, not a bespoke backend call.

If you’re deciding interface shape, this short piece on WebMCP vs traditional APIs explains when a JSON‑schema tool at the page is better than adding a new REST route.

What breaks in production

Early wins often stumble on day two for predictable reasons.

• Betting on the wrong runtime

  • A popular agent doesn’t yet call page tools, or needs a hidden flag. Always cross‑check the ecosystem tracker and rehearse on the exact build.

• Missing or weak tool descriptions

  • Agents pick tools by description. If you don’t specify preconditions or side effects, the model guesses. Guesses are flaky.

• No guardrails for sensitive actions

  • Payments, account settings, or deletion without in‑page confirmation is an instant red flag. Add a confirm step and describe the requirement in the tool.

• Returning megabytes of data

  • Large, DOM‑shaped payloads slow agents and provide little value. Return a 1–3 key summary and any IDs or text the agent can reason about.

• DOM coupling and drift

  • A minor class change breaks your selector. Prefer data-* hooks. In production, health checks that suggest updated selectors save hours; Agent Layer does this automatically and lets you roll back a bad config.

• Auth walls and CAPTCHAs

  • Agents run in the user’s session, but login funnels, CAPTCHAs, or bot blockers can still break demos. Keep the demo page public or pre‑authenticated.

• Poor form semantics

  • Unlabelled inputs and unnamed buttons confuse both assistive tech and agents. The free audit (below) flags missing labels, invalid JSON‑LD, robots rules that block crawlers, and more. Fixes help users too.

• Ignoring the old address

  • Some runtimes still look at navigator.modelContext. Feature‑detect both or risk a dead demo.

Where Agent Layer helps (and where you can go without it)

You don’t need Agent Layer to build WebMCP tools. A single script and the code above get you a working demo.

Agent Layer removes the operational work when you move beyond the demo:

• Detects page templates and lets you define tools per template, publish them as versioned configs, and roll back quickly.
• Health checks catch UI drift when selectors move and suggest the new binding.
• Guardrails for sensitive actions are built in; you can enforce confirmation.
• Analytics log every tool call: which agent, success/error, duration.
• Test scenarios let you write intents and check which tool the agent picks.

If you want to see how WebMCP compares to other testing and automation options, read WebMCP vs Playwright MCP.

A lightweight “hackathon pack” you can copy

• One template page with data-* hooks for each UI control you’ll touch.
• Two tools: get_* and a guarded set_*. Both return tiny JSON summaries.
• A single script that registers tools with feature detection, plus an in‑page confirmation helper.
• A rehearsed prompt for your agent runtime (“On this page, add SKU X to the cart, then read the total.”).
• A backup demo path using a second runtime from the “works today” list.
• Optional: add basic console timing and success/error logs inside execute.

Try it

Run the free agent‑readiness audit at Agent Layer. It scans your site, scores it across four pillars, and proposes page‑by‑page WebMCP tools with concrete fixes. Then pick one page, wire two tools, and test against a runtime from the ecosystem tracker. If you want to keep those tools healthy in production—guardrails, analytics, drift fixes, versioned configs—Agent Layer is built for that.