ToolForge

Inspiration

WebMCP gives websites a structured language for working with agents, replacing fragile visual guesswork with explicit tools. But the adoption challenge extends far beyond any single website or industry: every developer must still inspect their interface, identify meaningful actions, define schemas, make authorization decisions, and connect custom controls to real application behavior. ToolForge addresses that broader infrastructure gap. Rather than building another WebMCP-enabled storefront, we created a reusable, cross-functional developer tool that can audit many kinds of websites ranging from ecommerce and marketplaces to games, productivity tools and financial applications. It recognizes semantic forms, custom actions, composite workflows and uncertain elements, then converts them into evidence-backed candidates for developer review. ToolForge does not blindly expose everything clickable or pretend that business intent can be inferred from the DOM. It accelerates the repeatable parts of WebMCP adoption while preserving human control over meaning, safety and execution. The storefront is simply our end-to-end proof; the product itself is a general bridge between today’s websites and an agent-ready open web.

What it does

ToolForge is an injectable, development-mode readiness inspector for existing websites. It scans the live DOM including open Shadow DOM roots and accessible same-origin frames and organizes interactions into five groups:

• Declarative-ready native forms
• Form-like interactions
• Composite workflows
• High-confidence imperative actions
• Ignored or low-confidence elements

For native forms, ToolForge drafts toolname, tooldescription, and toolparamdescription attributes from the page's existing labels and structure. The developer reviews every value, decides whether to enable toolautosubmit, applies the attributes to the live DOM for immediate testing, and can copy a minimal stable-ID attribute diff back to source.

For custom JavaScript controls, ToolForge drafts metadata and a JSON schema but refuses to present the tool as complete until the developer provides a real function reference or execute body. Related controls such as separate price chips, region controls, and an “All filters” button can be grouped into one composite workflow instead of becoming dozens of tiny tools.

Low-confidence elements are not silently discarded. Developers can search the ignored queue, inspect structural evidence, highlight the real page element, keep it ignored, promote it for review, or re-evaluate it after the page changes. Manual decisions persist across rescans for the current session.

The repository includes a complete storefront that proves the result end to end. It exposes:

• search_products through the imperative WebMCP API
• add_to_cart through a declarative form with developer-approved autosubmit
• checkout through a declarative form without autosubmit, preserving human confirmation

How we built it

ToolForge is a static, dependency-free application built with semantic HTML, CSS, and vanilla JavaScript. It has no backend, framework, build step, runtime model call, or page-data upload.

The finished storefront and the unannotated demo target share the same product rendering, cart state, and human interface logic. This creates an honest before-and-after comparison: demo-target.html contains no WebMCP surface, while index.html contains the reviewed declarative attributes and loads the imperative implementation from webmcp.js.

The declarative tools reuse the forms' existing submit handlers. The imperative search_products tool uses document.modelContext.registerTool() and calls the same search function as the human interface. ToolForge's panel is isolated in Shadow DOM, observes dynamic page changes with a MutationObserver, records evidence for each classification, and gates every imperative export on a real developer-supplied handler.

Automated Chrome DevTools Protocol tests cover tool discovery, execution policy, native forms, form-like controls, composite workflows, ignored-element review, dynamic content, open Shadow DOM, same-origin frames, duplicate collapsing, stable rescans, and the imperative export gate.

Challenges we ran into

The hardest challenge was staying honest about what the DOM can and cannot reveal. HTML can provide parameter structure, but it cannot reliably reveal private JavaScript behavior, business meaning, or authorization policy. ToolForge therefore does not invent handlers or automatically decide which actions are safe.

Modern commerce pages presented another challenge because filters are often implemented as many independent buttons rather than native forms. Treating every chip as its own tool created noisy and misleading results. We added structural composite-workflow detection so related price and region controls become a single filter_listings candidate while product-card actions remain separate.

We also had to balance filtering with developer control. A large ignored count was technically accurate but difficult to audit, so the ignored set became a searchable review queue with evidence, highlighting, promotion, persistent decisions, and re-evaluation.

Accomplishments that we're proud of

• A working, polished storefront with three real WebMCP tools across both declarative and imperative APIs
• A clear safety demonstration: reversible add-to-cart can autosubmit, while checkout requires human confirmation
• A deterministic readiness inspector that works without AI inference or a backend
• Five evidence-backed readiness categories instead of an inflated list of clickable elements
• Composite workflow detection that groups related filters into a usable schema
• A fully reviewable ignored queue instead of silently discarding uncertain controls
• Automated browser regression coverage for the scanner and WebMCP execution policy
• Mobile Lighthouse scores of 100 for Performance, Accessibility, Best Practices, and SEO

What we learned

Semantic HTML is already a strong bridge to agent-ready interfaces: a real form provides useful parameter structure and an existing execution path. The harder problems are meaning, authorization, and developer intent. Those cannot be responsibly inferred from labels alone.

We also learned that WebMCP adoption tools should optimize for inspectability rather than maximum candidate counts. A smaller set of coherent, evidence-backed workflows is more useful than dozens of technically clickable but context-free actions.

What's next for ToolForge

Next steps include packaging the inspector as a browser extension, adding source-aware adapters that can produce framework-specific patches, supporting richer developer-defined workflow grouping.

Built With

• chrome
• chrome-devtools-protocol
• css3
• github
• html5
• javascript
• json-schema
• model-context-tool-inspector
• mutationobserver
• shadow-dom
• vercel
• webmcp