Inspiration
The web already contains useful capabilities, but AI agents usually have to infer those capabilities from page structure, prose, and UI controls. That is brittle, wasteful, and difficult to verify.
The Interdependency already maintains skill-lib: a public library of structured agent skills with canonical sources, dependency information, boundaries, usage guidance, and validation tooling. WebMCP provides the missing browser-native boundary: a website can expose explicit tools to an agent instead of requiring the agent to guess how the site works.
What it does
The Interdependency WebMCP gives agents structured access to capabilities exposed by The Interdependency website while preserving the same website for human use.
The initial WebMCP surface operates on the skill registry, with operations such as:
- discover available skills
- find skills relevant to a task
- inspect a skill
- resolve dependencies and prerequisite closure
- retrieve boundaries and usage guidance
- expose the smallest relevant capability set for the current task
The WebMCP implementation belongs to the website that exposes those capabilities. The reusable webmcp skill belongs separately in skill-lib, where it teaches agents how to construct, validate, and maintain a WebMCP surface.
This keeps implementation ownership and procedural knowledge distinct while sharing one canonical source of truth.
How we built it
The existing website is an Eleventy/Node knowledge system backed by public GitHub repositories.
During the WebMCP Challenge we are extending that existing site with browser-native WebMCP tools using document.modelContext.registerTool(...).
The architecture is:
canonical skill sources → registry → website capability layer → WebMCP tools → agent
Human-facing pages and agent-facing tools therefore derive from the same underlying information rather than becoming separate, drifting interfaces.
Challenges
The principal design problem was deciding where WebMCP belongs.
Putting the WebMCP runtime inside skill-lib would make the skill library responsible for another application's runtime. Making every skill itself a WebMCP function would incorrectly collapse procedural knowledge into executable operations.
The resulting separation is:
- the website owns the WebMCP runtime and registered tools
skill-libowns the reusable WebMCP setup and validation skill- canonical skills remain authoritative knowledge objects
- WebMCP exposes operations over those objects ## What I'm most proud of
I'm most proud of msdmd — Module Self-Declared Metadata Markdown.
It started from a simple problem: documentation, capability maps, dependency graphs, ownership records, tests, and agent instructions all tend to drift away from the code they describe.
msdmd reverses that relationship. A module declares structured metadata about itself, close to the source that gives those declarations meaning. Other surfaces are then derived and checked from those declarations rather than maintained independently.
That idea became the foundation of skill-lib: documentation coverage, capability inventories, dependency topology, ownership, contracts, boundaries, generated agent instructions, and other tools all build from the same underlying convention.
What I'm proud of is not the syntax itself. It is the architectural consequence:
one source can describe itself well enough that humans, tests, documentation systems, and agents can all derive useful views without creating competing truths.
WebMCP extends that same idea into the browser: instead of an agent guessing what a website can do, the site can declare its capabilities directly.
What we learned
WebMCP is most useful when it is not simply an alternate way to click buttons.
Its stronger role is to make a web application's actual capability model explicit to agents. That reduces interface guessing, unnecessary context consumption, and divergence between what humans can see and what agents can reliably do.
For a structured skill registry, this also makes selective disclosure possible: an agent can receive the smallest relevant capability closure instead of loading an entire library into context.
What's next
The immediate goal is a small, fully tested WebMCP surface over the skill registry.
After that, the same pattern can extend to other parts of The Interdependency website while preserving explicit boundaries, provenance, validation, and human control.
hmmm — the interesting boundary is not whether every website should expose more tools, but whether it can expose exactly the capabilities it actually owns, no more and no less.
Log in or sign up for Devpost to join the conversation.