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
Report
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
Report
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
Report
@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.
Report
does this filter MCP server calls by client? This could be useful for my use-case
@henry_habib Definitely. Thanks for your kind words. Please do share your experience.
Report
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.
TrackMCP
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
TrackMCP
@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?
TrackMCP
@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?
TrackMCP
@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.
does this filter MCP server calls by client? This could be useful for my use-case
Voquill
Congrats! I can see this being useful for debugging weird MCP behavior.
TrackMCP
@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.
Veltrix AI
Cool!!!