MCP

What Security Teams Need to Know About MCP Servers

Written by: 
Published on: 
Jun 9, 2026
A key approaching a glowing keyhole among lime-green pixelated blocks on a dark   background, with the title "What Security Teams Need to Know About MCP Servers.

Security teams are already experimenting with AI to speed up investigation, enrichment, triage, and reporting. The appeal is clear. A model can summarize an alert, organize evidence, explain technical findings, and help analysts think through possible next steps.

Security investigations depend on data a model cannot access from the prompt alone. Proper analysis of a suspicious domain may require current risk signals, DNS history, registration context, infrastructure relationships, ticket details, and other data that live across separate tools and systems. Without a structured way to reach those sources, AI remains useful but limited. The analyst still has to gather evidence manually, switch between tools, and stitch the context together before the model can interpret it.

MCP addresses this connection problem. The Model Context Protocol gives AI applications a standard way to connect to external tools and data sources, allowing security teams to ground AI-assisted work in data from the systems they already trust. For SOC teams, MCP is most useful when it brings domain intelligence, enrichment sources, and investigative tools into the workflows analysts already use.

For domain investigations, that connection matters because analysts often start with a single indicator and need to understand the broader context around it: risk signals, DNS history, registration data, hosting patterns, and related infrastructure. The DomainTools MCP server helps bring that intelligence into AI-assisted workflows through a standard connection layer, so analysts can ask better questions and work from trusted domain data from the start.

The starting point is what an MCP server actually does.

What Is an MCP Server?

MCP, or Model Context Protocol, is an open standard that gives AI applications a common way to connect to external tools and data sources. Instead of relying only on the information included in a prompt, an AI agent or LLM can use MCP to request information from configured systems and bring that context back into the workflow.

For security teams, that matters because investigations often depend on information outside the model. Without a defined connection to those sources, the AI workflow is limited to whatever the analyst provides manually.

An MCP server closes that gap by linking the AI application to the external tools or datasets required for the task. The AI application can interpret the analyst’s request, route the appropriate tool call through MCP, and return structured results that the model can use to support the investigation.

Why Does MCP Matter for Security Teams?

The challenge in the modern SOC rarely comes down to access. The harder problem is getting the right data, fast enough, and in a form analysts can act on.

MCP changes what AI can do inside SOC workflows. A standalone LLM can summarize an alert or suggest a next step, but it cannot pull a current risk score, check passive DNS, or surface related infrastructure. MCP gives the AI workflow a structured way to retrieve that evidence from the systems analysts already trust.

For SOC teams, that shifts AI from a writing aid to an operational layer. An analyst can ask a question in natural language and get back risk signals, registration context, hosting history, and related domains in the same workflow. Senior-level pivots become accessible to junior analysts. Triage moves faster without adding headcount. And because the underlying intelligence is queried programmatically rather than generated by the model, the same question returns the same answer every time.

MCP brings trusted investigation data into AI-assisted work, so analysts can act on evidence instead of gathering it.

How Does MCP Work?

MCP uses a simple architecture: host, client, and server.

The host is the AI application the analyst uses, such as a chat interface, an AI assistant, or an agentic workflow. The client is the secure connection layer inside that host that maintains the session and translates messages to a specific server. The server is the component that exposes specific tools, data, or actions from an external system, such as a security data source, an investigation platform, a ticketing system, or a response tool.

In a security workflow, the process starts when an analyst submits a prompt. The LLM interprets what the analyst is asking for, such as enriching a domain, checking historical records, or finding related infrastructure. The MCP client then routes the appropriate tool call to the right MCP server. The server queries the connected system and returns structured results back through the workflow.

The model can then use those results to answer the analyst’s question, summarize findings, or suggest next steps. The response is based on security data from connected systems rather than only the model’s general knowledge or the prompt text. It is grounded in sources that the security team has configured for the workflow.

What Is an MCP Server Not?

An MCP server is not the intelligence, dataset, or security tool itself. It does not replace the systems analysts rely on for enrichment, investigation, or response. Instead, it provides a standardized way for an AI workflow to access those connected systems.

That distinction matters. MCP is the access layer. It defines how an AI application can request information or trigger configured actions through a common interface. The substance still comes from the underlying tool or data source, whether that is domain intelligence, threat intelligence, case management data, or another security system.

For DomainTools, this means MCP helps bring trusted domain intelligence into AI-driven security workflows. The MCP server provides the AI workflow with a way to request DomainTools data. Still, the investigative value comes from the intelligence itself: risk signals, DNS history, registration context, infrastructure relationships, and related indicators that help analysts understand whether a domain is benign, suspicious, or part of a larger threat pattern.

MCP enables the connection, but domain intelligence is what makes that connection useful for an investigation.

How Can Security Teams Use MCP in Investigations?

Here is what an MCP-connected investigation looks like in practice. An analyst working a suspicious domain starts with: "Analyze the domain sampledomain.com and find related infrastructure." The DomainTools MCP server returns the Risk Score, SSL certificate details, passive DNS records, and registrant email in a single response.

The analyst pivots: "Are there other domains registered to that same email address?" A cluster surfaces, and the LLM identifies shared patterns consistent with a coordinated phishing campaign.

One more prompt narrows the scope: "Give me the domains in this cluster with a Risk Score above 80." The MCP server returns a prioritized list ready to feed back into the SIEM as new IOCs or hand off to detection engineering.

Three investigation patterns show where MCP helps most: domain enrichment, infrastructure pivoting, and historical analysis.

