Most threat intel tools still punish you for asking a simple question.

You want to know whether an IOC is already known, what it correlates to, whether it belongs to a tagged campaign, whether there are sightings, and what export you can hand to another system. That should be one conversation with the platform. Instead, it usually turns into a scavenger hunt across five tabs, three filters, and one UI that clearly hates you back.

That annoyed me enough to build misp-mcp, an MCP server for MISP that lets an agent ask the platform directly.

Not in the vague “AI will fix everything” sense. I mean in the practical sense. Give the agent a tool surface that maps to the work analysts already do, keep the scope tight, and make the answers come from the actual threat intel system instead of a pile of copied notes.

This week I pushed the project a lot further.

What shipped this week

The big update is simple: the server is now broad enough to be genuinely useful, and tested enough that I do not have to cross my fingers every time I touch it.

This week I shipped:

  • expansion to 36 tools
  • Docker support
  • GitHub Actions for lint, build, test, and Docker verification on Node 20 and 22
  • expanded test coverage across the new tool modules plus live integration tests

The repo now exposes:

  • 36 tools
  • 3 resources
  • 3 prompts

And it covers the parts of MISP that actually matter in day to day work:

  • events
  • attributes
  • correlations
  • tags
  • exports
  • sightings
  • warninglists
  • objects
  • galaxies
  • feeds
  • organisations
  • server management

That means an agent can do more than just fetch one record and shrug. It can navigate the shape of the intel.

The real angle: less dashboard tourism, more direct questions

I think a lot of MCP demos are too cute.

They show that a model can call a tool. Fine. We already know that part. The interesting question is whether the tool surface is shaped around a real workflow or just a thin wrapper around an API spec.

Threat intel is a perfect place to be opinionated here.

If I am investigating an IOC, I do not want a magic trick. I want a direct path through a messy system:

  • look up the attribute
  • inspect related event context
  • check correlations
  • review tags and galaxies
  • confirm sightings
  • export what I need in the right format

That is the job.

So the point of misp-mcp is not “MISP, but with LLM glitter on it.” The point is that the agent can ask MISP the same kind of questions a human analyst asks, without making that analyst click through a small maze every single time.

Why the size of the tool surface matters

A sloppy tool surface is worse than no tool surface.

Right now people are finally paying attention to tool visibility, portability, and blast radius. Good. They should. Between sketchy supply chains, random wrappers, and half-baked integrations, the last thing I want is a giant fuzzy interface that can do everything badly and opaquely.

This is why I care about explicit tools.

When I say the server now has 36 tools, I do not mean that as a vanity metric. I mean the interface is becoming clearer and more inspectable. The agent gets concrete operations for concrete MISP tasks. That makes behavior easier to reason about, easier to debug, and frankly less spooky.

You can also see the shape of the platform more clearly this way.

MISP is not just a bag of events. It is relationships, enrichment structures, warninglists, sightings, taxonomies, galaxies, and exports that need to land in formats other systems can actually consume.

That is why I made sure the server includes support for things like:

  • MITRE ATT&CK galaxy integration
  • export formats including CSV, STIX, Suricata, Snort, text, RPZ, and hash lists
  • bulk IOC add
  • the correlation engine

If you are serious about threat intel workflows, those are not side quests. That is the job description.

Docker and CI are not glamorous, but they are the difference between a demo and a tool

I do not trust projects that stop at “works on my machine.”

Especially in security tooling.

This week I added Docker support and a GitHub Actions workflow that runs lint, build, tests, and Docker verification across Node 20 and 22. That sounds boring because it is boring. It is also what turns a weekend project into something another person can pick up without developing a personal relationship with your shell history.

The same goes for testing.

The README already documented unit and integration coverage, and this week I expanded test coverage across the new tool modules while also adding live integration tests around the bigger surface area. That matters because the failure mode for threat tooling is not just a broken button. It is a quietly wrong answer, which is much worse.

If a tool tells you an IOC is clean because the glue code is sloppy, congratulations, you have built software that lies politely.

I prefer rude software that fails loudly.

Why MISP is a strong fit for MCP

MISP already has the depth. The issue is access.

Analysts and defenders use MISP because it holds real intelligence structure: events, attributes, objects, sightings, galaxies, feeds, organisations, export paths, and correlation logic. But a lot of that value gets trapped behind the fact that humans have to manually traverse it, and traditional automations are often too rigid.

MCP gives a middle path.

You can expose a tight set of capabilities to an agent without pretending the model should freestyle its way through your environment. The model gets a defined interface. The platform stays the source of truth. You get answers grounded in the actual system instead of vibes and stale screenshots.

That is the part I find genuinely useful.

Also, if I can avoid teaching someone which of the four nearly identical menu paths hides the export they need, I will take that win every time.

Built with boring choices on purpose

The stack here is intentionally straightforward:

  • TypeScript
  • Node 20+
  • MCP SDK 1.x

That was not an accident.

There is a lot of justified paranoia right now around tool reliability and dependency risk. I am not claiming JavaScript is spiritually pure or that any ecosystem is immune to nonsense. It is software. Nonsense is undefeated. But I do think there is real value in keeping the implementation legible, mainstream, and easy to run.

The goal is not novelty in the stack. The goal is reducing friction between “this looks useful” and “this is now running in my environment.”

Where I think this goes next

The bigger idea behind this project is simple: agents are most useful when they can interrogate systems directly, through visible and well-scoped capabilities, instead of forcing humans to be the translation layer.

Threat intel is full of that translation tax.

A human notices a suspicious hash, digs through MISP, checks correlations, looks at ATT&CK context, reviews sightings, maybe exports a format for another control, and then summarizes the result elsewhere. That flow is exactly where a good tool interface helps.

Not by replacing analysis. By removing the dumb parts that waste analysis time.

That is what I am building toward with misp-mcp.

Not a shiny dashboard replacement. Not a vague “cyber AI” pitch. Just a direct interface so the agent can ask the platform useful questions, and the human can spend more time deciding what matters.

That feels like a better use of both machines and eyeballs.

And yes, I still think five clicks to answer one IOC question is ridiculous.

It was ridiculous before MCP. It is even more ridiculous now.