DEV Community

Cover image for Why Your Network Devices Need an MCP Server - Part 1
Uzi Golan
Uzi Golan

Posted on

Why Your Network Devices Need an MCP Server - Part 1

#mcp #networkautomation #ai #netdevops

This is Part 1 of a 7-part series on AI-assisted network operations with MCP and Agent Skills.

From private chatbots to shared, reusable infrastructure: MCP servers, Agent Skills, knowledge catalogs, and safety models that turn AI into a real network operations teammate.

Table of Contents

Today, every engineer who uses AI works in a private silo. A support engineer investigates an alarm in a personal chat. An architect designs a solution in another. A developer debugs in a third. The AI knowledge gained in each conversation dies when the chat closes. Skills and MCP servers are built by one person, used by one person, and never become company assets.

Meanwhile, most teams building AI applications weave the prompt, the data access, the retrieval logic, and the safety checks into a single codebase that can't be decomposed or shared. When the framework falls out of fashion, they rebuild from scratch.

There's a better way. The Model Context Protocol (MCP) and Agent Skills create modular, composable blocks each with a clear boundary. You build them once, share them across teams, and adapt them when the technology landscape changes. This article explains why network engineers should care, what the landscape looks like today, and what becomes possible when you connect AI to real equipment the right way.

The Problem: AI That Can't Touch the Network

Here's what happens today when a network engineer tries to use an AI assistant for real work:

Scenario 1 "Show me the active alarms on sf-163-187."
The engineer copies the CLI output, pastes it into the chat, and asks the AI to interpret it. The AI guesses at alarm meanings based on general networking knowledge. It doesn't know the vendor's alarm dictionary. It doesn't know which alarms block configuration work. It gives a plausible-sounding answer that may or may not be correct.

Scenario 2 "Design an ERP ring across three ETX-2 units."
The engineer describes the topology to the AI. The AI produces a generic ERP ring configuration maybe close enough for a textbook, but not paste-ready for a specific firmware version. Port naming conventions differ by family. The configure protection erp syntax varies. The AI doesn't know what it doesn't know.

Scenario 3 "Change the location string on sf-163-187 to TLV lab rack 3."
Nobody would let an AI make a configuration change on a production switch. And they're right not to there's no safety net. No backup. No diff preview. No approval gate. No audit trail. The risk is unacceptable.

All three scenarios share the same root cause: the AI has no connection to the device and no knowledge of the device. It's answering from training data, not from your network's reality.

But there's a deeper problem: even if one engineer solves these scenarios in their personal AI chat, the next engineer who faces the same problem starts from scratch. The investigation, the knowledge, the safety rules none of it is shared. Every engineer rebuilds the same context, discovers the same pitfalls, and produces answers that die when the chat closes.

From Personal AI to Team AI

The shift isn't from "no AI" to "some AI." It's from personal AI to team AI from "can one engineer use AI" to "can a team share AI investigations, knowledge, and infrastructure."

This isn't theoretical. The vision looks like this: a shared workspace where multiple engineers and AI agents work on the same investigation. People contribute from different roles support, architecture, development and specialized agents handle different domains: a network agent connects to devices via MCP, a documentation agent searches manuals and release notes, a development agent searches Git history and Jira. One shared investigation, multiple agents, visible sessions, and structured output that combines root cause, supporting evidence, CLI output, related issues, manual references, and recommended action.

This is the difference between "another chatbot" and infrastructure. Skills and MCP servers should be company assets, not personal tools. An MCP server on one laptop is a prototype. An MCP server plus a collaboration hub where multiple engineers can queue tasks to multiple AI agents, see every investigation, and resume any session is infrastructure.

This is the difference between

Figure 1 the difference between "another chatbot" and infrastructure

When a support engineer opens a case on a device that lost a critical feature after a firmware upgrade, three roles collaborate: the support engineer checks the device state, the architect validates the expected behavior against the design, and the developer checks the commit history and known issues. Three AI agents support them a network agent (device CLI + SNMP), a documentation agent (manuals + release notes), and a development agent (Git + Jira + CI). The agents work in parallel, each in its own terminal tile, and the team sees all three in one view. The structured output root cause, evidence, CLI output, Jira issue, manual references, recommended action is assembled from all three agents' work.

What MCP Actually Is (For Network Engineers)

