Browser agents at Huawei
I spent four months at Huawei researching whether WebMCP was worthwhile for browser agents, and how an agent should be built to use it. I drove the experimental work, from proposing questions and approaches to implementing them and working through the results.
WebMCP lets a website expose actions an agent can call through its forms and JavaScript. Those actions can depend on the page the agent is on. Imagine an issue tracker: the issues page could offer tools for creating and managing issues, while the pull requests page offers a different set. The tools don't all have to be available at once.
But what does "with WebMCP" mean? I worked on both sides: what capabilities a page should expose, and how an agent should discover and use them. I built page-scoped tools and adapted open-source agents to compare page-first, tool-first and on-demand discovery. I also worked through problems such as stable target IDs and preserving a tool's result when its navigation destroyed the page context.
When a comparison finished, I went through the runs myself. Where were the gains? Where were the regressions? What was the agent doing differently? I looked at success and efficiency, not just the final score, and used what I found to propose the next experiments.
I also built benchmark queues so available machines could pick up the next job overnight, served models on local GPUs, and tracked down browser, session and model-serving failures when runs stopped.
I'm not personally betting that tools will replace page observation. My expectation is that small local models will get extremely good at difficult computer-use tasks. I think some of the work I did will become outdated quickly. I learned a lot doing it anyway.
In the meantime, WebMCP may be a good way to make web agents usable for people, for cheap and fast. I see it as an interim approach. Let's make products that users can enjoy now. That's the idea.