Doceo

The learned capability returns a verified cart update. This screenshot shows the local Tool Lab test interface.
Three deterministic tests verify the demonstrations and no-match rollback before separate UI approval.
Two demonstrations reveal variable inputs and fixed actions, producing a constrained contract.
Teach the web by example: demonstrate, compare, verify, and approve a reusable website tool.

Inspiration

Most websites offer agents only the tools their developers wrote. But users develop useful workflows that were never packaged as tools. That makes us wonder: what if a website could learn a reusable capability from its user, verify what it does, and expose it through WebMCP? Doceo is Latin for “I teach” explores that idea. Its guiding principle is simple: humans demonstrate, agents propose, the website verifies, and lastly humans approve.

What it does

Doceo turns demonstrated workflows into site-native WebMCP tools. The prototype uses Lumen Market, a demo shopping website. A user demonstrates the same shopping task twice with different searches and budget filters. Doceo records the underlying domain actions not screen coordinates or DOM selectors. Then compares the examples to identify what changes and what stays fixed. An agent can then inspect the evidence, propose a structured tool contract, run isolated tests, and request publication. A separate approval step in the interface registers the tested capability as a new WebMCP tool. The resulting find_and_add_product tool accepts new inputs, selects a matching product, and updates the same cart visible to the user. If execution fails its checks, the interpreter restores the previous state. The important transition is not simply from clicks to automation. It is from demonstrated intent to a verified capability on the website’s own tool surface.

How I built it

The application uses React, TypeScript, and Vite, with Zod for runtime contract validation. Doceo exposes four WebMCP meta-tools:

get_workflow_evidence
propose_tool_contract
run_candidate_tests
request_tool_publish These let an agent participate in tool creation before the learned tool exists. Proposed contracts use a constrained intermediate representation backed by five allowlisted domain actions. They cannot introduce arbitrary JavaScript. A deterministic interpreter executes those actions and checks their observable effects. Verification covers the recorded demonstrations and a no-match safety case. Editing a contract invalidates its previous test results, and approval reruns verification against the current evidence. Sessions persist across reloads, evidence and contracts can be exported, and published tools can be revoked. Parallel AI supported project and technical research during development. Graphify supported codebase navigation and persistent project context. Neither is required to execute the demo’s learned tools.

Challenges I ran into

The hardest problem was deciding what the examples actually justify. Two demonstrations can suggest a reusable pattern, but they do not prove a user’s general intent. Doceo therefore keeps its scope narrow, exposes the proposed contract for review, and rejects incompatible demonstrations. Another challenge was separating proposal from publication. The WebMCP publication tool only requests approval; registration happens through a separate interface action after verification. It was also important to distinguish compatibility testing from native integration. A local test harness is useful, but it is not evidence that native WebMCP discovery and invocation work.

Accomplishments that I'm proud of

The prototype completes the full demonstrate --> propose --> verify --> approve --> invoke cycle. Native WebMCP testing confirmed discovery of the four meta-tools, runtime appearance of the approved fifth tool, successful invocation, and removal after revocation. The current automated suite passes 16 unit tests and 9 end-to-end tests, including persistence, contract editing, rollback, responsive layouts, and automated accessibility checks.

What I learned

Recording behavior is easier than establishing a trustworthy contract for repeating it. Stable domain actions, explicit parameters, observable postconditions, and reversible execution matter more than a convincing replay. I also learned that WebMCP can support more than a fixed integration: it can provide the interface through which an agent helps a website construct and validate a new capability.

What's next for Doceo

The next steps are a public deployment, a reproducible demo, and evaluation with additional users and workflows. I also want to add clarification questions when demonstrations are ambiguous and compare agent-assisted execution against UI-only execution using measured success rates, latency, and token usage. The current prototype is intentionally limited to an instrumented shopping website. It does not claim to learn arbitrary workflows on arbitrary websites. The longer-term goal is a reusable teaching layer that other websites can adopt while retaining control over their actions, verification rules, and publication decisions.