MCPulse

@uninejacky Partly, and the honest answer has a hole in it worth naming.

What's there: tool pairs, which tools get called one after another, and per-tool call counts. So if the agent skipped your tool and reached for a neighbour instead, that neighbour's count is up and yours is flat. On a small server that's usually enough to see which one took the traffic.

What's missing is the direct claim. The server sees a call to B. It never sees A being considered and passed over, because that decision happens in the client and the protocol reports nothing back. So "the agent picked B instead of A" is an inference from two counts rather than something observed.

Which is fine when the pair is obvious and useless when it isn't. On a large server with several plausible substitutes, you get "A is dead, and these four tools are all busy" — and no way to tell which of the four is actually absorbing A's requests.

The thing that narrows it is the static side: which tools share an input object with A. If A takes a customer and only two of the four busy tools also take a customer, those two are the candidates. Combining "never called" with "shares an input with something heavily called" is a much better signal than either half, and it's roughly the version I'm building.

Still an inference. The definitive answer needs a controlled test — write a sentence that should route to A, run it with the full tool list, see what actually gets picked. That you can do before shipping, with no traffic at

@kashclick Good question, and the honest answer to the first half is that MCPulse can't distinguish those on its own — you distinguish them, and the mechanism is already in MCP rather than in my SDK.

A business-level refusal is a successful execution. Your handler ran, applied a rule, and the correct result is "this order isn't eligible for invoicing". If you return that as content with isError false, it records as ok — which is right, because nothing failed. If you return it with isError true, it records as tool_error, which is also legitimate if you consider an ineligible request an error condition.

Either is fine; mixing them within a server is what hurts, because then tool_error means two things and you can't read the rate. Worth picking one convention and applying it everywhere.

The sharper case is the one you didn't ask about. If your refusal returns an empty result rather than an explanation, it records as is_empty — succeeded and returned nothing usable. That's indistinguishable from a genuine no-data case, and it's also bad for the model, which gets nothing to tell the user. A refusal that says why is both better instrumentation and a better answer.

On tenants: no tenant identifier is collected, and there's no field for one. Which means per-tenant comparison isn't possible — a real limit rather than something I'd work around. Per-client comparison works because client_name comes from the MCP handshake and identifies software rather than a customer.

For a POS ven

Hey 👋

I built MCPulse because I published an MCP server and had no idea whether it worked. Not "was it up" — whether the model actually understood the tools I'd written.

The directories tell you nothing. Not which tools get called, not whether your descriptions make sense to the thing reading them. The protocol never reports back to the author.

Here's what convinced me it mattered. One tool, search_orders: 76% first-call success in Claude Desktop, 21% in Cursor. Server-wide that averages to 62% — too high to look urgent, too low to look healthy, useless either way. The description was ambiguous, not the handler.

Two things people ask straight away. It's not a proxy — it's a package inside your own server, so your URL never changes and OAuth keeps working. And it never sees your data: sizes and hashes only, no column for arguments or results.

Two lines to install, ten languages, free forever.

Try the live demo first, no signup: app.getmcpulse.com/m/demo — look at first-call success and switch between clients.

If you maintain an MCP server, what would you want measured that isn't there yet?

The privacy-first angle is the part I'd lead with harder. I built an analytics product too and landed on the same constraint for a different reason — my users' data is sensitive enough that "we don't collect it" had to be structural rather than a policy, so there's simply no column for it in the schema. Turns out the constraint sells better than the feature would have.

One question on the gamification: does the XP track effort or outcome? Levelling up on visitors feels different from levelling up on shipping — the first rewards a number you only partly control, the second rewards the thing that actually moves it. Curious which way you went, because that choice probably decides whether founders come back on a bad week.