Giving NetPulse a voice with MCP
I wanted to be able to ask Claude about my network and actually get useful answers, so I added an MCP server to NetPulse.
I wanted to be able to ask Claude about my network and actually get useful answers, so I added an MCP server to NetPulse.
NetPulse already had a REST API. You could query devices, pull BGP session states, look at NetFlow data, all of that. But the API is meant for machines, not for a conversation. If I wanted to ask "why did my BGP session to AS1234 flap last night?", I would have to open the dashboard, dig through the BGP events tab, cross-reference the timestamp with whatever else was going on. Totally doable. Not fun.
Model Context Protocol (MCP) is a standard that lets you expose tools to an LLM in a structured way. Instead of pasting API output into a chat window and hoping for the best, the model can call tools directly, look at the results, and reason about them. It's the difference between handing someone a stack of printouts and letting them search the system themselves.
Adding MCP to NetPulse
NetPulse is written in Go, so I used mark3labs/mcp-go to handle the protocol. Each tool is a function that takes a request and returns a result. The MCP server mounts itself on the same HTTP server as the rest of the NetPulse API, so there's no separate process to manage.
28 tools and what they cover
I ended up registering 28 tools. That sounds like a lot, but most of them map directly to things you would already do by hand in the dashboard.
Device and interface tools let the model list all monitored devices, pull interface traffic stats, and dig into SNMP details. BGP tools cover active sessions, recent events, prefix visibility, and a looking glass that can query the routing table for a specific prefix or ASN. NetFlow has a query tool with a full set of filters (source/destination IP, ASN, protocol, port, interface) plus an aggregate statistics view. Then there are alert management tools and health reporting, which generates a full analysis of the network's current state.
The health report one is probably the most useful. It pulls together everything NetPulse knows and produces a structured summary. When I ask Claude "how is the network looking?", it calls that tool first and works from there.
What it actually looks like
Here are a few real interactions against my live network.
> Are all my BGP sessions up?
Yes, all sessions are established across all four routers. You have transit via
Vultr in NYC, iFog in Ashburn, and Securebit in Amsterdam, plus IX peers at
BGP.Exchange and SBIX. The longest-running session is the Vultr peer at
nyc-edge-01, up since March 20.
> Any active alerts I should know about?
One critical alert worth your attention: the ROA for 2601::/20 (AS7922,
registered at ARIN) expires in 24 hours, at 2026-03-28 14:00 UTC. That's not
your prefix, but once it expires your RPKI validator will start rejecting it,
which affects routes you receive from that origin. The rest of the active alerts
are older BGP prefix visibility events and a device recovery on fw-01-jc01 from
earlier this month, all resolved.
> Where does traffic to 2606:4700:4700::1111 go right now?
Traffic to 2606:4700:4700::1111 exits through your Vultr transit in NYC. The
route is 2606:4700::/32 via AS13335 (Cloudflare), next hop 2001:19f0:ffff::1
on nyc-edge-01. AS path is 215855 → 64515 → 13335.
The pattern is the same across all the tools. You ask a question in plain language, Claude figures out which tools to call and in what order, and then reasons about the results and tells you what actually matters. The raw JSON never surfaces.
Wiring it up to Claude
Once NetPulse was running with MCP enabled, connecting Claude Code to it was one command:
claude mcp add --scope project netpulse-home --transport sse http://10.63.21.10:8080/mcp/<path>
After that, Claude had access to all 28 tools. It can now list my BGP sessions, check if any alerts are active, query NetFlow for traffic to a specific ASN, look up a prefix in the routing table, all in the context of a conversation. I can ask follow-up questions and it already has the context from the previous tool calls.
That was the missing piece. Not just having data available, but being able to reason across it.
Conclusion
There is a gap between data being available and data being useful. Being able to ask natural language questions and get answers that draw on multiple data sources at once closes that gap in a way the REST API alone never did.
It also serves as a good reminder that Claude is not just a tool for writing code. Give it the right context and the right tools, and it becomes just as useful for understanding your infrastructure, debugging problems, or making sense of data you already have.
NetPulse started as a project to replace MRTG and grew from there. This feels like the next natural step. The monitoring data was always meant to help me understand my network. Now it actually talks back.