We Measure Whether Agents Pick Tools. Now They Can Pick Pickrate.

Pickrate's entire thesis is that AI agents are a market. We measure whether an agent, handed an unbranded task, reaches for your tool or a competitor's. So there's an obvious dogfood test we couldn't resist: make Pickrate itself a tool an agent can pick, natively, in the browser. As of this week it is. Open pickrate.io in a WebMCP-aware Chrome and an in-browser agent can call Pickrate's tools directly.

What we shipped

WebMCP is a new web standard, currently a Chrome origin trial, that lets a page hand tools to an in-browser agent through a navigator.modelContext API. No separate MCP server, no install — the page declares what an agent can do on it, and the agent reads that contract and calls the tools while the user is on the site.

Pickrate now registers three read tools:

• getPickRate — the headline Pick Rate and rank for a single tool. Ask for stripe and you get back its rank, field size, Pick Rate, Default Rate, and Shortlist Rate.
• getLeaderboard — the ranked tools in a category, by Pick Rate. Omit the category and it lists the categories available.
• lookupTool — resolve a name, slug, domain, or package to its Pickrate report.

The handlers are thin fetches over the same public JSON endpoints that feed the report and leaderboard pages, so there's one source of truth. An agent gets the live numbers, not a snapshot we have to remember to update. We also serve a discovery manifest at /.well-known/webmcp so an agent can learn the contract without executing any page script. Everything is feature-detected and wrapped: on a browser without the trial it renders nothing and changes nothing.

Why "callable" is the point

For two years the whole game of being chosen by AI has been about getting recommended — named in the answer, written into the scaffold. That still matters, and it's most of what we measure. But recommendation and execution are starting to collapse into a single moment. When the agent lives in the browser, the gap between "the agent suggests Pickrate" and "the agent queries Pickrate and uses the result" disappears. The tools that are callable at that moment get used. The ones that aren't are a paragraph the agent has to summarize from memory.

This is the Agent Funnel's Discovery stage taken to its logical end. Discovery has always been about machine-readability — can an agent read you well enough to commit, right now. llms.txt, clean markdown, OpenAPI, an MCP server: each one lowered the friction between an agent and your tool. WebMCP removes the last step. The agent doesn't read about what you can do and then go find an API. It calls you.

A new distribution surface, early

We're shipping this while the standard is still an origin trial and the imperative API is still shifting under us — we register against both shapes it currently ships with and no-op cleanly when neither is present. That's deliberate. Surfaces where agents act are the surfaces worth being early on, and the cost of being there is low: a client island, a manifest, three handlers over endpoints we already had. If agents are buyers, the browser-as-agent-runtime is a store we'd rather have a shelf in before it's crowded.

It's also the most honest version of the product we can ship. We tell dev tools to be readable and callable by agents. It would be strange if the company measuring that weren't.

Try it

Open pickrate.io in Chrome 149+ with WebMCP, and ask an in-browser agent for the Pick Rate of any tool. Or read the contract yourself at /.well-known/webmcp. Then go see where your tool ranks — and whether an agent would pick it.