MCP is an open protocol introduced by Anthropic in late 2024 and now governed as a community project at modelcontextprotocol.io that standardizes how AI applications connect to external systems. As the NetPilot MCP guide for network engineers puts it, if you've ever wished vendor APIs shared one schema language the way SNMP promised with MIBs, MCP is that idea done for AI agents and adoption has broadened across major AI and developer tools, including Claude, GitHub Copilot, OpenAI Codex, Cursor, and JetBrains.

The protocol specification defines three transports: stdio (local subprocess, the default for desktop hosts), Streamable HTTP (single endpoint for remote/multi-tenant), and SSE for backwards compatibility. The architecture is straightforward:

  • MCP servers wrap a system (a device CLI, an SNMP stack, an inventory file) and expose three things: tools (typed, callable functions), resources (readable data), and prompts (reusable templates).
  • MCP clients live inside AI applications Claude Code, Claude Desktop, GitHub Copilot, OpenAI Codex and connect to servers over stdio (local) or streamable HTTP (remote).
  • The AI model never talks to your device directly. It sees a list of tool definitions with JSON schemas, decides which to call, and the client executes the call through the server. The server not the model decides what gets exposed and what doesn't.

That last point matters more than it sounds. The server is the gatekeeper. It can whitelist read commands, refuse writes without explicit confirmation, redact credentials from responses, and log every action to an audit trail. The model can't bypass these controls because the controls live in the server, not in a prompt.

Figure 2 — The MCP server is the gatekeeper the model never talks to the device directly

If you've built network automation with Python and Netmiko before, think of it this way: MCP is the layer that turns your existing scripts into something an AI agent can discover, understand, and call safely without you hardcoding workflows. The AI decides which tools to chain together based on what you asked. You decide what the tools can and cannot do.

The Landscape Today: Who Has MCP Servers for Network Devices?

I spent time surveying the existing landscape before building my own. The survey below is based on public GitHub repos and vendor documentation found via web search in July 2026 treat it as a starting point for your own research, not a production endorsement. Review each project's auth model, write scope, and audit logging before pointing anything at real equipment.

Here's what's out there as of mid-2026:

Cisco (widest coverage)

Cisco's RADkit remote-automation SDK has an MCP server under the CiscoDevNet GitHub org device inventory, CLI execution, config commits via certificate-based auth. It's labeled "not an official product" but lives under Cisco's own org. There are also community servers wrapping pyATS/Genie for structured show-command parsing, and lighter-weight network-assistant servers for routing policy and device-health lookups. Cisco has the widest coverage of any vendor.

Juniper (best vendor-official support)

Juniper maintains an official MCP server in their own GitHub org stdio and streamable-http transports, Docker image, token-based auth. Supports operational queries and config load/commit. They also have a routing-director MCP server for Paragon Automation at the controller level. The community has built PyEZ-based servers tested with VS Code/Copilot as well.

Palo Alto Networks

Palo Alto Networks publishes an official server but it's a security relay for MCP traffic (Prisma AIRS), not a PAN-OS device management tool. The device-management side is covered by community servers: read-only mode toggles, regex-validated inputs against XPath injection, explicit two-step write-commit flows, and one server with .mcpb Desktop Extension support and OS-keychain credential storage.

Arista

An official-adjacent CloudVision MCP server bridges Claude/agents to CloudVision's REST API. Community servers wrap Netmiko for Arista labs with TOML device inventories, show/VLAN/BGP/LLDP queries, and health-check prompts across spine/leaf fleets.

Fortinet

Community servers cover FortiOS 7.6.x with 200+ typed tools, async HTTP clients, and security-first defaults. A FortiManager MCP exists for centralized policy/device management with built-in safety checks.

Others

MikroTik has the most crowded field six community servers, including MikroMCP with 117 typed tools, dry-run previews, per-router circuit breakers, and RBAC. Huawei VRP has a gap no mature MCP server exists for physical hardware, though a NAPALM driver for VRP provides the building block to wrap. Linux/Windows shell MCP servers exist but are host-management, not network-device tools.

The cross-vendor pattern

