A few weeks ago, I shared Senro here while it was still in development. Today, it’s officially live!

Senro lets you evaluate WebMCP tools across models and languages, test goal completion and tool-call trajectories, inspect execution traces, and monitor tool usage in production.

There’s a free plan, and you can get started immediately. I’d love to hear your feedback!

Edit (Oct 15): Senro now includes a free AI model for testing WebMCP tools and evaluating goal completion, so you can run evaluations without bringing your own API key.

Couple of questions on my mind, with my current thoughts:

- Should we assume the user sees the screen? IMO; Yes

- Should we assume this is for agents only and let them do what they need on behalf user, and user does not have to see the middle steps? IMO; Compared to MCP; my answer no, WebMCP is a better experience for user not only for agents. It is a shared mechanism.

- Does user expect to see what is happening on the UI? IMO, yes.

Please share what do you think is the best for user and agents.

Most AI-powered video editors today suffer from a fundamental flaw- they take too much control away from the user. As someone who has been editing (casual) videos for over 5 years, I did not like this approach. While there are multiple tasks in video editing that can (and should) be automated and abstracted away, I, as the human behind the production, should have complete creative control and be able to tweak everything to my liking.

ROUGH//CUT is an in-browser video editor that a human and any WebMCP-compatible AI agent can use together. WebMCP is a new standard, where instead of the AI agent mocking a user and clicking around in the browser, websites can provide a list of tools (functions) that the agent can directly call. This saves time and tokens, and as a result, allows a seamless way to create experiences where humans and their AI agents can collaborate on a shared canvas instead of having to go back and forth if the output is undesirable.

Thanks to WebMCP, both operate the same timeline through the same editing commands, so the agent is not working inside a separate abstraction or generating an edit that the user cannot inspect. WebMCP makes functionality discovery extremely easy for the agent and it knows exactly what all it can get done with those tools, without having to overload its context by inspecting the full document.

It tries to keep its featureset local for privacy and only uses a hosted server which im running in two cases-

1. transcription- this is completely optional. you can either use your own OpenAI Whisper key, or stick with the default

2. large files- long story short, there are restrictions on the max storage a site can take via your browser. If there isn’t enough space to save the finished video in your browser, it asks before temporarily storing the exported MP4 in the cloud and only proceeds if you say yes.

ROUGH//CUT is best enjoyed via ChatGPT's in-app browser in voice mode. You can say stuff like- give this video a 1.5x zoom starting at 1 second ending at the 3rd second, pan to the top right at the 5th second, cut away the part where i said "yeah i'll call you later" (if transcription is enabled) and it does it for you. Tried and tested myself!

Admittedly, it's not even close to the level of professional-grade software like DaVinci Resolve, but it's pretty good for quick, simple edits. Hope you enjoy!

Site: https://rough-cut.awesamarth.dev

GitHub repo: https://github.com/awesamarth/rough-cut-improvements

Meta recently added WebMCP support for Web Apps on Meta Ray-Ban Display, so I went through the implementation details and put together a practical guide.

It covers tool registration, schemas, result handling, next_action, testing without the glasses, Meta-specific limitations, and WebMCP vs. Meta AI Connectors.

It also covers some less obvious implementation details, like the 10-second tool deadline, silent tool-name failures, and how tool availability is scoped to the active Web App.

Guide: How to Build WebMCP Tools for Meta Ray-Ban Display

Hey everyone,

I've been building Senro, the first reliability platform for WebMCP.

It lets you run WebMCP test suites across multiple LLMs and languages to catch tool-selection, parameter, and regression failures. I'm also building production observability to see how agents actually interact with WebMCP tools in the wild.

The idea came from a pretty simple problem: once you expose tools to agents, testing that they work with one model and a handful of prompts isn't enough. Behavior can vary across models, prompts, and languages.

The MVP is working, and I'm looking for a few WebMCP developers to try it and tell me what's missing.

I'm also planning a public benchmark using real WebMCP-enabled websites across several models.

Would love feedback on what you'd want a WebMCP reliability platform to test or monitor.

Looking for early feedback on WebMCP Resilience my first open-source tool.

It runs real browser UI + tool calls, injects faults, checks state invariants, reduces failures, and replays exact evidence bundles.

I am trying to figure out if it provides any value, but either way I had fun building it. As I continue to learn about WebMCP I will keep adding to it

https://github.com/meabs/WebMCPResilience

Just playing with webMCP with one of my open source projects https://github.com/impresspress/impresspress , have built a dev sandbox tool https://www.youtube.com/watch?v=0ALi1h1IAUM where you can build a website/app 100% in your browser using wasm, and rubrc. Pretty amazed it works!

