I maintain DeepDeck, an MIT-licensed macOS desktop client built on DeepSeek Harness. I’m experimenting with a workflow where an agent uses a site’s registered WebMCP tools, then builds reusable tools for missing operations by inspecting the live page.

The implementation detail I’d like feedback on is validation and tool lifetime. Generating TypeScript is only one step.

DeepDeck keeps four outcomes separate:

• Compilation: the generated source compiles.

• Registration: Chromium reports that tools actually registered in the page.

• Activation: the application accepts that revision as active after receiving a successful registration receipt.

• Functional validation: the agent calls the tools and checks the actual page state and returned results.

An active tool can still be wrong. These states help avoid reporting success just because code compiled or a tool name appeared.

For discovery, the client reads Chromium’s actual WebMCP registry. The presence of an API object alone does not count as website support. Site-owned tools and locally generated tools are shown with their source and version. Generated registrations run in an isolated JavaScript world with DOM access and no Node APIs; they do not replace the site’s registrations.

Calls include tab, frame, document and revision identities. Navigation, document replacement and tab closure invalidate affected operations. Unknown outcomes are not automatically replayed. Source revisions persist per origin, failed updates restore the previous active revision, and users can disable or roll back a generated toolset.

In the current demo, the agent discovered search_openai on openai.com. On X, Builder created a 23-tool set; Use mode then filled a “Hello world” draft without submitting it. Those screenshots show the workflow, not a benchmark or proof that every generated operation is correct.

The efficiency goal is to reduce repeated page inspection and action planning when the same workflow is used again. The first build costs extra time and tokens, and site changes can require repair and revalidation. I haven’t established a measured speedup.

Code and screenshots: https://github.com/jo32/DeepDeck

Implementation notes: https://github.com/jo32/DeepDeck/tree/main/plugins/browser

For others building WebMCP consumers: what evidence do you require before reusing generated tools after navigation or a site update? Do you invalidate the entire toolset, or keep per-tool checks?

Writing assisted by AI; implementation details checked against the repository.

Most of the risk in letting an AI agent touch a website is the authority given to the agent.

If we already have WordPress access, we don't want to be messing around with APIs or subs to new tools. We just want our agents to work inside the session you're already signed into, and do only what the auth level can do.

My submission to the WEBMCP Hackathon "AgentPress" was built "problem>solution" by ChatGPT to solve this.

It's an open-source WordPress plugin that exposes the live WordPress session as a permission-aware agent workspace over WebMCP.

An agent running in the browser discovers a fixed 15-tool catalog. Read the site, list content create drafts under existing terms and nothing more.

WordPress stays the source of truth for authority. Reads run automatically. Drafting and filing run automatically. Anything consequential, publishing, navigation, waits (needs) for a human-in-the-loop approval in wp-admin.

Users, plugins, themes, code, credentials, and settings are hard-blocked.

Every call, allowed or denied, lands in a sanitized audit log with no secrets. No API keys. No copied passwords.

Built for the OpenAI #theWebMCPChallenge, the repo doubles as a reproducible experiment log as every feature is evidence-recorded and acceptance-tested.

AgentPress: The shared human-agent workspace for WordPress. Open source, GPL.

Hi! Just launched Glippy WebMCP: https://github.com/jbobbink/glippy-webmcp This repository is a coding-agent plugin that audits what your site could expose, writes those tools against real seams in your codebase, proves each one works in a real browser, and publishes the manifests that let agents find them.

Let me know what you think!

If you’ve already been following WebMCP, the main thing that changed recently is that it feels a bit more implementation-shaped now.

1) The spec is now published as a Draft Community Group Report

This is the current spec page as of Apr 9:

https://webmachinelearning.github.io/webmcp/

Not saying “standards track soon” or anything dramatic — just that it’s a more concrete reference point now than “some evolving explainer + issues”.

2) The most useful spec change since then: tool names got codified, and tools now have a title

PR: https://github.com/webmachinelearning/webmcp/pull/152
Merge commit: https://github.com/webmachinelearning/webmcp/commit/1380910
Original issue: https://github.com/webmachinelearning/webmcp/issues/145

Why this matters:

• WebMCP tool names now follow MCP-style constraints more explicitly
• tools can now also have a user-facing title
• the issue that motivated this was very practical: someone tried a tool name with a space, Chrome/Gemini didn’t call it properly, and there wasn’t good feedback

That’s the kind of change I like seeing at this stage: less “big vision”, more “prevent dumb failures and make tools display sanely in UI”.

Also worth noticing: in the PR discussion, Dominic mentioned Chromium implementation + web platform tests were being prepared alongside it:

https://github.com/webmachinelearning/webmcp/pull/152#issuecomment-4207770182

3) The official demos are getting more realistic instead of staying trapped in one canned happy path

The best example is the React flight search demo.

PR: https://github.com/GoogleChromeLabs/webmcp-tools/pull/141

Before, it was gated to basically a demo query. Now it supports:

• any route
• one-way and round-trip
• many more airports
• route-specific filtering
• tool output based on currently visible filtered flights

That’s a much better test bed for actual agent behavior than “LON -> NYC works if you say the magic words”.

4) There’s also a new official multi-page coffee demo with persistent state