Most of these servers share common safety patterns worth copying: read-only environment variable toggles, dry-run/diff-before-commit flows, whitelisted commands over raw shell strings, and audit logging with secret redaction. And for multi-vendor coverage, Netmiko/NAPALM device type strings map directly arista_eos, cisco_ios, huawei_vrp, junos, rad_etx are all supported Netmiko platforms, so a single wrapper can cover multiple vendors from one codebase.

Why Build Your Own?

With all these existing servers, why would you build your own? Six reasons:

1. Your devices aren't covered

If you work with equipment from a vendor that has no MCP server and many don't you have no choice. I work with RAD Data Communications devices (ETX-2, SecFlow, Megaplex, MiNID). Search for "RAD MCP" and you find unrelated projects: RAD Security (Kubernetes), Cisco RADkit (different product), Radicle (git). Nothing for RAD equipment. The practical path is the same as Huawei: wrap Netmiko's rad_etx device type in your own thin MCP server.

There's also a strategic angle: being the first to publish an MCP server for your vendor ecosystem positions you as an AI-based operations vendor, not just a device manufacturer. The toolkit becomes embeddable in your existing management platform RADview in this case and differentiates your product line in a market where every vendor is being asked "what's your AI strategy?"

2. The knowledge is the product, not just the tools

An MCP server that can run show commands is useful. An MCP server paired with a skill that knows your device's firmware-exact CLI reference, alarm dictionary, config hierarchy, and operational best practices is transformative. In the material I've found, existing servers expose the tools to talk to devices none of them ship the knowledge of what to check, in what order, what "good" looks like, and what commands are safe.

This is the gap that Agent Skills fill. Agent Skills (the SKILL.md open standard, now documented by Anthropic and supported by Claude, Copilot, and Codex) are filesystem-based knowledge resources that auto-load into AI agents. They're not code they're structured expertise: ordered diagnostic sequences, real config patterns, anti-patterns to avoid, and safety rules the agent must follow. A skill turns a generic AI into a specialist.

Without skills, Claude gives you textbook answers. With skills, it gives you the ordered diagnostic sequence an experienced engineer would follow, the exact commands to run, what the output means, and the anti-patterns to avoid as the claude-network-skills project puts it, "the difference shows up immediately."

3. You control the safety model

When you build your own server, you design the safety model from the ground up:

  • Read operations are whitelisted only approved command prefixes, no raw shell strings.
  • Write operations follow a staged-commit flow: backup the running config, stage the changes, show a diff preview, wait for explicit human approval, commit, then verify. On some device families (like the Megaplex-4), a mandatory recipe is server-enforced: discard-changes → configure → sanity-check → commit → save.
  • Dangerous operations (reboot, factory-default) are excluded entirely not just guarded, but out of scope.
  • Credentials never appear in inventory files, tool arguments, or responses they live in environment variables or OS keychain only.
  • Every action is logged to an append-only audit trail with credentials redacted.
  • A read-only toggle can disable all write tools at registration time useful for demos, training, or restricted environments.

These are the same safety primitives documented as patterns worth copying in the vendor baseline survey that informed this project. An IETF Internet-Draft from Huawei also proposes consent workflows, audit trails, and LLM isolation for MCP-based network management a sign the standards community is taking this seriously.

4. Building for a team, not just for yourself

An MCP server built for one engineer on one laptop is a prototype. An MCP server built for a team with HTTP transport so multiple engineers connect to one instance, token-based access control so each person gets the right permissions, a shared knowledge catalog so everyone gets the same firmware-exact answers, and an audit trail so every AI-driven action is traceable that's infrastructure.

The rad-collab-hub project demonstrates this in practice: a web platform where multiple AI agents run side-by-side in tiled terminals, a shared task queue auto-dispatches work to idle agents, and a session browser makes every investigation visible, tagged, and resumable. A support engineer queues a device investigation. An architect adds a design question. The AI agents work on both in parallel. Neither engineer waits for the other, and neither investigation is lost when the chat closes.

5. Good infrastructure reduces model requirements

A well-designed MCP server with bounded query tools and a thin skill layer doesn't just make the AI smarter it makes it cheaper to run. When the infrastructure handles exact lookups, structured retrieval, and validation, the model's job shrinks from "understand everything about this device" to "read these structured results and compose a response."

