I keep running into a design question I can't answer on my own, and it's the kind of thing other people building in this space will have opinions on.
MCPulse currently reports 16 things: calls per tool, which client they came from, first-call success, retries, empty results, bad arguments, tool errors, crashes, latency, result size, sessions, cost per session, tool pairs, schema size, and dead tools.
That's too many for a first screen. Sixteen numbers is a wall, and a dashboard that makes you work out what to care about has done half the job.
So the question: if you maintain an MCP server and could see exactly one number about it, which would it be?
Hi Product Hunt
I built MCPulse because I published an MCP server and had no idea whether it worked. The directories tell you nothing — not how many people use it, not which tools get called, not whether the model can even understand your tool descriptions.
The thing that surprised me most is on the second image. One tool, search_orders, succeeds on the first try 76% of the time for Claude Desktop and 21% of the time for Cursor. Server-wide it averages out to a flat 62%, which tells you nothing to fix. The description is ambiguous, not the handler — and you cannot see that without splitting every metric by client, which is why every metrics table here is keyed by the client as well as the
tool.
Two things people ask straight away:
It is not a proxy. It is a package inside your own server, so your URL never changes and OAuth keeps working. If MCPulse is down, your server keeps running.
It never sees your data. Sizes and hashes only — there is no column for arguments or results, so it is not a policy I can quietly change later.
Ten languages, one for every official MCP SDK. Free forever and there is a live demo with no signup: app.getmcpulse.com/m/demo
Would love to know what you would want measured that isn't here yet