Written by
Y2 Team
At

MCP Server for Threat Intelligence: A Defender's Guide

Evaluate an MCP server for threat intelligence, query Y2 CVEs and cyber graphs, and separate evidence retrieval from security response permissions.

Back

An MCP server for threat intelligence exposes security research capabilities to an AI application through the Model Context Protocol. Depending on the provider, those capabilities may include indicator enrichment, vulnerability lookup, threat-actor research, or access to a security platform. Choose a server by its evidence and permissions, then test a complete investigation.

The first question is specific: are you researching external threats, investigating your own telemetry, or executing a response? Those jobs need different data and different authority.

Which threat intelligence connection do you need?

NeedEvidence to requestIntegration consideration
Vulnerability researchCVE identity, advisory links, affected products, related entitiesVerify identifiers and source dates
Indicator enrichmentDomain, IP, URL, or hash observations with provenanceCheck coverage and observation age
Internal investigationAuthorized security events and organizational asset contextKeep tenant and telemetry access explicit
Response executionA reviewed action against a defined targetSeparate write authority from research credentials

For an established implementation example, Google's security MCP repository documents connections to Google Threat Intelligence, Google SecOps, SOAR, and Security Command Center. Each has its own product setup and access requirements. Y2's MCP integration exposes its documented intelligence resources, including cyber entities and graphs. This is a capability comparison, not a measured ranking of detection quality.

A CVE-to-graph workflow with Y2

Configure @y2-intel/mcp using the setup guide and a workspace-bound key with intel:cyber. Discover the installed tools and inspect the live OpenAPI operations before calling them. The following argument object searches an example CVE using y2_call_api:

{
  "operationId": "listCVEsV2",
  "parameters": {
    "q": "CVE-2024-3094",
    "limit": 5
  }
}

The identifier is an illustrative lookup, not evidence of a current incident. Confirm an exact CVE match in the returned data. If the search returns nothing, record the missing result rather than inventing an entity.

For a matching record, inspect getCyberGraphV2 and pass the returned CVE entity ID:

{
  "operationId": "getCyberGraphV2",
  "parameters": {
    "rootCveId": "RETURNED_CVE_ENTITY_ID",
    "depth": 1
  }
}

Replace RETURNED_CVE_ENTITY_ID with the actual entity identifier. The parameter expects an entity ID, not the text CVE-2024-3094. The cyber graph reference supports a bounded traversal from a CVE, threat actor, or malware-family root, with a maximum depth of two.

Review the relationships and supporting evidence. A graph connection can guide the next query; it does not, by itself, establish that an actor exploited a vulnerability against your organization.

Tool discovery is not permission enforcement

Y2 can hide dedicated mutation tools with Y2_MCP_ENABLE_WRITE_TOOLS=false, but the configured key's scopes still determine API authority. The generic y2_call_api tool follows the selected operation's authorization. A broad key can retain powers that are absent from the visible list of dedicated tools.

For this CVE workflow, keep intel:cyber and omit unrelated write scopes and agent:y2. If the research later needs another domain, determine the exact new operation and scope before expanding the credential. The scoped-key guide explains the boundary.

How to evaluate the result

Build a small, analyst-reviewed evaluation set around the actual task:

CaseExpected behavior
Exact CVE lookupPreserves the correct identity and source references
Similar actor aliasesShows uncertainty instead of silently merging distinct actors
No graph relationshipReports the evidence gap without inventing an edge
Outdated indicatorPreserves its observation date and avoids a present-tense claim
Missing scopeReports authorization failure and stops unchanged retries

Track supported claims, incorrect matches, missed evidence, and analyst corrections. Tool-call success rate is useful for operations, but it does not measure analytical accuracy.

Frequently asked questions

Is a threat intelligence MCP server also a SIEM integration?

Only if it exposes that product's telemetry and investigation capabilities. Inspect the provider's tool reference and authentication requirements. External intelligence access alone does not connect an organization's logs.

Does read-only access eliminate agent security risks?

No. A read tool can disclose sensitive data or return content containing malicious instructions. Limit accessible data and validate where results can go. See AI agent security best practices.

How does this differ from a cyber threat intelligence AI agent?

The server supplies a tool interface. The agent selects operations and produces the investigation output within its host's policies. The cyber threat intelligence agent guide covers that broader evidence-to-brief workflow.