Every design decision that moves intelligence from the model to the infrastructure also reduces token consumption:

  • Bounded MCP queries return 10 results, not the whole catalog smaller context
  • Skills embed 5 critical rules, not a 50-page manual less system prompt overhead
  • SQLite FTS5 exact lookup instead of loading entire manual chapters no 180KB in context
  • Strict JSON schema output the model produces structured data, not free-form essays
  • Validation in code, not in the model no corrective reasoning passes needed
  • Knowledge served from a catalog, not bundled in skill files thin skills (56KB) instead of bundled references (14MB)

That means fewer tokens, lower API costs, and the ability to run with smaller or self-hosted models. Organizations with data sovereignty requirements can run open-weight models locally the knowledge lives in the SQLite catalog, not in the model's weights. Teams on a budget can use smaller API models the bounded queries keep token costs low. Good infrastructure is the equalizer.

6. Internal organizational benefits

The toolkit isn't just a technical asset it changes how the organization works. Six benefits surfaced during the POC:

  • Budget savings routine work shifts from expensive expert hours to AI-assisted workflows. Automatic config backups prevent costly outages.
  • Faster turnaround answers in seconds, as paste-ready CLI blocks. A new device is onboarded independently in minutes, not days.
  • Manpower leverage a junior engineer or an AI agent performs veteran-level work because the knowledge catalog and skills encode the expertise. Less dependence on the few people who know the quirks.
  • Process discipline one path for every change: check, backup, stage, approve, execute, verify with permissions and audit. No more ad-hoc SSH sessions with no trail.
  • Skills growth every answer cites its source: which command, which chapter, which constraint. Engineers learn from verified flows the AI teaches by example, like a mentor. New team members ramp up faster by reading the cited references.
  • Knowledge surviving turnover when the senior engineer who knows the ETX-2's ERP timing quirks leaves, the knowledge doesn't leave with them. It's in the catalog, versioned in Git, available to the next person. Expertise becomes an asset, not a person-dependent liability.

These aren't product features they're organizational transformation. The MCP server is the tool; the knowledge catalog is the asset; the safety model is the policy. Together, they change how the team operates.

Lego Blocks, Not Monoliths

Most AI applications today are built as monoliths. A team uses LangChain (or LlamaIndex, or raw prompt engineering) to build "the ERP diagnostic app" and the prompt, the retrieval logic, the data access, the safety checks, and the output formatting are all woven into a single codebase. The app works. But the knowledge is trapped inside it. The safety rules are coupled to the app's logic. The device access is custom. No other team can reuse any of it without copy-pasting code and the copies drift.

Skills and MCP take a different approach. Each capability is a self-contained block with a clear boundary:

Block What it contains Reusable across
MCP server (device access) SSH/SNMP/NETCONF tools, safety gates, command whitelists Any AI client that speaks MCP
Skill (domain policy) "For ERP, check ring state before node state; these 5 OIDs are the minimum" Any MCP server, any AI client
Knowledge catalog (structured data) MIB objects, CLI references, manual chapters, datasheet sections Any tool that queries SQLite
AI client (reasoning layer) The model that reads results and composes answers Swappable the blocks don't care which model you use

A LangChain app is a sculpture beautiful, but you can't take it apart and build something else. Skills and MCP are Lego blocks you build, unbuild, recombine, and share.

Team A builds an "ERP ring diagnostics" workflow using the MCP server, an ERP skill, and the MIB catalog. Team B needs a "firmware upgrade validation" workflow. They reuse Team A's MCP server. They reuse the same MIB catalog. They write a new skill (firmware validation policy) and compose it with the existing blocks. Shipping time: days, not months. Try that with a LangChain app you'd be copying code, rewriting prompts, duplicating safety logic, and praying the two versions don't drift.

Infrastructure survives technology shifts

AI interaction with data is evolving rapidly. Today MCP is the emerging standard. In two years, it might be something else a new protocol, a new abstraction, a new way for models to access external data. This isn't speculation; it's the pattern of every technology cycle. REST replaced SOAP. GraphQL challenged REST. Each shift required rebuilding data access layers.

Applications built directly on today's frameworks are optimized for today's paradigm. When the paradigm shifts, you rebuild from scratch because the knowledge, safety, and access logic are tangled together inside the app. A LangChain app from 2023 is already showing its age.

Skills and MCP create a separation of concerns that makes the infrastructure adaptable:

