WebMCP Foundry
Agents propose. Evidence qualifies. Authority promotes.
WebMCP makes it possible for websites to expose structured tools to AI agents. But exposing a function does not answer a harder question:
Which actions have actually earned the right to become agent-callable tools?
WebMCP Foundry is a capability compiler and verification workbench for the agent-native web. It takes actions that already exist in a human-facing web application and turns them into minimized, tested, effect-aware, evidence-backed, authority-governed WebMCP capabilities.
Instead of treating registerTool() as the beginning of the process, Foundry treats native WebMCP registration as the output of an engineering lifecycle:
human action → candidate → contract → minimized inputs → effects + authority → verification → evidence → promotion → LIVE WebMCP tool
If the underlying implementation changes, its old evidence no longer silently remains valid. Foundry marks the affected capability STALE and withdraws it from the browser's native WebMCP registry until fresh evidence qualifies it again.
What it does
The demo uses Ledgerly, an ordinary human-facing financial web application.
Foundry discovers actions such as transaction search, notes, balance adjustments, fund transfers, and account deletion. It then determines what part of each action should actually be agent-controlled.
For example, an initially over-broad action with four controllable fields is reduced to only two agent-visible inputs, while trusted session and identity state remain application-controlled.
Foundry then verifies proposed capabilities using explicit contracts, observed effects, negative tests, and deliberately incorrect must-kill mutants. A check only contributes evidence if it can reject its assigned known-bad implementation.
The demo shows the complete lifecycle:
- Discover actions from the human application.
- Minimize an over-broad interface from 4 inputs to 2 agent-controlled inputs.
- Find a concrete counterexample in an incorrect implementation.
- Block promotion because the evidence is FAIL.
- Repair the implementation and obtain fresh evidence.
- Refuse an agent's attempt to self-promote a consequential financial capability.
- Allow an appropriately authorized human to promote it.
- Register it through native
document.modelContext. - Execute the capability through the browser's native WebMCP tool registry.
- Change the underlying source, causing LIVE → STALE and automatic native tool withdrawal.
The browser registry and Foundry state are continuously reconciled:
LIVE ⇔ present in document.modelContext.getTools()
Everything else — CANDIDATE, VERIFIED-but-unpromoted, BLOCKED, STALE or WITHDRAWN — must remain absent.
Why WebMCP
Without WebMCP, Foundry would only be a verifier describing which actions could be safe agent tools.
WebMCP makes the final step real.
A capability that passes Foundry's gates becomes an actual browser-native tool. When its evidence becomes stale, Foundry aborts its registration and the tool actually disappears from the agent's available interface.
That closes the loop between software assurance and the browser's agent surface.
How we built it
Almost the entire authoritative system is implemented in dependency-free Julia using only the standard library.
Julia owns:
- capability and effect models
- authority policy
- contract minimization
- verification
- mutation testing
- deterministic gates
- stale-dependency analysis
- the hash-chained evidence ledger
- HTTP serving
- JSON handling
- the demo application
- the Foundry UI
- native-host acceptance grading
JavaScript is intentionally limited to the browser boundary where WebMCP exists. A small bridge projects Foundry's LIVE manifest onto document.modelContext, maintains one AbortController per tool, reconciles getTools(), and reports native browser observations back to the authoritative Julia system.
The development polyfill is explicitly separated from native WebMCP and cannot satisfy Foundry's native acceptance gate.
Challenges
One of the biggest challenges was avoiding a verifier that simply agreed with itself.
We addressed this with external observations, explicit non-PASS verdicts, counterexamples, and must-kill mutants. UNKNOWN, UNGRADABLE and BLOCKED cannot silently become PASS.
Another challenge was the experimental nature of WebMCP itself. During native testing we found that our Edge build exposed the expected document.modelContext API but differed from the current WebIDL expectation for one executeTool() input form. Foundry records that disagreement rather than hiding it.
Deployment was another practical challenge. The public entry point now monitors the live Foundry and Ledgerly services and redirects judges to their current HTTPS origins.
Accomplishments we're proud of
- A working native WebMCP lifecycle rather than a simulated tool registry.
- LIVE → STALE → native withdrawal driven by real dependency changes.
- Agent self-ratification of consequential capabilities is refused.
- Trusted/session-bound fields cannot be forged through the agent contract.
- Verification checks must demonstrate that they can reject known-bad controls.
- A replayable, hash-chained evidence and promotion ledger.
- A dependency-free Julia authority kernel with only a minimal JavaScript WebMCP boundary.
- Native WebMCP acceptance tested against the deployed application.
What we learned
WebMCP makes exposing tools easy. The difficult engineering problem begins one level earlier:
What should be exposed, under what contract, backed by what evidence, and for how long does that evidence remain valid?
We found it useful to treat an application's agent interface as a derived software artifact rather than a static list of callable functions.
What's next
The next step is to generalize Foundry beyond the Ledgerly demonstration: richer application adapters, CI integration, additional capability-effect models, and standards-backed normative provenance.
The longer-term idea is for WebMCP to be one compilation target of a protocol-independent capability IR.
WebMCP lets websites expose tools to agents. WebMCP Foundry asks why each tool is allowed to exist.
Log in or sign up for Devpost to join the conversation.