WebMCP, But Only From the Server

We've spent ten months hunting token sucks in our own dev loop. Not the model's output, the input nobody watches: the context you shovel in to get one answer back.

For a long while the biggest one was scoping. Turning an epic into its tasks against the PM database meant pulling schema, rows, and relationships into the prompt as SQL, pass after pass, and it ran into the millions of tokens at times. We fixed it. I won't bore you with exactly how here, but it came down to roughly a couple hundred thousand. Same work, a fifth of the compute.

With that one off the board, the next suck stood out plain: visual verification. Every time we touched the front end and wanted to know "did it actually render," we reached for Playwright, or a screenshot, or a DOM dump piped into the model. A screenshot is a pile of tokens. A full DOM is worse, and most of it is div soup the model has to wade through to find the one row that says whether the thing worked.

The screen was never what we cared about. The state was. So we quit looking at the screen.

We register the app's own tools and let the test call them directly using WebMCP, but only when the request was coming from the same server. No browser to drive, no pixels to read. The check invokes the registered verb server-side and reads back a structured result: the row, the status, the value it was looking for. Same question answered, a fraction of the tokens. The drop landed in the same neighborhood as the scoping fix.

"Only from the server" is the part that matters, and it's where the token win and the security turn out to be the same decision. WebMCP, the emerging way for a page to hand an agent its tools, points the right direction. Declared verbs beat scraped pixels every time. But a tool surface a page hands to any agent that wanders by is the McKinsey Lily problem in a new suit. Their internal AI tool sat with a couple dozen writable endpoints unauthenticated, and an agent walked one for about twenty bucks. A verb an agent can call is a verb an attacker's agent can call, and "it's just the frontend" was never a security boundary.

Our tools answer only to the server, behind the same firewall every other command runs through: the verb checked against a whitelist, the caller's scope checked, fail closed when anything looks off. Permissions are a bitset per cell, rwxdi. Read, write, execute, direction, interface. A human gets one set; an agent acting for that human gets a narrower one, declared on the cell it's working inside. Same tool, different bailiwick. That's the agents-versus-humans line, drawn at the envelope rather than bolted on after. The move that saved the tokens, routing every tool call through the server's own WebMCP tools security, is the move that locks the door and saved us a further 25% reduction.

So that's how we use it. Two of our biggest dev token sucks, scoping and verification, came down to the same thing: quit shipping the haystack, ask for the needle through a governed verb. If y'all are wiring agents into your own app, that's the play. WebMCP got the door right. The lock is server-side, bring your own lock. If things hold, adding WebMCP security could become the part a savvy consultant could package and sell.

The firewall, the bitset, the agents-versus-humans envelope, it's all in the writing. Read on, or subscribe.