Layer Survives a paradigm shift?
Knowledge layer (SQLite catalog, MIB compiler, manual splitter, datasheet ingester) Yes the data and its structure don't change when the transport changes
Safety layer (staged commits, confirmation gates, audit trails) Yes safety rules are domain rules, not transport rules
Skill layer (distilled domain policy) Yes policy is expressed in natural language, not tied to a protocol
Transport layer (MCP today, possibly something else tomorrow) Swappable replace this layer without touching the others

When the next protocol arrives, you replace the transport layer. The knowledge catalog stays. The safety rules stay. The skills stay. You adapt by changing the interface, not by rebuilding the infrastructure.

This isn't theoretical. In July 2026, the MCP spec released a major revision (2026-07-28) that removed the stateful initialize handshake, eliminated HTTP sessions, introduced a mandatory server/discover RPC, and replaced sampling/roots/elicitation with Multi-Round-Trip Requests. For a monolithic LangChain application that hardcoded MCP client behavior, this means rework finding every call site that assumed sessions, rewriting sampling callbacks, updating resource subscription logic.

For the modular infrastructure described in this series, the migration is confined to the transport layer: implement one new RPC handler (server/discover), remove the initialize handler, add two metadata fields (ttlMs, cacheScope) to list results. The knowledge catalog untouched. The safety model untouched. The skills untouched. The driver abstractions untouched. The audit trail untouched. A few hours of transport-layer work, and the same verification ladder from Part 6 proves nothing broke: the gold-standard MIB prompt still returns the same OID and source hash, the staged-commit flow still refuses without confirmation, the tools-status matrix still shows the same tools. Applications are built for a point in time. Infrastructure is built for a timeline. Both are legitimate but know which one you're building.

An MCP Server Is Grown, Not Shipped

Building an MCP server that can SSH to a device and run show commands is a weekend project. But the first version of your MCP server will be wrong. Not broken wrong in the sense that it won't have the tools you actually need, because you can't predict what engineers will ask until they start asking.

The toolkit behind this series went through the same evolution. It started with basic read tools (run_show, get_config, health_check). Real usage revealed the gaps:

  • New tools appeared because engineers asked questions the existing tools couldn't answer. "Can the AI check SNMP?" led to snmp_probe, snmp_get, snmp_walk. "Which card gives me 16 E1 ports?" led to the datasheet layer. "What does this alarm mean?" led to the manual ingestion pipeline.
  • Tools were enhanced because a tool that worked for one device family broke on another. The run_show command needed per-family whitelists some families have dangerous commands that look like show commands. Port naming is family-specific: a SecFlow uses ethernet 3, an ETX-1p uses ethernet lan1, an ETX-2 uses ethernet 0/2. The tool had to learn each family's dialect.
  • Safety rules were refined because real device operations exposed edge cases. The Megaplex-4 requires a mandatory discard-changes → configure → sanity-check → commit → save recipe discovered only when staging a config change on a real device.
  • The knowledge layers grew because questions spanned beyond what the current layers covered. The CLI reference exists because someone asked "what commands does this device support?" The MIB catalog (35,977 objects) exists because someone asked "can the AI check the ERP state without opening an SSH session?" The datasheet layer exists because someone asked "which card has 16 E1 ports?" Each question was a gap. Each gap became a tool.

None of these were planned upfront. Each was discovered through usage.

Internal verification before external release

Before publishing anything externally, the toolkit was proven internally. A POC put the toolkit in the hands of six roles each with a different job, each stressing the toolkit differently:

  • Device developers faster debugging, config experiments, and CLI discovery without memorizing syntax
  • NMS developers device behavior, MIBs, and APIs answered instantly while building management features
  • Test engineers repeatable health checks, config validation, and consistent automated test setups
  • Sales product variants, ordering options, and feature answers without waiting for an expert
  • Technical support faster root-cause analysis using live device state + knowledge in one conversation
  • Pre-sales instant answers on limits and competitive positioning during customer discussions

Each role exposed different gaps. Sales needed datasheet lookups that engineers never asked for. Test engineers needed repeatable health checks that revealed family-specific SSH fragility. Pre-sales needed comparison prompts that drove the cross-family capability grounding rule. The POC wasn't a demo it was a stress test that shaped the toolkit into something useful for the whole organization, not just the network engineering team.

