TrackMCP

I helped several companies build their official MCP servers and this was always a key part of it. A very popular question product managers wanted to understand is how the usage of the MCP server differs from the usage of the product via the traditional (aka UI) interface. So this is very cool. As you said, agree that being careful about what data is pulled in is crucial though from the privacy standpoint.

does this filter MCP server calls by client? This could be useful for my use-case

Your site design and product UI are both exceptionally well done. The consistency goes beyond the visual styling; the discipline around hierarchy is especially tight. I used to lead Web UX and Visual Design at Neo4j, so I’m deeply familiar with how difficult it is to represent a complex technical product visually. The “How It Works” block on the homepage is especially strong, and the micro-interactions add a lot without distracting from the explanation. Kudos to the design team.

Cool!!!

So is this a proxy for MCP servers, or does it read the data from the Claude desktop?

The split between tool-call telemetry and outcome visibility is compelling—especially the demo's `send_email` failing 94% of calls. How much of that workflow/outcome linkage is automatic from the one-line SDK, versus something a server needs to instrument explicitly?

Krishna, the part that stuck with me is catching the stuff that looks fine but quietly did nothing. That kind of quiet failure is the worst because you never think to go looking. Genuinely cool.

do u log the tool arguments or only tool names? args carry a lot of user text, but where does the job stop is hard to answer without them

Congrats! I can see this being useful for debugging weird MCP behavior.

What I can't see is whether the result was any good. A tool returns 200 with an empty array, the agent carries on and answers anyway, so my success rate looks healthy while the answer is wrong. The signal I'd want is what happened in the next turn: did the model retry the same tool, switch to a different one, or quietly ignore what came back. That's the gap between a server that responds and one that works.

Hey PH 👋

I kept seeing people build MCP servers, but once it went live, they had no clear view of how it is being used.

So I built TrackMCP to answer these questions:

🔸 Who is using my MCP server?
🔸 Which AI clients connect and how many are new or keep coming back?
🔸 What are they trying to do? Which tools do they use, in what order?
🔸 Does the work get done?
🔸 Where does the job stop?

Add one line to your server. TrackMCP takes care of the rest, and your data shows up in the dashboard right away.

We also has an MCP repository. If you’re building an MCP server, list it there, it’s free.

Would love to hear from people building MCP servers: what are you currently unable to see?

- Krishna