Developer Relations Engineer for Chrome and the Web at @Google, technology addict.

London, England
I asking Kasper questions about Jev and WebMCP in a meeting, but decided to do it in a livestream instead, because why not? Join our conversation and ask your own questions too, tomorrow Sep 25th at 5PM CEST / 8 AM PST on twitch.tv/theagenticweb/ #WebMCP #AgenticWeb
I’ve been experimenting with Jev and WebMCP 😁 - Jev selects the next tool and fills enumerable inputs. If the same call needs free text or a number, it falls back to LLM. If that same call also needs free text, a number, or another non-enumerable value, an LLM fills only those remaining fields. What's also interesting is that based on the confidence score given by Jev we can make decisions in harness - if Jev is 97% sure we might trigger the tool - but if the confidence is, let's say, 60% we might want to do additional checks! Evals next? 🤔 1/2 🧵
5
2
16
1,022
🔄 Every software loop needs feedback: design, build, test, launch, and review. When human users hit broken flows on a site, some file support tickets. But when AI agents hit dead ends, they fail silently or apologize in prose. What if we give agents a bug-reporting tool? 🧵👇
Made with AI
9
7
33
8,762
In-band tools also face fundamental architectural limits: • ⏳ Adds synchronous latency to a failing turn • 🔒 Exposes users to prompt-based exfiltration from untrusted sites • 🙈 Cannot report "missed hits" when an agent bypasses an existing tool for DOM scraping
1
4
132
A better path is platform-level out-of-band reporting, modeled on the W3C Reporting API: silent background dispatch, zero conversation latency, and runtime-verified schemas. 📖 Read the full write-up on my blog: bandarra.me/posts/webmcp-fee…
1
6
135
Ha, the WebMCP Maze demo makes a cameo into @kaskulikowski 's latest post!
I’ve been experimenting with Jev and WebMCP 😁 - Jev selects the next tool and fills enumerable inputs. If the same call needs free text or a number, it falls back to LLM. If that same call also needs free text, a number, or another non-enumerable value, an LLM fills only those remaining fields. What's also interesting is that based on the confidence score given by Jev we can make decisions in harness - if Jev is 97% sure we might trigger the tool - but if the confidence is, let's say, 60% we might want to do additional checks! Evals next? 🤔 1/2 🧵
1
11
536
André Bandarra retweeted
Design effective WebMCP tools to help AI agents complete users' workflows→ goo.gle/4ixF7eG Follow our practical framework to map user goals, define application states, and role-play scenarios to support agentic interactions.
15
24
207
14,128
PayPal's early testing of #WebMCP shows end-to-end checkout was twice as fast on average compared to an agent actuating their existing web interface. Full post: developer.paypal.com/communi…
1
8
595
Ah, that's great. My projects are a mix of CLAUDE.md, AGENTS.md, and often both. Will be great to converge into one thing.
We're adding support for AGENTS.md to Claude Code. Starting today in version 2.1.277, if there is no CLAUDE.md in a folder, Claude will check for and use AGENTS.md. You can toggle this behavior in /config.
6
266
André Bandarra retweeted
We just ran Jev on our WebMCP benchmark. The result: basically broke the benchmark. Jev + Mercury 2.5 (a fast, low-cost LLM) using WebMCP solved 100% of the tasks at roughly 112× lower model cost than GPT-6 Astra using computer use with code execution. Compared to Astra using screenshot-based computer use, the model cost was 245× lower (!). We also compared Jev operating the browser with and without WebMCP. We used Browser Use’s open-source Ultrafast, with some improvements to the harness to make it more reliable across the benchmark. Jev’s browser-control accuracy on its own was not amazing - adding WebMCP nearly doubled the number of solved tasks, from 25/49 to 49/49, while reducing model cost by 18% (more on why below). The benchmark and methodology are fully open and reproducible. Full results: webmcp.com/benchmark A few words on how the Jev + WebMCP harness works and why this is exciting: Jev receives text as input and a set of discrete options it can choose from. With WebMCP, those options are the tools exposed by the website. At each step, Jev sees the task, the available tools and previous results, then picks what to do next. The limitation is that Jev can’t generate arbitrary text, which you need for tool arguments. For example, it can choose the search_products tool, but it can’t generate the search query itself. So we split the work: Jev picks the tool and Mercury 2.5 generates the arguments if needed. This works well because turns out most of the cognitive load in these tasks is around choosing the right action. The argument generation itself is relatively simple, so we can delegate to a small and very fast model. We used Mercury, which outputs 1,000+ tokens/sec and is very cheap. The result is a pretty simple combination: Jev for tool selection + Mercury for arguments + WebMCP for the interface. It ends up being very reliable, very fast, and very cheap. A few words about Ultrafast and why do we think it underperforms: Without WebMCP, Jev chooses from the page’s controls: which button to click, which field to fill, or which option to select. But choosing a valid button is different from choosing the right next step. The agent still has to navigate menus, understand forms, recover from errors and recognize when the task is actually complete. Our hypothesis is that WebMCP makes the decision space much simpler. Instead of figuring out a sequence of clicks through a website, Jev chooses explicit actions that directly advance the task. @typesafeai itself documents weaker accuracy on questions requiring multiple reasoning steps. WebMCP moves much of that complexity into the website’s tools, leaving Jev with clearer decisions and fewer opportunities to go wrong (in a sense WebMCP "compresses" a sequence of clicks into one tool call). Our modified Ultrafast setup solved 25/49 tasks - that is a result for our particular implementation and benchmark, not a universal limit on Jev or Browser Use. We are open to more harness optimization to get this result to perform better, feel free to directly contribute to the benchmark here: github.com/nekuda-ai/WindTun… Browser-use ultrafast: github.com/browser-use/jev-u…
94
170
2,063
239,605
André Bandarra retweeted
In case you missed it - we have support for WebMCP in Chrome DevTools! 🎉 Find it inside the Application panel under "WebMCP" to easily debug your WebMCP tools! Let us know what is missing and what should be improved! #WebMCP #ChromeDevTools #AIAgents #WebDev
8
13
75
11,755
Can we watch The Mummy Returns with DLSS 5 now?
3
128
André Bandarra retweeted
⚠️ WebMCP API breaking change Starting in Chrome 155.0.8051.0, 𝚁𝚎𝚐𝚒𝚜𝚝𝚎𝚛𝚎𝚍𝚃𝚘𝚘𝚕.𝚒𝚗𝚙𝚞𝚝𝚂𝚌𝚑𝚎𝚖𝚊 returns a JavaScript object instead of a serialized JSON string. François Beaufort (@quicksave2k) shared a backwards-compatible pattern:
2
1
3
630
André Bandarra retweeted
Want to understand how WebMCP works? @kaskulikowski from Google covers how agents interact with websites, why semantic HTML matters, how WebMCP exposes structured tools, and how to implement, debug, and evaluate them. Watch Kasper’s full presentation: piped.video/HdCc-KezQPk
3
5
337
I analyzed 545 websites implementing Chrome WebMCP. Across thousands of tool definitions, two common issues show up again and again: 1. Vagueness (under-specification) 2. Verbosity (context bloat) Here’s what I found and how to hit the sweet spot 🧵👇 #WebMCP #AI
7
8
49
6,205
4 rules for WebMCP tool definitions: 1. Scope in 1-2 lines: what it does and returns 2. Bound your numbers: minimum, maximum, default 3. Declare units: amountUsd, standard formats 4. Validate in code, not prompts: handle rules in your JS handler
1
4
170
High-signal schemas cut ~90% of token overhead while making browser agents far more reliable. How are you structuring your WebMCP tool definitions? RT the first tweet if you found this helpful! 🔁
1
4
146