The principle: internal usage is the proving ground. The product goes through internal verification before external release. Every gap discovered by a real user a salesperson, a test engineer, a support agent becomes a tool, a filter, or a safety refinement. You don't publish the toolkit and hope it works. You prove it internally, fix what breaks, and then share it.

Fetch tools need filtering that usage reveals

Every data-fetching tool starts naive: "get the data, return it." Then real usage exposes the problem the data is too much, too broad, or shaped wrong for how engineers actually ask questions.

The evolution follows three directions:

  • Scope filtering "give me less, but the right less." The first version of every fetch tool returns too much. Engineers don't want "everything about ERP" they want "the ERP status on this specific device, this specific ring, this specific node." A show command that returns 20 lines on one device family returns 2,000 on another. The tool learns to filter by family, by context, by firmware.
  • Shape filtering "give it to me structured, not raw." Raw CLI output is verbose and hard for the model to parse. Real usage drives the evolution: parse the output into structured JSON, extract only the meaningful fields, return a compact representation. The same happens with SNMP raw walk output becomes a decoded table with enum values, not raw BER-encoded values.
  • Granularity filtering "give me the right level of detail." One tool can't serve every question. "What is ERP?" needs the manual chapter. "What's the ERP state on device3?" needs a bounded SNMP poll. "Which OIDs are relevant to ERP?" needs a MIB catalog search. Each question type demands a different granularity and you discover the granularities only when engineers ask questions the existing tool can't answer well.

Every filter reduces tokens. When a fetch tool returns 10 bounded results instead of 500, the context is 50x smaller. When output is parsed into structured JSON instead of raw text, the model doesn't waste tokens parsing verbose CLI formatting. Good filtering is the single biggest lever on token consumption and it's discovered through usage, not designed upfront.

What Becomes Possible

Here's what changes when an AI agent has both the tools to reach your devices and the knowledge to understand them. These examples are from the a project, tested against real lab equipment.

The POC identified nine usage domains from simple knowledge lookup to full multi-layer fusion:

Domain Example Query
User Manual "How does zero-touch work on MiNID?"
Datasheets "Compare ETX-2i 10G vs 100G ports"
Device Management "Add lab-etx2 and run health check"
CLI Operations "Show active alarms on sf-163-187"
SNMP Operations "Walk IF-MIB and summarize errors"
Network Engineering "Design a 3× ETX-2 ERP ring config"
Advanced "Compare ETX-2 vs ETX-2V on QoS"
Onboarding "Harvest CLI of a new family"
Fusion "Unbox → inventory → health → location"

Each domain exercises different layers of the toolkit manual and datasheet lookups hit the knowledge catalog, CLI and SNMP operations hit the MCP tools, network engineering combines knowledge with design skills, and fusion prompts span every layer in one request. The examples below show what that looks like in practice.

Ask in plain language, get grounded answers:

"Show the active alarms on sf-163-187"

The agent navigates configure reporting → show active-alarms and interprets severity. A major or critical alarm blocks config work by policy. The agent explains what each alarm means using the vendor's alarm dictionary not a guess from training data.

Design from real references:

"I have three ETX-2 units in a ring running ERP give me the configuration for all three"

The agent grounds its answer in the harvested CLI reference for that firmware version and the manual's protection chapter. Ring-port roles, RPL owner/neighbor placement, per-unit paste-ready config blocks, and the verification reads (show erp status) all from real device knowledge, not a textbook.

Make changes safely:

"Change the location of sf-163-187 to TLV lab rack 3"

The agent backs up the running config, stages the change, shows you a diff preview, waits for your explicit approval, commits, and then verifies. On Megaplex-4 devices, the mandatory MP recipe applies and is server-enforced: discard-changes → configure → sanity-check → commit → save. You see every command before it runs. Nothing touches the device without your confirmation.

Probe device identity over SNMP:

"Check SNMP on etx2v-1 and report its exact firmware, sysObjectID, and detected family"

The agent uses snmp_probe to read the MIB-II system identity and compare the returned sysObjectID with the toolkit's family map. A quick way to confirm device identity and firmware without opening an SSH session.

Query the MIB catalog (the gold standard):

"Describe RAD-EthIf-MIB::erpNodeState give the exact OID, syntax, enum values, description, and source provenance"

