Yonatan OfekTL;DR: MCP gives agents a standard way to use tools, but most security MCP setups are thin API wrappers over a single product. Real value comes when MCP sits on full visibility and natural language over federated data.
The Model Context Protocol Is Having a Moment
MCP (Model Context Protocol) is having a moment. Every vendor has it, every product supports it, every keynote mentions it. And the idea is good: give AI agents a standardized way to interact with external tools. Query data, enrich an IP, run a search. That’s genuinely useful.
But most of what’s shipping right now misses the point. This isn’t a protocol problem. It’s an architecture problem.
MCP Didn’t Fix the Security Workflow. It Just Changed the Interface.
Most MCP implementations in security follow the same pattern. Take an existing API, wrap a few endpoints, expose them through MCP. Now an LLM can “use your platform”.
So what can it actually do? Read alerts. Summarize them. Maybe reformat them nicely. That’s about it.
If you’ve ever worked in a SOC, you know that reading an alert is not the work. It’s the starting point. The real job is everything after: you pivot to logs, enrich indicators, run follow-up queries, try to build a story that makes sense. None of that exists in a read-only MCP setup. You end up with a slightly nicer way to look at information you already had. It feels impressive for about five minutes, and then you go back to your normal workflow.
The protocol works. The workflow doesn’t change.
The Problem Isn’t MCP. It’s Where MCP Sits in Your Security Stack.
Security operations don’t happen in one place. They span identity systems, endpoints, cloud logs, SaaS apps, threat intel feeds, and whatever internal systems your team has stitched together over the years. Every investigation crosses those boundaries.
That’s where most platforms quietly break down. Each tool gives you a slice, but none of them give you the full picture. So the analyst becomes the integration layer, bouncing between tabs, correlating things manually, holding context in their head.
Now drop MCP on top of a single one of those tools. Nothing fundamental changes. The AI can only see that one slice. It can summarize it, sure, but it can’t connect it to everything else you need to actually investigate something.
We’ve seen this pattern before with AI in security. When it’s confined to a narrow view of the environment, it stays stuck doing narrow things.
If you want MCP to actually matter for security operations, you have to fix the foundation first. And in security, that foundation is visibility. Not into one system. Into all of them.
Most platforms sidestep this. They ingest what they can, index what they can afford, and call it “coverage.” But investigations don’t respect those boundaries. They cross systems whether your platform does or not.
Vega takes a different approach. Instead of pulling data into a single place, we query it where it already lives, across SIEMs, data lakes, cloud providers, SaaS tools. One interface, one query language (KQL, Kusto Query Language), no re-ingestion.
So when you introduce MCP on top of that, it’s not sitting on a partial dataset. It’s sitting on the full environment.
Inline image (placeholder): Side-by-side of a traditional MCP setup (structured endpoint call with rigid parameters) vs. Vega’s approach (plain English question returning results across multiple data sources). Alternatives: diagram MCP client → natural language → federated query layer → [SIEM, cloud, EDR, SaaS]; or a mockup of natural language in an MCP client with cross-source results.
Natural Language MCP Endpoints Change Everything for Detection and Hunting
Most MCP tools expose structured endpoints. You need to know what to ask for, and the AI just translates your request into a predefined query. It’s useful, but it’s limited.
Vega flips that. The primary MCP tool, nl2kql, doesn’t take a structured filter. It takes a question. Any question. Behind it is a purpose-built AI service that understands security log schemas, so it can translate natural language into valid KQL across your environment. The companion tools, run_query and get_query_results, handle execution and retrieval. Three tools total, but because the entry point is natural language over federated data, they unlock the entire security operations lifecycle.
You don’t call “get alert by ID.” You just ask:
- Show me failed SSH logins from external IPs in the last 24 hours.
- Find processes spawned by Excel that made outbound connections.
- Were there DNS queries to newly registered domains from finance last week?
The system translates that into KQL, validates the generated query against schema and execution constraints, and runs it across every connected data source. The response can be the raw event data itself or an AI-generated summary that highlights what matters, depending on what the workflow needs.
Once that clicks, you stop thinking in terms of endpoints. You’re just asking questions, and the system keeps up. Follow-ups happen naturally. Investigations start to feel like conversations instead of workflows you have to manually stitch together.
And because any MCP client can connect to this, Claude, Cursor, a Slack bot, a custom internal agent, they all become native Vega interfaces. No SDK, no custom integration code, no training users on query syntax.
MCP for Alert Triage, Threat Hunting, and Detection Engineering
Full visibility plus natural language access. That combination is what changes things.
Detection engineering speeds up because you’re not translating ideas into syntax across three different consoles. Threat hunting stays in hypothesis mode instead of getting derailed by query mechanics.
But alert triage is where it changes the most. Vega’s AI-powered triage orchestrator uses MCP internally to investigate alerts autonomously: enriching indicators against multiple threat intel sources, formulating follow-up queries in natural language, persisting results in investigation notebooks, and assigning alerts when human judgment is needed. The AI handles the first 80% of the investigation so the analyst can focus on the judgment calls. Not a summary. A head start.
And that only works because the AI has access to everything it needs and the ability to ask new questions as it goes. None of it works if the MCP layer only exposes “get alert by ID.” For a deeper look at what it takes to make this kind of AI triage actually work, we wrote about the critical requirements for a successful AI SOC.
The Gap Between “MCP Support” and an MCP-Native Security Platform
Right now there are really two versions of MCP in the market. One is a thin layer over existing APIs. It demos well and makes dashboards feel conversational, but it doesn’t change how work actually gets done. The other is what happens when MCP is built on top of full visibility, a unified query layer, and an AI-native workflow. Same protocol, completely different outcome. And as more vendors rush to check the “MCP support” box, that gap is only going to get wider.
The thing security teams actually need isn’t another interface. It’s fewer gaps between the ones they already have. Alert volume keeps going up, data keeps spreading across more systems, and the workflows connecting everything are still held together with duct tape and browser tabs. MCP can help with that, but only if it’s connected to something that actually sees the whole picture and can act on it.
That’s what we’re building toward. Not AI that sits on the edges and summarizes things, but AI that operates inside the detection lifecycle itself, continuously improving coverage, accelerating investigations, and taking real work off the analyst’s plate.
That’s when this stops being a buzzword and starts being useful.
Want to See MCP Work on a Real Security Problem?
If you’re curious what MCP looks like when it’s wired into the system instead of sitting on top of it, we’re happy to show you.
Bring a real detection engineering or threat hunting problem. We’ll walk through it live.
Request a demo and see how Vega turns MCP into something you can actually use.
