---
title: "Blog"
description: "Read about the background of our monitoring solution, new features and case studies"
canonical: "https://www.rumvision.com/blog/what-does-webmcp-mean-for-website-performance-and-rum/"
---

Breadcrumbs: [Home](https://www.rumvision.com/?format=md) > Blog

# What does WebMCP mean for website performance and RUM?

AI agents are becoming another way people interact with websites. But today, they often still have to use a website much like a human would: open a page, inspect the interface, find the right input or button, perform an action and then interpret the result.

WebMCP proposes a different approach. Instead of making an agent figure out how your interface works, a website can expose structured tools that describe what the agent can do.

For example:

- A documentation website could expose a `search_help` tool.
- An ecommerce site might eventually expose tools for finding products or checking availability.
- A SaaS application could expose actions such as retrieving account information or querying reports.
 
That is interesting from an AI perspective, but it also raises an interesting performance question: **if an agent can go directly to the capability it needs, does it still need to load and interact with all the same pages a human would?**

## What WebMCP changes

WebMCP changes the way an agent can interact with a website. Instead of interpreting the visual interface first, the agent can discover structured capabilities that the website exposes directly.

Chrome currently describes WebMCP as a way for websites to expose tools to in-browser AI agents. The API is still experimental, but the underlying idea is straightforward: give agents a direct interface to useful website functionality.

### From UI to direct capabilities

Normally, an agent searching a website may have to reproduce an entire user journey:

 ```
open website→ find search→ enter query→ submit→ load results→ inspect results→ open article
```

With WebMCP, the site can expose that same capability directly:

 ```
search_help("third party performance dashboard")
```

The agent no longer needs to understand where the search box is, how the form works or how the results page is structured.

### A small tool can be useful

You do not need to expose your entire application for WebMCP to be useful.

A documentation search is already a good example. It has a clear purpose, does not modify user data and can usually reuse an existing search endpoint.

That makes it a practical first step for websites that want to experiment with agent-friendly functionality without redesigning their application.

## WebMCP and site performance

WebMCP is not a performance API. Registering a tool does not automatically make a website faster.

The more interesting performance effects appear when an agent can replace several interface interactions with one direct capability.

### Does it improve Core Web Vitals?

Not directly.

Adding WebMCP does not automatically improve Largest Contentful Paint, Interaction to Next Paint or Cumulative Layout Shift. There is no Core Web Vitals benefit simply for exposing tools to agents.

A poor implementation could even do the opposite. Loading a large framework, making extra configuration requests on every pageview or doing expensive work during startup would simply add overhead for normal visitors.

So WebMCP should be treated as progressive enhancement, not as another mandatory frontend dependency.

### Less work in the browser

If one structured tool can replace several page navigations and UI interactions, there may be less work for the browser.

An agent may no longer need to render multiple intermediate pages, trigger interface updates or execute JavaScript associated with operating those screens.

This does not improve the Core Web Vitals of a human visitor. It simply makes the agent's route through the website more efficient.

### Less work on the server

The same principle can apply to backend load.

A normal navigation may involve HTML generation, database queries, template rendering and additional API requests. If an agent needs several page loads before reaching its goal, all of that work may happen multiple times.

A well-designed WebMCP tool could sometimes replace that journey with one targeted request.

That does not mean WebMCP automatically reduces server load. It depends on what the tool does. But when one concrete API call replaces several navigations, less backend work is a realistic side effect.

### Keep WebMCP lightweight

There is some irony in making a website slower just to help agents use it more efficiently. The same performance principles therefore still apply:

- **Keep registration small.** Tool metadata usually does not require a framework or large dependency.
- **Avoid startup requests.** Fetch data when a tool is used, not merely because WebMCP exists.
- **Reuse existing APIs.** A WebMCP layer can often remain very thin.
- **Cache static code.** A small `webmcp.js` file can use normal browser caching.
- **Use progressive enhancement.** Normal site functionality should not depend on WebMCP being available.
 
## What makes a useful tool

Simply exposing a tool is not enough. A good tool should help the agent complete a task with as little unnecessary follow-up work as possible.

That means both the purpose of the tool and the quality of its response matter.

### Concrete output matters

A search result that only returns a title and URL may force the agent to open every result before deciding whether it is relevant.

A richer response can provide enough context immediately:

 ```
{"title": "Third parties","module": "help","relevance": 100,"ai_context": "Use this article for questions about the RUMvision Third Parties dashboard, JavaScript execution impact, Long Animation Frames (LoAF), INP diagnostics and comparing first-party versus third-party script performance. It covers 1st-party and 3rd-party UX impact scores, hostname occurrence frequency, JavaScript execution time, INP involvement distributions, low/moderate/critical impact categorization, drilling down from hostnames to individual file paths and source locations, and jumping into the Technical dashboard with preconfigured filters. Relevant for questions about third-party scripts, long tasks, LoAF tracking, INP regressions, GTM, consent providers, monitoring tools, inline JavaScript, script hostnames, file-level debugging, 200ms execution thresholds, 75th-percentile interaction impact, third-party categories, benchmarks and evaluating alternative vendors or lighter implementations.","hyperlink": "/help-center/monitoring/dashboard/third-parties/","text": "The Third Parties tabblad can be found in the sidebar navigation. It will show you long JavaScript tasks per hostname and even filename, helping website owners to make informed decisions. To track the impact ...","markdown_url": "/md/help-center/monitoring/dashboard/third-parties/"}
```

The agent can now decide whether the result matches the user's question before retrieving the full article. That is another way tool design can reduce unnecessary requests and navigation.

### Reuse existing APIs

WebMCP does not necessarily require a separate AI backend. A site may already have:

 ```
website UI│▼existing API
```

WebMCP can simply become another consumer:

 ```
human UI ──────┐▼existing API▲AI agent ─ WebMCP
```

That keeps business logic in one place and avoids maintaining separate implementations for humans and agents.

### For sites, shops and dashboards

WebMCP is not limited to public websites. It can also be useful inside webshops, dashboards and authenticated or otherwise authorized environments, wherever an agent needs to perform structured tasks on behalf of a user.

A webshop, for example, could expose tools that let an agent retrieve a previous cart, adjust quantities or sizes and prepare a new order. With the right permissions and confirmation steps in place, the same flow could eventually continue all the way to checkout.

## WebMCP on RUMvision

We have now started experimenting with WebMCP on the RUMvision website as well.

For now, our implementation is deliberately small. The first capability focuses on something that is both useful and low risk: finding information in our Help Center and blog.

### Our first use case: search

RUMvision currently exposes a `search_help` tool that allows an in-browser agent to search our documentation using structured search terms.

Conceptually, it looks like this:

 ```
search_help({query: "third party performance dashboard",module: "help"})
```

We had already built the underlying structured search flow for our [regular MCP integration](https://www.rumvision.com/help-center/apis/mcp/introduction/?format=md). Once that was in place, extending the same capability to WebMCP was a fairly natural next step rather than a separate search project.

We didn't need to build a separate search engine specifically for WebMCP. The tool simply reuses our existing search infrastructure and exposes that same capability to in-browser agents.

The agent simply gets another structured way to use a capability that already exists.

### Why this matters for RUM

Real User Monitoring is built around understanding how people use websites: pageviews, navigations, interactions, browser conditions and performance metrics.

An agent using WebMCP may follow a very different route.

A human looking for documentation might do this:

 ```
homepage → help center → search → article
```

An agent could instead do:

 ```
search_help() → article
```

The goal is the same, but the technical journey is different.

As agent-driven browsing becomes more common, that distinction may become relevant for analytics and monitoring. A WebMCP invocation may not generate the same interactions, navigation patterns or engagement signals as a normal human journey.

### Expose performance data too

For a RUM platform, the opposite direction may be even more interesting.

Instead of only exposing website functionality to agents, performance data itself could eventually become available through structured tools such as:

 ```
get_metric_summaryget_health_checkscompare_periodsget_lcp_breakdown
```

An agent could then investigate a question such as:

> Why did LCP become worse after yesterday's deployment?

without first navigating several dashboard screens and manually configuring the right filters.

That does not make the monitored website faster. It can make **finding and understanding performance problems faster**.

## Where this could go next

WebMCP is still early, so there are plenty of open questions around browser support, agent behavior and how websites will eventually expose these capabilities.

But the broader direction is interesting for both websites and monitoring tools.

### Human and agent journeys

Websites have traditionally been designed almost entirely around human interaction. Agents currently learn to use those same interfaces by inspecting and reproducing human actions.

WebMCP introduces another possibility: tell the agent directly what the website can do.

Because Agentic browsing is likely here to stay, whether websites actively design for it or not. If agents are going to interact with our sites anyway, there is little reason to force them through every interface step a human visitor needs. Providing a clearer, more direct path can remove unnecessary hurdles for agents while potentially reducing the amount of navigation, rendering and backend work required to reach the same outcome.

That could eventually make it useful to distinguish between:

 ```
human navigationagent-assisted navigationWebMCP tool usage
```

Those journeys may have the same goal but very different technical characteristics.

### Experimental, but worth trying

WebMCP is still experimental today, so normal website functionality should not depend on it yet. WebMCP is currently being developed in the [W3C Web Machine Learning Community Group](https://www.w3.org/community/webmachinelearning/). The current [WebMCP specification](https://webmachinelearning.github.io/webmcp/) is published as a Community Group Report, which means it is still a draft and not a finalized W3C standard.

Chrome is actively developing the API, and current implementation details can still change. The latest status and documentation are available in [Chrome's WebMCP documentation](https://developer.chrome.com/docs/ai/webmcp/).

For us, that makes a small, read-only capability such as documentation search a sensible place to start.

It is useful today, while still leaving plenty of room to learn how agent-driven website interaction may develop.

## Conclusion

WebMCP is not a Core Web Vitals optimization. Adding a WebMCP tool will not suddenly improve LCP, INP or CLS.

The more interesting performance benefit is structural.

When an agent has access to a well-designed capability, it may no longer need to reproduce a multi-step human workflow to reach the same result. That can mean fewer page loads, less frontend work, fewer backend requests and a shorter path from intent to outcome.

RUMvision now supports WebMCP on our website, currently focused primarily on searching Help Center and blog content.

That is a small first step, but it already demonstrates the underlying idea: **agents do not always need to use websites in exactly the same way humans do.**

And for a RUM platform, that leads to an interesting next question:

**if agent journeys become fundamentally different from human journeys, how should we measure them?**