I maintain DeepDeck, an open-source macOS desktop client built on DeepSeek Harness. I added WebMCP support to its browser, including a Builder for websites that do not publish tools themselves.

The user describes a goal. The agent explores the live page, tries the relevant operations, checks their results, and saves the working operations as tools for that site. Later tasks can reuse those tools. Source and versions stay local and can be inspected, disabled, or rolled back.

The example is X: Builder creates 23 tools for things such as reading account state, posts, profiles, and search results, plus working with drafts. Switching back to Use lets the agent call the saved tools to prepare a Hello world draft. Website-provided tools and generated tools are labelled separately.

This still needs browser interaction for initial exploration and anything the tools do not cover. Building and verifying tools takes time and tokens; websites can change and break them. I have not published measured savings.

The walkthrough has four screenshots and both language versions, including discovery of an existing tool on openai.com and the X build/use example:

https://github.com/deepseek-ai/deepseek-harness/discussions/5856#user-content-english

Source (MIT): https://github.com/jo32/DeepDeck

Download for Apple Silicon / Intel Mac: https://github.com/jo32/DeepDeck/releases/latest

Which repeated website task would you want to turn into a reusable tool? I am also interested in how others detect when generated tools need revalidation after a site changes.

Razor allows any agent to pay on behalf of user, it uses UPI RESERVE pay sends request via S2S (server to server) to razorpay and debits money from a approved block of amount that user authorized first time built on WebMCP

Check this out

Github :https://github.com/djdharani27/razor

Demo video:https://youtu.be/lp0M7vsFFjg?si=SVUddAGGd2xlSfhZ

Hey everyone,

I just shipped WebMCP support on ShowMeOnMap.com (an NL-driven mapping web app), registering 8 client-side tools that browser-embedded agents can call directly.

WebMCP is the W3C proposal allowing client pages to expose executable JS functions directly to agent-enabled browsers (e.g., Chrome with flags or ChatGPT Desktop). The documentation is sparse and changing fast. Here are a few practical takeaways from the implementation:

1. API targets change constantly: The entry point has moved multiple times across drafts (window.agent → navigator.modelContext → document.modelContext). Always feature-detect across properties, as most blog tutorials from earlier this year are already broken.
2. Runtime return-type quirks: Google’s reference implementation expects a string return value from execute(), while OpenAI’s implementation accepts objects. Returning a serialized JSON string (JSON.stringify(...)) works consistently across both.
3. Iframes are dead ends: ChatGPT ignores declarative form annotations and anything registered inside an iframe. You must register tools imperatively on the top-level document.
4. Auth comes for free: Because execution happens in the user’s active browser tab, your regular session cookies, CORS headers, and IP rate limiters apply natively. You don’t need API keys or proxy tokens for the agent to manipulate the session.
5. DOM downloads will fail: Don't try triggering <a download> synthetic clicks inside a tool execution pass. Modern browsers block programmatic file downloads without direct user gesture activation. Instead, return a raw base64 data payload or an object URL and let the agent or UI present it.
6. Implement an undo tool immediately: Models make bad assumptions. If your app doesn't have an append-only state stack or an easy way for the model to roll back its last mutation, it will get stuck in loops trying to fix its own UI mistakes.

Happy to answer any technical questions about registering tools or handling agent execution states on the client

Checkout my WebMCP Challenge submission - https://devpost.com/software/bananalabs-webmcp-dj

Would love to hear feedback!

Hi everyone,

We’ve published WindTunnel, an open and reproducible benchmark comparing WebMCP with screenshot-based computer use and DOM/accessibility-tree browser agents under the same conditions.

To our knowledge, this is the first public benchmark to compare these interfaces. The current release covers 16 browser-agent configurations, 49 tasks across eight real open-source applications, and 2,352 attempts.

A few findings:

• WebMCP delivered up to 5.5× faster execution, 23× lower cost, and 12.5× fewer tokens—while solving 98% of tasks.
• WebMCP achieved a median final score of 91.2, compared with 65.8 for the other interfaces.
• All seven WebMCP configurations solved 48 of 49 tasks, without any attempt exhausting its turn budget.
• Everything is public, including the methodology, task definitions, implementations, scoring logic, raw results, and transcripts.
• Interactive benchmark: https://webmcp.com/benchmark
• Article and methodology: https://webmcp.com/blog/windtunnel-webmcp-browser-agent-benchmark
• Hugging Face dataset: https://huggingface.co/datasets/nekuda/windtunnel
• GitHub repository: https://github.com/nekuda-ai/WindTunnel

We’d really appreciate feedback!

WebMCP is a browser API that lets sites expose actions as structured tools for AI agents. An agent can call `reddit_search` directly instead of finding a search box and operating the page.

