Built an MCP server for Malcolm, looking for feedback on what tools matter

[nagameTW]

I put together an MCP server for Malcolm and would like feedback from people who run it day to day, since I'm not sure I've picked the right surface to expose.

Background, in case MCP is new to anyone here: the Model Context Protocol lets an AI agent (Claude, and others) call structured tools instead of writing raw queries. The reason I built this: pointing an LLM straight at Malcolm's OpenSearch index doesn't work well. The field names aren't standard, the index has its own filter syntax, and the model can't check whether a field exists before it queries, so it invents field names and writes DSL that returns nothing.

What I have so far exposes Malcolm's filter syntax, field discovery (the agent checks names before querying), field-value enumeration, Suricata alert queries with the suricata.alert.* vs rule.* mapping handled, NetBox asset lookup, and Arkime tools (session search and detail, unique values, SPI graph/view, and a connection graph). Read-only by default; writes like alert creation, session tagging, hunts, and PCAP upload are each behind their own env flag, off unless enabled, with an audit line per attempt.

The questions I actually want to ask this group:

1. For the read side, is there a Malcolm or Arkime endpoint you reach for constantly that would be worth wrapping? I skipped the ops/cluster-stats endpoints as not useful for hunting. Was that right?
2. Does the read-only-by-default, opt-in-writes split match how you'd want an agent touching a live Malcolm instance, or is even opt-in writing a non-starter in your environment?
3. Any field-mapping quirks beyond the Suricata one that trip people up and would be worth handling in the tool layer?

Repo is here if you want to look at the tool list: https://github.com/nagameTW/mcp-server-malcolm (pip install mcp-server-malcolm). Grateful for any thoughts.

[mmguero]

Hey, thanks for reaching out! We actually have a team here at INL that's working on something that might overlap with this some, I will try to get their eyes on this and see if they can offer their insights.

As far as some things that might help you:

• I wrote both this dashboards reference (markdown) and, to some extent, this query language guide (markdown, see also the external links in this one) with the main goal of this being something that could help an LLM formulate sane queries, navigate sensibly, filter usefully, etc. Maybe that could be of use to you.
• Yeah, I think skipping the ops/stats stuff is the right call. As far as endpoints we constantly reach for, I would say for hunt/IR that depending on the scenario stuff across Dashboards and Arkime are all pretty much used a lot. There are some APIs exposed as well that might be helpful for you? The aggregation API can also be useful to do easy bucketing aggregations (for example, here are OUIs grouped by network protocol). There's also one to get the entire list of known fields.
• The idea of read-only by default and writes opt-in is a good approach, I think. See role-based access control for some of the stuff we have related to fine-grained permissions.
• Field mapping is a royal pain in the butt, especially when dealing with disparate data sources. Looking in logstash/pipelines is probably a good way to find things (for example, here is where I normalize suricata.alert.* into rule.* when appropriate).

I'll see if I can get the guys on my team working on our LLM feature right now to chime in.