The application-level visibility point matches my experience. I removed an MCP server a while back because its tool descriptions quietly told the agent to prefer it as the primary search tool over the built-in one. Not a vulnerability, no leaked secrets, just the vendor steering agent behavior in a way you only notice if you read the raw tool definitions. Does mcp-xray flag that kind of prompt-level steering in tool descriptions, or is it focused on classic vulns?
You're facing competition from both the incumbents who can ship these capabilites to their massive userbase, and emerging startups like Runlayer who are running away with the AI-native segment.
What are you offering that people want yet neither of those classes of solutions offer?
Runlayer can be a fit once you know what you want to put behind an MCP gateway.
The challenge we hear from customers is that they don't know what AI apps, MCPs, or tools their employees are actually using. And new things just keep popping up everyday. Without that visibility, it's difficult to know where to apply controls.
There's also Bluerock, as yet another example. I've worked with both companies though I get nothing from mentioning them here. My point is this is a (suddenly) crowded market - perhaps more so than you realized - so you should consider what exactly is different about your product and why that matters, and then make that obvious to prospective buyers.
I will definitely checkout Runlayer Watch in depth. It seems that it works with coding agents but not web-based agents yet. We've had customers comparing the two solutions. They liked the depth of discovery and the open-source security scanning capabilities.
And I know Harold well at Bluerock. I totally agree that the market is crowded and will only get more crowded which is a good sign that the problem is real.
And yes I totally agree with you that differentiation is the key. I can't say that we have figured this out 100% but our approach is always community first, open-source first. I hope that is the right direction in the long run.
I think you are going in the wrong direction. All EDR providers have this capability now. The actual example of the drop table command that you specified does not execute on the "user's endpoint" anymore.
The fact that you have install another EDR along with this is a no-go.
I agree that DROP TABLE executes remotely. The key point is that the decision to invoke the tool is made by coding agents like Claude Code. Traceforce captures those tool calls at the application layer before they're executed.
The gap we focus on is application-level visibility inside AI apps—understanding which MCPs, skills, and tools are connected and what they're doing. A big part of our work has been building an MCP registry so we can accurately identify and classify MCPs, something traditional EDR telemetry doesn't provide.
That said, if your existing EDR already gives you that level of visibility and enforcement, I’d be interested in learning about which EDR you’re using and how it handles MCP and tool-level activity.
The application-level visibility point matches my experience. I removed an MCP server a while back because its tool descriptions quietly told the agent to prefer it as the primary search tool over the built-in one. Not a vulnerability, no leaked secrets, just the vendor steering agent behavior in a way you only notice if you read the raw tool definitions. Does mcp-xray flag that kind of prompt-level steering in tool descriptions, or is it focused on classic vulns?
Hey Xia! Super excited for this- good talking to you a few weeks ago and best luck with the launch :)
+1
You're facing competition from both the incumbents who can ship these capabilites to their massive userbase, and emerging startups like Runlayer who are running away with the AI-native segment.
What are you offering that people want yet neither of those classes of solutions offer?
Runlayer can be a fit once you know what you want to put behind an MCP gateway.
The challenge we hear from customers is that they don't know what AI apps, MCPs, or tools their employees are actually using. And new things just keep popping up everyday. Without that visibility, it's difficult to know where to apply controls.
Not exactly. See: https://www.runlayer.com/watch
There's also Bluerock, as yet another example. I've worked with both companies though I get nothing from mentioning them here. My point is this is a (suddenly) crowded market - perhaps more so than you realized - so you should consider what exactly is different about your product and why that matters, and then make that obvious to prospective buyers.
I will definitely checkout Runlayer Watch in depth. It seems that it works with coding agents but not web-based agents yet. We've had customers comparing the two solutions. They liked the depth of discovery and the open-source security scanning capabilities.
And I know Harold well at Bluerock. I totally agree that the market is crowded and will only get more crowded which is a good sign that the problem is real.
And yes I totally agree with you that differentiation is the key. I can't say that we have figured this out 100% but our approach is always community first, open-source first. I hope that is the right direction in the long run.
We are also curious to ask what existing tools are folks using to gain visibility into what's running out there?
I think you are going in the wrong direction. All EDR providers have this capability now. The actual example of the drop table command that you specified does not execute on the "user's endpoint" anymore.
The fact that you have install another EDR along with this is a no-go.
Thanks for the feedback!
I agree that DROP TABLE executes remotely. The key point is that the decision to invoke the tool is made by coding agents like Claude Code. Traceforce captures those tool calls at the application layer before they're executed.
The gap we focus on is application-level visibility inside AI apps—understanding which MCPs, skills, and tools are connected and what they're doing. A big part of our work has been building an MCP registry so we can accurately identify and classify MCPs, something traditional EDR telemetry doesn't provide.
That said, if your existing EDR already gives you that level of visibility and enforcement, I’d be interested in learning about which EDR you’re using and how it handles MCP and tool-level activity.