nano SIEM
Agents & MCPInvestigator

Investigator

nano-investigator: an MCP server that turns a coding agent into a SOC analyst workstation over the nano SIEM

Investigator

nano-investigator is an MCP server that exposes the nano SIEM's analyst surfaces to a coding agent (Claude Code, or any MCP client) over stdio. It registers 69 tools, five MCP prompts, and a set of MCP resources, then proxies each call to two nano backends: the main API and the search service. The agent drives search, triage, investigation, threat hunting, and parser authoring through natural language while the server handles the SIEM API calls.

A typical session looks like a conversation against your data:

  • "how many alerts fired today?" runs get_alert_counts
  • "what do we know about 10.5.2.40?" runs get_entity_context plus a scoped search
  • "investigate alert 456" runs the investigate_alert prompt
  • "who are the riskiest entities right now?" runs get_risky_entities
  • "build a parser for these logs" runs the build_parser prompt

How it differs from nanodac

nano-investigator and nanodac sit on opposite sides of the detection lifecycle and run side by side as separate MCP servers, sharing the same environment variables.

nanodacnano-investigator
RoleDetection-as-code authoringSOC operations + parser authoring
WorkWrite, validate, and deploy detection rulesSearch, triage, investigate, hunt, build parsers
DetectionsReads and writesReads only
Default postureWrites to the SIEMRead-first; writes cases, notebooks, and parsers

Detection-rule editing stays in nanodac. nano-investigator only reads detections; for the authoring side, see Detection-as-Code.

Log-source parsers can be authored two ways, and neither uses nanodac's tools (nanodac is detection-only). The version-controlled path drafts a parser.yaml against the nano-rs/parsers repo and validates it with the vector vrl CLI, then ships by PR or UI import — see Authoring parsers. The interactive path, new here, authors and deploys a parser directly against a live tenant over MCP — see Build parsers.

The surface at a glance

The 69 tools cover these areas:

AreaToolsAccess
Search & schema9Read, plus save_search and create_shared_search
Alerts & triage3Read-only
Cases12Read, plus 7 write tools (merge_cases is destructive)
Notebooks9Read, plus 5 write tools
Detections & MITRE5Read-only
Entities & risk3Read-only
Enrichment / IOC2Read-only
Prevalence3Read-only
System / org4Read-only
Parsers19Read, plus author, deploy, and import

Most of the surface reads. A few tool groups write:

  • Cases can create, update, change status, assign, attach alerts, post wall entries, and merge. merge_cases is the one destructive operation: source cases are closed as merged, so the agent should confirm before running it.
  • Notebooks can create, append entries, add references, update, and share.
  • Parsers can create, update, and deploy log-source parsers, wire routing rules, and import from a parser repository. Deploy changes what Vector ingests, so the build_parser prompt confirms before deploying and verifies with get_log_source_health. See Build parsers.
  • Search can write in two narrow cases: save_search and create_shared_search.

Alerts cannot be mutated. There is no acknowledge, close, or assign tool for alerts; triage happens by adding an alert to a case.

Alongside the tools, the server registers:

  • 5 MCP prompts: investigate_alert, hunt_entity, hunt_campaign, morning_briefing, and build_parser. These are structured workflows the agent follows, not callable tools.
  • MCP resources: an SQL guide, the UDM schema, an nPL reference, a VRL parser reference, and seven playbooks. See the Tool Reference for the full list.

The full tool inventory, with parameters and access level for each, lives in the Tool Reference.

Where to go next

On this page

On this page