ThreatWeaver is an MCP server that lets an AI client investigate indicators of compromise as a running investigation instead of a series of disconnected lookups, correlating findings across IOCs to surface shared infrastructure and campaign patterns.
What this enables
- Queries VirusTotal, AbuseIPDB, URLhaus, and Shodan in parallel for a single IOC instead of four manual tab switches.
- Keeps investigation state in an MCP resource, so a follow-up question like "which of these share an ASN" doesn't require re-explaining prior findings.
- Correlates multiple IOCs using shared ASN, registrant, malware tags, and geographic proximity to flag likely coordinated infrastructure.
- Outputs STIX 2.1 bundles that SIEM tools like Splunk, Elastic, or Sentinel can ingest directly.
- Runs in an offline mode against fallback datasets when API keys aren't configured.
The workflow security analysts actually deal with
When a SOC analyst gets a suspicious IP, domain, URL, or file hash, the job is to figure out how dangerous it is and whether it connects to anything else already under investigation. In practice that means separately querying VirusTotal for detections, AbuseIPDB for abuse reports, URLhaus for known malicious URLs, and Shodan for exposed services and ASN data, then manually holding all of that in your head, or in a notebook, while you decide what to check next.
The harder problem is correlation. A single IOC rarely tells the full story. Coordinated phishing or C2 infrastructure usually reuses ASNs, registrants, or malware families across several IOCs, but that pattern only becomes visible once someone lines up multiple investigations side by side. Single-source, single-query tooling doesn't do that by default; it takes an analyst noticing the overlap.
Why a REST wrapper wasn't the right shape
A conventional integration could expose each threat-intel API as a REST endpoint and let a model call them one at a time. That covers individual lookups, but it drops the thing that actually matters here: investigation state. Each REST call is stateless, so a natural follow-up like "which of these are on the same ASN" would require the client to re-send everything it has already learned, or the server to bolt on its own session layer.
ThreatWeaver's README frames the distinction directly: MCP's resource and prompt capabilities support persistent, agentic investigation workflows in a way plain REST APIs don't, since correlation across investigation history needs state that outlives a single request-response pair.
The build
ThreatWeaver exposes five MCP tools, two resources, and one prompt. investigate_indicator queries VirusTotal, AbuseIPDB, URLhaus, and Shodan for a single IOC and returns a threat score. suggest_next_steps looks at what's already been investigated and proposes related indicators, for example a domain sharing an ASN with an IP already flagged.
correlate_investigations runs a BFS over the investigation history, comparing every pair of IOCs on shared ASN (weighted 0.90), shared malware tags (0.85), shared registrant or ISP (0.75), and geographic proximity under 100km (0.60); groups of three or more IOCs connected on multiple attributes get reported as a coordination pattern. generate_report turns the investigation into Markdown or a STIX 2.1 bundle, and batch_investigate runs the same pipeline across a list of IOCs with progress streaming.
The state that makes follow-up questions possible lives behind an investigation://current resource, backed by SQLite with a two-layer LRU-plus-disk cache. A second resource, threat://feeds, exposes pre-loaded fallback data so the server keeps working without live API keys, which is useful for demos and for analysts working somewhere API quotas are tight. An investigation_template prompt guides the model's reasoning through the investigate-correlate-report sequence rather than leaving tool ordering to chance.
In the demo flow shown, a client investigates an IP, gets back a threat score with detection counts and ASN data, then asks a natural follow-up. The server has already stored the ASN from the first lookup, so suggest_next_steps can surface two related IOCs on that same ASN without the analyst restating anything. Investigating those and running correlate_investigations produces a pattern match: three IOCs, shared ASN plus overlapping malware tags, with a confidence score attached.
Where NitroStack fits
ThreatWeaver's tools, resources, and prompt are built with NitroStack's decorator-based primitives (@Tool, @Resource, @Prompt) inside an @Injectable module structure, with Zod schemas validating IOC input before it reaches the threat-intel adapters. That separation keeps the correlation engine, the SQLite-backed investigation store, and the API adapters as independent, testable services rather than one monolithic handler file.
The demonstrated setup connects NitroChat directly to the ThreatWeaver server running on NitroCloud: NitroChat discovers the five tools and two resources at connection time and invokes them as the conversation calls for them, without the investigation logic knowing anything about the frontend. NitroCloud handles the hosting and deployment path. The README's npm run deploy runs pre-flight checks, type checking, and tests before pushing, so the project's own infrastructure work goes into the threat-intel adapters and the correlation logic rather than server plumbing. Because it's a standard MCP server, the same tools also work from Claude Desktop or any other MCP-compatible client.
What the build demonstrates
ThreatWeaver was built for the Amrita University MCP Hackathon 2026, and its evidence is a working repository and a demonstrated tool-calling flow rather than production SOC deployment metrics. What it does show concretely is that MCP resources can carry investigation state across multiple tool calls well enough to support real follow-up questions, and that a correlation engine comparing IOCs pairwise on a handful of weighted attributes can surface coordination patterns that a single-IOC lookup would never reveal.
The reusable pattern
The useful idea here isn't "connect an AI to some security APIs." It's the separation between the tools that fetch new data and the resource that holds accumulated investigation state. Put the mutable, cross-call context behind a resource instead of asking the model to re-derive it from tool outputs each turn, and multi-step, correlated workflows, not just individual lookups, become possible.
If you want to see ThreatWeaver in action, check out the complete video here.
It walks through the MCP server, the threat-intelligence investigation workflow, how multiple IOCs are investigated and correlated across VirusTotal, AbuseIPDB, URLhaus, and Shodan, and how investigation state is preserved so follow-up questions can build on previous findings.
To explore the implementation in more detail, head over to the NitroStack docs for guides on building tools, resources, prompts, testing MCP servers in NitroStudio, and deploying them through NitroCloud.
Check out the complete ThreatWeaver source over here. You can also read the source and build your own stateful MCP application using the same SDK and workflow at nitrostack.ai.