A correct answer returns the enterprise OID (1.3.6.1.4.1.164.*), enum values, table context, and a source sha256 none of which is guessable from training data. To verify the catalog served it (not training memory), tail the audit log: each call logs a mib_search / mib_describe line.

Fuse every layer in one prompt:

"We just unboxed a SecFlow-1p confirm its power and temperature specs from the datasheet, add it to the inventory as sf-new at 172.17.163.200, run a health check, verify its identity over SNMP, and set its location to OT cabinet 2"

One prompt, every layer in order: datasheet lookup (offline) → the six-fact intake gate → health_check → snmp_probe identity cross-check → the staged config flow for the location write. No context switching, no copy-paste between tools, no manual handoff between steps.

Onboard a new device family in 30 minutes:

"We just received a new Megaplex-4 harvest its CLI, ingest the manual and datasheet, and load the MIB"

This is where the toolkit's automation pipeline shines. You hand it four things one live device (reachable over SSH), the user manual (PDF), the datasheet (PDF), and the MIB file (.mib) and the pipeline does the rest:

  1. CLI harvesting (5 min) the harvester connects to the live device, walks its command tree, and extracts every supported command with its syntax, arguments, and output structure. The result is a firmware-exact CLI reference not a manual page, not a guess, but the actual command set the device responds to right now.
  2. Manual ingestion (5 min) the PDF is parsed, chunked by chapter, and loaded into the SQLite FTS5 catalog. The chapter structure is preserved when someone asks "how does zero-touch work on MiNID?" the answer comes from the exact chapter, not a full-text scramble.
  3. Datasheet parsing (5 min) the datasheet is parsed into structured records: card types, port counts, ordering codes, specifications. "Which card has 16 E1 ports?" becomes a bounded SQL query, not a page-by-page scan.
  4. MIB loading (5 min) the .mib file is parsed into the catalog with every OID, syntax, enum value, and description indexed and searchable. 35,977 MIB objects loaded in one pass. "What's the OID for erpNodeState?" returns the exact OID, enum values, and source provenance with a SHA-256 hash for verification.
  5. Family registration (5 min) the MCP server registers the new family with its per-family CLI dialect (port naming, command structure, safety whitelist). The safety model learns which commands are read-only, which require the staged-commit flow, and which are excluded entirely for this family.
  6. Skill routing (5 min) the skill layer updates its routing rules to include the new family. When someone asks about the Megaplex-4, the skill routes to the right CLI reference, the right manual chapter, the right MIB branch, and the right safety recipe.

Thirty minutes after unboxing the PDFs and connecting to the device, the new family is fully operational. Engineers can ask questions, run health checks, design configs, and make changes safely with firmware-exact grounding, not textbook answers. Compare that to the traditional approach: a senior engineer spends days reading manuals, building spreadsheets, and writing custom scripts. The toolkit compresses that into a pipeline that runs while you get coffee.

The key insight: the hard part was always knowledge digestion, not device access. SSH and SNMP have been solved for decades. What was missing was the automated pipeline that turns raw documents and a live CLI into structured, searchable, bounded knowledge that an AI agent can query. That pipeline is the real product.

The capstone from datasheet to running ring:

"We're rolling out a 3-unit ETX-2 ERP ring pick the right ETX-2i variant from the datasheets, design the ring from the manual and CLI reference, stage the configuration for each unit, and after I approve, verify the ring by CLI and SNMP"

Hardware selection (datasheet variants/ordering) → grounded design (manual chapter + configure protection erp reference) → per-unit staged commits, each with explicit approval → post-commit verification via show erp status and an IF-MIB walk. This is the fusion prompt that spans every layer in a single request and it only works because every layer was built, tested, and refined through real usage.

What's Different From Existing Network Automation?

If you already use Ansible, Nornir, or pyATS, you might ask: isn't this just another automation framework?

No. The fundamental difference is who decides the workflow.

With traditional automation, you write the playbook. You define the steps, the order, the conditionals, the error handling. The system executes your script. If something unexpected happens, the script fails or does the wrong thing.

With an MCP-connected AI agent, you describe the outcome. The agent decides which tools to call, in what order, based on what it learns at each step. It chains tools dynamically: it reads the device state, interprets the output, adjusts its plan, and asks for confirmation before making changes. The workflow is emergent, not hardcoded.