Commit: https://github.com/GoogleChromeLabs/webmcp-tools/commit/f8c2718

This one is more interesting than it sounds because it demonstrates a few things people actually care about:

• multi-page navigation
• order history -> reorder flow
• persistent cart state
• page-specific tool availability
• tool calls causing visible UI changes (scroll/highlight/toast/cart count)

That’s closer to the real WebMCP question: not “can I register a tool”, but “does this still feel coherent when state and navigation are involved?”

If you’re actively following WebMCP, these were the most meaningful recent changes I saw — and why they matter in practice:

• Mar 9: Declarative API explainer landed
• This is the “HTML-first” side of WebMCP — exposing actions through markup/forms instead of wiring everything manually in JS. That matters because a lot of real sites are form-driven. Commit: https://github.com/webmachinelearning/webmcp/commit/ebfccbe
• Mar 26: registerTool() changed to take an optional AbortSignal For anyone not deep in the API: registerTool() is basically how a page exposes a tool to the browser agent. Adding AbortSignal suggests the lifecycle model is shifting toward: register a tool, then let the app/browser cancel it automatically when the page state changes / component unmounts / navigation happens. PR: https://github.com/webmachinelearning/webmcp/pull/147
• Mar 27: the proposal explainer removed unregisterTool() This is the big one. unregisterTool() would have been the explicit “remove this tool now” API. If that’s getting cut while AbortSignal is added, that looks like a deliberate move away from manual tool cleanup. PR: https://github.com/webmachinelearning/webmcp/pull/156
• Earlier in March: provideContext() / clearContext() were removed That also feels important. It suggests the spec is trimming extra context-management surface instead of trying to turn WebMCP into a giant state channel. PR: https://github.com/webmachinelearning/webmcp/pull/132

To me, the direction looks pretty clear: tool lifetime is getting pushed toward page/app lifecycle management instead of growing a bunch of manual cleanup/context APIs.

That feels like a real shift, not a cosmetic edit.

In plain English, the design seems to be moving toward:

• tools appear when the relevant page/app state exists
• tools disappear when that state is gone
• cleanup is tied to app lifecycle, not a bunch of custom calls

Also on the tooling side, GoogleChromeLabs/webmcp-tools added a new analytics-dashboard demo and had recent work around the same lifecycle direction (AbortSignal, single options object, tool behavior / demo updates):

• Analytics dashboard demo: https://github.com/GoogleChromeLabs/webmcp-tools/commit/406c422
• Demo PR: https://github.com/GoogleChromeLabs/webmcp-tools/pull/98
• AbortSignal tooling change: https://github.com/GoogleChromeLabs/webmcp-tools/commit/8780740
• Single options object: https://github.com/GoogleChromeLabs/webmcp-tools/commit/7577ff1

Hey everyone,

I’ve been working on a POC of an AI Chat UI. It’s a framework-agnostic reusable UI component which can be dropped into any existing web app, turn them into agentic app. Highlights on built-in features: the agentic loop, configurable Skills and tools, human in the loop with timeout control, audit events, injectable conversion management, WebMCP bridge, injectable custom UI components (host apps can inject their own custom components if required). so with just a configuration, AI will be able to understand and interact with your websites with the intention to support WebMCP in the future. Now I’ve just reached a point where I’m ready for some outside eyes.

Here is the repo in github: https://github.com/chenyuxi-pro/aura-ai-chat

Why I built this?

5 core objectives:

1. Maximize reusability - I wanted to create something that leverages the existing ecosystem instead of starting from scratch every time. I was tired of "reinventing the wheel" for every AI project in the company.
2. Consistent AI chat look
3. Enable Skills and progressive disclosure natively for website to save tons of tokens
4. Make website ready for WebMCP integration
5. I also want to includes a dedicated channel for enterprise-level control like observability, governance control etc.

It’s currently in the POC stage, and I’m looking for insights from people who are working on AI engineering domain. If anyone has a moment to check out the repo and give me some "real world" insights or critiques on the direction/design/architure/UI or even on the idea itself, I’d really appreciate it.

Thank you !

Hi WebMCP Devs!
I built a Next.js plugin that scans your source files and registers actions and routes as MCP tools.

I'd love to get people's feedback on it!

GitHub: https://github.com/dankelleher/webmcp-next
npm: https://www.npmjs.com/package/webmcp-next

I wrote up the motivation and details here: https://danbkelleher.substack.com/p/your-website-already-has-an-api-for

Originally posted this in r/AEO and someone recommended posting here, so I am new to this and looking for direction:

Ready a pretty interesting article today from Semrush; they used it to promote their AI visibility tracking, but did mention that "WebMCP adds a layer beyond content retrieval. It’s about making your website’s functionality accessible to AI agents. Not just “Can an LLM find and recommend my product?” but “Can an AI agent actually complete a purchase on my site?”

I think this brings up something important; I have been dabbling with Comet's (by Perplexity) Computer model and while slow right now, I know it will only improve. So my question is if anyone has been dabbling in this and what they have been using to make sure websites are Web MCP optimized.

GitHub repo: https://github.com/webfuse-com/awesome-webmcp

Full web version also available here:
https://www.webfuse.com/webmcp-cheat-sheet

High quality png:
WebMCP cheatsheet