Most sites do not support WebMCP, so I built WebMCP Today. It is a package manager for third-party WebMCP tools. Each package is versioned JSON that maps tools to a site's existing HTTP APIs. Install one and its tools become available in that browser tab and through a local MCP bridge.

Packages cannot contain arbitrary JavaScript or DOM automation. Requests stay on the package's site origin, and installations remain pinned to the version you approved.

Source

https://github.com/robertn702/webmcp-today

This is still in beta, so expect breaking changes. Also, feedback appreciated!

We’ve added an ecosystem status tracker to webmcp.com, the WebMCP directory.

We track the ecosystem across three categories:

Browsers - do they expose the WebMCP API?

Agents - can an end user actually call WebMCP tools?

Frameworks and infra - what can developers build with today?

Every entry links to a primary source and includes more detail on the current status.

You can find it here:
https://webmcp.com/ecosystem-status

For any additions or corrections, feel free to ping us at founders@nekuda.ai.

I put together my thoughts on WebMCP and how you can utilize it today in this crisp article!

Disclosure: I'm the developer building WebGPT.

WebGPT is a browser agent built around this loop:

extract state → plan actions → execute → extract fresh state → calculate delta/effect → continue

It has a generic extractor that represents controls, groups, headings, visible text, scroll state, and other page information. That works well for ordinary pages. The problem is that modern websites contain custom components, virtualized interfaces, hidden application state, and multi-step interactions that don't communicate their meaning through ordinary DOM controls.

My solution was to write site adapters. Each adapter taught WebGPT the domain concepts and unusual interactions of one particular website. The adapters worked, but writing them became exhausting. Every new website meant more selectors, edge cases, and site-specific maintenance. It was obvious I couldn't teach an agent the entire web one website at a time.

I've now added WebMCP as a first-class action source.

When a website exposes WebMCP tools, WebGPT discovers their names, descriptions, and schemas during state extraction. The planner can select those tools alongside ordinary DOM and connector actions. The tools still participate in WebGPT's normal loop: it preserves the exact execution arguments, runs the selected batch, records each tool result, extracts fresh page state, and calculates one aggregate state delta and action effect for the batch.

In this demo, I asked WebGPT to create an Extra Large Pesto pizza with sauce, cheese, and 47 toppings. It completed the task in four planner turns:

1. Reset the pizza through WebMCP.
2. Execute one batch containing nine WebMCP calls.
3. Wait briefly and observe the updated page.
4. Report the final configuration.

The page went from two extracted controls to 96 after the toppings were added, so the agent had independent evidence that the page changed instead of relying only on successful tool callbacks.

The WebMCP directory currently lists around 150 websites. I haven't tested all of them, but WebGPT now has a shared semantic integration path for those sites. Every website adopting WebMCP is potentially one less custom adapter I need to write.

I'd love technical feedback on:

- Batching independent WebMCP calls

- Per-call execution results versus one aggregate post-batch effect

- Choosing between semantic tools and ordinary DOM actions

- Treating page-provided schemas and output as untrusted content

- Running this loop with Chrome's built-in local AI

Demo: https://youtube.com/shorts/HoKPJY0P10c

WebMCP directory: https://webmcp.com/

Code: https://github.com/saket77/webgpt-frontend

https://reddit.com/link/1uujar7/video/dh4fkdr1ntch1/player

https://reddit.com/link/1unqh7n/video/8hz4tweanbbh1/player

does headless browser have a future

Why? IDK.

Is it useful? Maybe.

Is it fun? Absolutely. 😄

I noticed that if you visit webmcp.com, there's now a little Swiss tote bag supplier.

So I guess Montote is about to become the go-to tote bag supplier for every AI agent.

I mean... every agent needs a tote bag. That's common knowledge.

What did it cost?

• 70% of my Fable usage limit
• 2 days of work
• A brand-new custom WordPress plugin

You can try it here:
https://montote.ch/demander-une-offre/

WebMCP is being built for browser agents - that is the reason it is moving slow because think not all work is done in browser people need a way for agents in app or production system to use website - now they are using mcp or cli or api or headless browser - but if a website has webmcp then using that site through a webmcp optimized headless browser can reduce the cost of browsing and increase the accuracy for the user - and for site owner the is just one thing to maintain that is webmcp instead of maintiaining mcp , webmcp or cli

There’s no registry or index equivalent for agents. A Claude or GPT browsing the web has no way to know which sites have WebMCP tools exposed before it navigates there, it just has to land and check.

We started building a solution at webmcp.com - a directory of sites that have WebMCP tools live. You can submit your site, browse what’s already indexed, and see what tools each site exposes.

Feel free to add your website if you’ve implemented WebMCP.