Your rules and your Suricata build decide what the alerts say; the server's job is the round trip. What it removes is the manual part of that loop — capture in, alerts out, without leaving the client to run the binary and open the log yourself.
A server that puts a Suricata installation you already run behind three MCP tools. Give it a .pcap file and a folder for results, and it runs Suricata over the capture and returns the contents of fast.log — the alerts themselves, back in the conversation. It is your Suricata throughout: the install directory and executable name are set in config.py, and rule files you add to the Suricata rules directory apply on the next run.
- Alerts from a .pcap file: Suricata runs over the capture and the contents of fast.log come back to the client
- The version string of the Suricata binary the server is driving
- That binary's own CLI help, so the agent can see which options the build supports
- Your custom rule files, picked up from the Suricata rules directory on the next run
Suricata installed on the same machine — this server drives it, it does not bundle it. Its install directory and executable name go in config.py, and the project's Python dependencies are installed from its requirements file. No account and no key.