Domain Enrichment

When an alert includes a suspicious domain, the analyst can pull risk indicators, registration details, DNS data, hosting context, and related infrastructure into a single AI-assisted response. The MCP server returns the intelligence in structured form; the LLM organizes it into a summary the analyst can scan in seconds. The analyst sees almost immediately whether the domain is benign, worth monitoring, or worth escalating.

Infrastructure Pivoting

Suspicious domains often share IPs, name servers, certificates, or hosting patterns with other assets. Those relationships are difficult to see when looking at one indicator in isolation. MCP-connected workflows make pivoting easier because the LLM identifies the overlaps and presents them in a form the analyst can review. The investigation moves from a single suspicious domain to a broader infrastructure view.

Historical Investigation

A domain that looks quiet today may have resolved to suspicious infrastructure last month, changed ownership recently, or moved hosts in a pattern that suggests attacker reuse. DomainTools' historical intelligence shows how ownership, hosting, DNS, and related infrastructure have shifted over time, and MCP-connected workflows make those historical questions easy to ask directly inside the AI assistant. The analyst can tell whether they are looking at a stable domain, a recently repurposed asset, or infrastructure worth a closer look.

How Does MCP Reduce Investigation Friction?

Investigations often slow down because the work is spread across too many places. An analyst may need to switch between tools, write custom queries, copy results, compare records, and stitch together context before they can explain what an alert means. None of those steps is unusual, but together they add time and create room for missed details.

MCP can reduce that manual work by letting analysts stay in one AI-assisted environment while still drawing from external security data. The analyst can start with a question, retrieve relevant intelligence through configured tool calls, and ask follow-up questions without rebuilding the investigation from scratch each time.

That can speed up enrichment, make follow-up easier, and make workflows more repeatable. It also helps teams get more value from the security intelligence they already use by making it easier to access in the flow of investigation.

MCP does not remove the need for analyst judgment. It gives analysts a cleaner way to gather and organize the evidence they need, so they can spend less time moving between systems and more time interpreting the evidence.

Why Does MCP Governance Matter?

For SOC leaders, MCP is not only a technical integration model. It is also a governance question. Security teams need AI workflows that connect to operational data in a controlled, interoperable way, without relying on brittle, one-off connectors for every model, tool, or data source.

That matters as AI adoption moves from experimentation into daily security operations. If AI is going to support investigations, enrichment, triage, or response, teams need a connection layer they can manage, review, and integrate into existing processes. They also need flexibility across tools over time, rather than locking critical workflows into a single vendor’s approach.

MCP is gaining relevance because it provides a common connection model for AI applications and external data. Anthropic released MCP as an open standard in November 2024. OpenAI adopted it in March 2025, followed by Google DeepMind in April 2025. In December 2025, the protocol was donated to the Linux Foundation's Agentic AI Foundation. As of 2026, MCP is supported by OpenAI, Google, Microsoft, and AWS, alongside most major AI platforms. For security buyers, that matters because AI adoption is easier to govern when integrations follow a common model instead of a patchwork of one-off connectors.

Teams still need access controls, logging, review processes, and clear limits on which actions an AI workflow can trigger. MCP gives them a more durable foundation for adoption. With MCP, security teams can connect AI workflows to trusted investigation data while maintaining control over which tools are exposed, what actions are allowed, and how results are reviewed.

Why MCP Matters for the AI-Powered SOC

As AI adoption grows in the SOC, alert summaries and investigation notes are only part of the value. Security teams need AI workflows that can connect to real security data, retrieve trusted context, and support the way analysts already investigate threats.

MCP helps make that possible. By giving AI workflows structured access to configured tools and datasets, MCP brings AI closer to operational work in enrichment, triage, hunting, and response. The model can help interpret a request, organize findings, and summarize results, while the connected tools provide the evidence behind the answer.

For domain investigations, the DomainTools MCP server helps analysts use natural language to access trusted domain intelligence, enrich suspicious indicators, and pivot across related infrastructure. Instead of treating a suspicious domain as a standalone artifact, analysts can quickly connect it to risk signals, DNS history, registration context, hosting patterns, and related infrastructure that may change the outcome of an investigation.

MCP does not replace security tools, intelligence sources, or analyst judgment. It gives teams a practical connection layer for using AI with the evidence analysts need.

Ready to bring trusted domain intelligence into AI-assisted investigations? Explore DomainTools MCP to see how your team can enrich suspicious indicators, uncover related infrastructure, and turn domain context into clearer decisions.

An MCP server exposes external tools and data sources to an AI application through the Model Context Protocol. For security teams, it can connect AI-assisted workflows to sources such as domain intelligence, DNS history, enrichment data, and investigation tools.
Security investigations often require live context that a standalone model cannot access on its own. MCP gives AI workflows a controlled way to retrieve evidence from configured tools and datasets, helping analysts enrich alerts, investigate suspicious domains, and ask follow-up questions without manually moving between systems.
Function calling is how a single AI provider lets a model call tools within its own ecosystem. MCP is an open standard that lets any AI application connect to any tool or data source that implements the protocol. For security teams, this means MCP-connected tools are portable across AI vendors rather than locked into one provider's implementation.
The DomainTools MCP server helps analysts use natural language to access trusted domain intelligence inside AI-assisted workflows. Teams can investigate suspicious indicators, pivot across related infrastructure, and connect domains to risk signals, DNS history, registration context, hosting patterns, and other evidence that supports clearer security decisions.
No items found.