TrackMCP shows who is using your MCP server, what they are trying to do, whether the work gets done, and where to improve. All from one line of code.
Free Options
Launch Team
ArticosTest your messaging on your audience, right inside Claude or ChatGPT
Promoted
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
@niveditha_patluri1 Yeah, that’s an important distinction. Tool names alone aren’t enough as the arguments often contain the context needed to understand whether the agent called the tool correctly and whether the result was relevant.
At the same time, we don’t want to blindly log sensitive user text. The goal is to make tool arguments inspectable with the right privacy controls (redaction, filtering, and configurable retention), then connect them to the tool result and the agent’s next action. That’s what lets you understand not just which tool ran, but whether the whole interaction actually worked
So is this a proxy for MCP servers, or does it read the data from the Claude desktop?
@jay_janarthanan1 It’s not a proxy and it doesn’t read data from Claude Desktop. TrackMCP wraps your existing MCP server and sends minimized telemetry from the server boundary like client connections, tool calls, errors, latency, retries, and workflow outcomes. It works across Claude, Cursor, ChatGPT, and custom MCP clients, while the server owner controls what data is collected
@krishnaa_ ok, so can it wrap MCP servers hosted by, for example, Salesforce?
@jay_janarthanan1 TrackMCP wraps the MCP server at the code boundary, so it works when you control the server or can add our SDK. For an MCP server hosted entirely by Salesforce, we wouldn’t be able to instrument it directly yet
The way to support that would be to place TrackMCP in front as a lightweight proxy or gateway, preserving the existing auth and session behavior while observing the MCP requests, tool arguments, results, and follow-up calls.
Congrats! I can see this being useful for debugging weird MCP behavior.
@henry_habib Definitely. Thanks for your kind words. Please do share your experience.
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.
Cool!!!
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.
@asadmalik901 Yes, I hear you and that's exactly the problem we are solving. A 200 response only tells you the server replied. It actually doesn't tell you whether the tool helped the agent. Even an empty result can look like a success when the agent gives the wrong answer and the metric states healthy.
We are building the visibility to connect exactly these dots: what the tool returned, how the agent interpreted it, what happened next. It also identifies whether it retried, which tool asked for more information, or just quietly carried on with the bad result. That next turn behaviour is the real signal of whether the system worked and that's our focus. That's the gap we are actually trying to close with TrackMCP.
@asadmalik901 @krishnaa_ Was gonna ask the same thing, but asad beat me to it. I hope to see more visibility in the future versions and congrats on your PH Launch today!
@krishnaa_ @simon_liang_1 The breakdown I'd want is per tool, not per server. When we instrumented ours the ugly finding was that one badly worded tool description caused most of the re-asks, and the server itself returned the right thing every time. If the retry data can point at which description is confusing the model rather than just flagging that a retry happened, that's the bit I'd pay for.
@krishnaa_ @simon_liang_1 The hard part is that the server never sees the next turn. It knows it returned something, and whatever the model did with that happens inside a client it has no window into. So the retry-or-ignore signal has to be collected client side, which is a much bigger install ask than one line of code on the server. Worth being upfront about which half you're actually measuring today.