This content originally appeared on HackerNoon and was authored by Mistakili
\ Last month I shipped an MCP server for Toolora — a suite of 41 browser based developer tools I've been building. Within days, AI agents were connecting to it. 594 MCP calls in the first week. I opened my analytics and thought I'd made it.
Then I looked closer at the breakdown.
246 _connect calls. 313 _list calls. 35 actual tool executions.
Agents were finding the server, cataloging every tool, and then… moving on. Like a tourist who photographs a restaurant menu but doesn't order. The MCP discovery-to-execution gap is real, it's not a code problem, and nobody is really talking about it.
But let me back up.
Why I Built This
Every developer tool I've ever used that "processes your file" actually sends it somewhere. Cloudflare, AWS, a startup's backend I know nothing about. I wanted tools that are genuinely local — where the privacy guarantee isn't a policy you read, it's a physical fact. Your file never leaves your device because no code exists to send it anywhere.
So I built Toolora as a fully browser-side tool suite. PDF merging runs on pdf-lib in a Web Worker. Image compression uses the Canvas API. JSON formatting, Base64, hashing, JWT decoding — all in-browser JavaScript, zero server contact.
41 tools now, across text, developer utilities, image processing, PDF manipulation, and AI/RAG prep tools (token counting, text chunking, HTML to Markdown).
The MCP Server
MCP (Model Context Protocol) is Anthropic's open standard for connecting AI agents to external tools. Think of it as a universal adapter that lets Claude, Cursor, and other AI tools call your functions in a structured way.
The irony of adding an MCP server to privacy-first browser tools isn't lost on me. The tools themselves are local-only; the MCP server is a server-side layer that wraps some of the same logic for agents that can't run browser code. It felt like the right tradeoff — humans get the browser tools, agents get the API.
Here's a simplified version of what the MCP endpoint returns when an agent calls tools/list:
{ "tools": [ { "name": "count_words", "description": "Count words, characters, sentences, and estimate reading time.", "inputSchema": { "type": "object", "properties": { "text": { "type": "string", "description": "Text to analyze" } }, "required": ["text"] } } // ... 24 more ]}
I'm using a standard HTTP+SSE transport rather than stdio, which means it works as a hosted endpoint — paste the URL into Claude Desktop's config and you're connected. No install, no Docker, no npm package.
The Discovery Gap
Back to those numbers. 594 MCP calls, 35 actual executions.
When I dug in, the pattern was clear. Agents were running automated discovery sweeps — connecting to MCP servers, listing all available tools, and storing that metadata somewhere. The _connect and _list calls happened in seconds. The actual count_words and other tool calls trickled in much later, from what looked like different sessions.
This tells me a few things:
- MCP discoverability is a solved problem. Agents find new servers fast, apparently through directories and shared registries I haven't fully mapped yet.
- The gap is a placement problem, not a quality problem. Agents discover tools but don't use them unless they have a specific task that maps to that tool at the right moment. The tool descriptions and input schemas matter enormously for this.
- Tool descriptions need to be written for agents, not humans. My initial descriptions were human-readable marketing copy. Agents need specificity: what inputs, what output format, what edge cases.
I've started rewriting tool descriptions with agent usage patterns in mind. "Count words, chars & reading time" becomes "Analyzes text and returns word count, character count (with and without spaces), sentence count, paragraph count, and estimated reading time in minutes at 200 WPM."
The Technical Stack
The browser tools are all React components, each doing real work in JavaScript/WebAssembly:
- PDF processing:
pdf-lib+pdfjs-dist - Image compression: Canvas API with quality tuning
- Hashing: Web Crypto API (SHA-1, SHA-256, SHA-512) for the stuff browsers support natively, WebAssembly for MD5
- YAML parsing:
js-yaml - Token counting:
tiktoken(GPT-4o encoding) + custom Claude tokenizer approximation - Text chunking: configurable chunk size/overlap for RAG pipelines
The MCP server is a Node.js/Express layer that re-implements the same logic server-side for the tools that make sense as agent utilities. It runs alongside the frontend but is architecturally separate.
One thing I got wrong early: I tried to share code between the browser tools and the MCP server. It seemed elegant. It was a maintenance nightmare. Browser bundles and Node modules have just enough overlap to make you think it'll work, and just enough difference to break at the worst times. They're separate implementations now.
What's Actually Working
The organic traffic side is more straightforward than the MCP side. Each tool page is a dedicated route with static HTML content for crawlers:
toolora.dev/tools/developer/jwt-decodertoolora.dev/tools/developer/regex-testertoolora.dev/tools/text/word-counter
These rank reasonably well for long-tail queries because they load fast (Vite-bundled, sub-second LCP), they're genuinely useful, and the content is specific enough that there's not much competition for the exact query.
The Chrome extension has been the biggest surprise for retention. Users who install it come back more than users who bookmark the site. That's not shocking in retrospect — the extension appears every time they open a new tab — but I underestimated how much the distribution channel affects the usage pattern.
What I'd Do Differently
Ship the MCP server earlier. I treated it as a nice-to-have. It turns out AI agents are eager to adopt new tools and the barrier to them discovering your server is low if you list it in the right places.
Design for agents from day one. Not just the tool descriptions — the actual tool interfaces. Agents prefer tools with narrow, composable inputs over multi-purpose tools with lots of options. A tool that does one thing and does it predictably is more useful than a Swiss Army knife.
Don't over-engineer the privacy story. "Your files never leave your device" is a one-sentence sell. I spent too long writing longer explanations when the short version works fine.
The Broader Point
Browser-side processing has gotten genuinely powerful. WebAssembly, Web Workers, the Canvas API, Web Crypto — you can do a lot of real work without a server. The tradeoff is not zero (you can't do everything, and WebAssembly bundles add size), but for the category of "developer utility tools," the browser is now a legitimate compute platform.
And MCP is making server-side exposure of the same tools useful again, but for a different audience. It's an interesting moment where the same product can have two genuinely different technical delivery mechanisms for two genuinely different users.
If you want to see the tools: toolora.dev \n MCP server endpoint for Claude Desktop:https://toolora.dev/api/mcp
The extension is on the Chrome Web Store if you search "Toolora."
What's your experience with the MCP discovery gap? I'm curious whether other MCP server authors see the same connect/list vs. actual-execution ratio.
\n
\
This content originally appeared on HackerNoon and was authored by Mistakili
Mistakili | Sciencx (2026-04-29T07:24:36+00:00) I Added an MCP Server to My Browser-Based Tool Suite. Agents Found It Immediately.. Retrieved from https://www.scien.cx/2026/04/29/i-added-an-mcp-server-to-my-browser-based-tool-suite-agents-found-it-immediately-2/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.