This doesn't replace your playbooks. It replaces the ad-hoc, interactive work that happens between the playbooks the troubleshooting sessions, the design questions, the "what does this alarm mean" lookups, the "what's the right config syntax for this feature on this firmware" questions. The work that currently means opening a CLI, reading a manual, and asking a colleague.

The Knowledge Problem (And Why It's the Hard Part)

Building an MCP server that can SSH to a device and run commands is a weekend project. Building one that's actually useful is much harder, because the server is only half the equation. The other half is knowledge.

A network engineer's expertise isn't just "knowing the commands." It's knowing:

  • Which commands are safe to run and which aren't
  • What the output actually means (not what it says literally, but what it means operationally)
  • Which features exist on which firmware versions
  • Which commands are family-specific (a show command on one product family may not exist on another)
  • What the alarm dictionary says, not what the alarm text says
  • What the config hierarchy looks like and where each setting lives
  • What to check before making a change, and what to verify after

This knowledge lives in four places:

  1. The device itself the ? help tree, the running config, the show command outputs. But the ? help is incomplete, inconsistent across families, and doesn't tell you why a command exists or when to use it.
  2. The user manual the product documentation with concepts, procedures, limits, and alarm definitions. But it's a PDF, not searchable by the AI, and the CLI syntax in the manual may not match the firmware on your specific unit.
  3. The datasheet hardware specs, interface options, product variants, ordering information. Essential for product selection and hardware questions, but completely separate from the operational CLI.
  4. The SNMP MIBs the machine-readable OID definitions that give you a second window into device state. But MIB files are dense, proprietary, and not something any general model has memorized.

A useful MCP server needs to make all four of these accessible to the AI. Not just the tools to reach the device the knowledge to understand it.

In the research I've done for this series, this is the part that's still under-covered. Existing articles like the LinkedIn post about building a 142-tool MCP server describe the server but don't address how to build the knowledge layer that makes it smart. The Itential guide to 56 MCP servers catalogs what exists but doesn't teach the knowledge engineering behind it.

That's what the rest of this series covers.

What's Coming in This Series

Over the next six articles, I'll walk through the complete build from a blank repository to a working toolkit that connects AI agents to real network devices with safety, knowledge, and multi-client support:

  1. Building Your First MCP Server for Network Devices driver abstractions, SSH backends with Netmiko, and the first tools (read, health check, inventory).
  2. The Safety Model staged commits, read-only modes, audit trails, and why interlocks belong in code, not prompts.
  3. Agent Skills: Teaching AI to Think Like a Network Engineer how to author SKILL.md files that auto-load across Claude, Copilot, and Codex.
  4. Knowledge Layers: CLI Harvesting, Manual Ingestion, and SNMP MIBs the hard part nobody talks about.
  5. Deploying Across Claude, Copilot, and Codex one skill set, six AI clients, and what "verified" really means.
  6. Fusion Prompts: From Datasheet to Running Ring capstone workflows that span every layer in a single prompt.

The Bottom Line

The question isn't whether AI will be part of network operations. It already is engineers are pasting CLI output into ChatGPT and asking it to interpret alarms. The question is whether you build the connection properly, with safety rails and real device knowledge, or keep doing it the ad-hoc way.

An MCP server gives the AI hands. Agent Skills give it a brain. Shared infrastructure gives your team a platform where investigations aren't lost, knowledge isn't scattered, and AI becomes another engineering teammate rather than a personal tool.

Well-designed MCP servers and Skills don't just make AI smarter about your network they make it cheaper to run, because the infrastructure handles the heavy lifting that would otherwise require the most expensive models and the largest context windows. And because the knowledge, safety, and policy layers are expressed in domain terms rather than transport terms, they survive the next technology shift. You adapt by replacing the interface, not by rebuilding the infrastructure.

The first version of your MCP server will be wrong and that's normal. It grows with your operations, one usage-discovered gap at a time. Each gap becomes a tool. Each tool makes the next workflow possible. The server is not shipped; it's grown.

If you work with network devices that aren't covered by an existing MCP server and most aren't building your own is the only path. It's more achievable than you might think, and the rest of this series shows you how.

Next in the series: Building Your First MCP Server for Network Devices.

Top comments (0)