AI & AIOps

From Friction to Flow: Why MCP Matters for NetOps

Peter Sprygada

Chief Architect ‐ Itential

From Friction to Flow: Why MCP Matters for NetOps

From Friction to Flow: Why MCP Matters for NetOps

October 15, 2025
Peter Sprygada

Chief Architect ‐ Itential

From Friction to Flow: Why MCP Matters for NetOps

Automation is a function of friction. Jeremy Schulman nailed it on his recent Packet Pushers podcast with Total Network Operations when he said that. Every ticket, every brittle script, every tribal-process that lives only in someone’s head is friction. And friction is the enemy of scale.

Friction is the ticket backlog that never shrinks. It’s the script that only works on one vendor’s box. It’s the “final_final_v3.py” file living on a laptop. And when production goes sideways at 2 AM, all that friction turns into real pain.

That’s why the Model Context Protocol (MCP) matters. It’s not hype. It’s a practical way to reduce friction by making automation discoverable, composable, and safe. And paired with a platform approach, MCP can turn AI from a flashy demo into a reliable interface for NetOps.



The Friction Problem in NetOps

We’ve all lived this:

  • Silos and tickets. Work bounces between teams, piling up delays, until the original context is gone. By the time the change is approved, the business need has shifted.
  • Script sprawl. What starts as a quick fix becomes mission-critical glue. The author goes on PTO, and suddenly no one wants to touch it.
  • Spreadsheet-driven ops. Copying and pasting configs works until one fat-finger brings down a core service.
  • Heroics over discipline. Teams rush to hack together code instead of documenting workflows. It feels fast – until the next person can’t follow it.

The common denominator is friction. It slows delivery, adds risk, and burns out engineers.



Why MCP Is Different

MCP changes the game because it makes automation tools discoverable and consumable:

  • Instead of hardcoding every REST call, an agent can connect to an MCP server and simply ask, “What tools are available?”
  • Natural language gets translated into scoped, pre-defined actions. Plain requests like “List all circuits from provider X” resolve into the correct tool with the right parameters.
  • Rather than exposing hundreds of fragile endpoints, you define a smaller set of safe, composable MCP tools. That means fewer sharp edges and less time maintaining brittle glue code.

Think of it as lowering the barrier to automation. Not everything is possible, but the right things become easier and safer.



From Glue Code to Governed Orchestration

Here’s the catch: MCP alone can become a new wild west. Without structure, it’s just another way to spread spaghetti. The solution is to treat MCP as a building block inside a governed platform:

  • Role-based access control. Agents can only do what they’re allowed – read here, write there, and nothing beyond scope.
  • Audit by design. Every MCP call is logged with full context, so there’s always a record of who did what and why.
  • Composable workflows. Instead of wiring NetBox, observability, and ticketing with brittle glue code, you expose MCP tools and orchestrate them into reusable flows.
  • Durability. Swap out a system and keep the MCP contract. No need to rewire every integration from scratch.

That’s how MCP becomes product-grade instead of another Frankenstein script.



 The Friction-to-Flow Journey

The steps to reduce friction aren’t rocket science – but they take discipline:

  1. Write the process first. If you can’t document it, you can’t automate it. Capture personas, pre/post checks, and rollback plans before touching code.
  2. Version control everything. Scripts, configs, intents, and workflows. Git beats “script_v2_final_final.py” every single time.
  3. Automate the repetitive. Start small. Automate the soul-crushing, error-prone steps first.
  4. Orchestrate the multi-step. Once the basics are reliable, connect them into governed workflows.
  5. Expose via MCP. Package those workflows as MCP tools so humans and AI agents can consume them without tribal knowledge.
  6. Layer compliance early. Bake RBAC, approvals, and audit into day one. Don’t wait for step 79.

The result is not just fewer outages – it’s a team that spends more time building and less time firefighting.



What This Means for NetOps Teams

MCP plus a platform approach means:

  • Faster triage. Instead of running ten CLI commands, you ask “What’s the status of circuit X?” and get a report with charts, logs, and recommended next steps.
  • Safer changes. Guardrails prevent runaway automation and give operators confidence that workflows won’t blast the wrong config.
  • Audit-ready by default. Every change has receipts, so compliance reviews stop being a scramble.
  • Engineers elevated. Less time copying configs, more time building real solutions. AI becomes a co-pilot today, and a co-worker tomorrow – always under governance.


Closing Call to Action

The conversation with Jeremy was a reminder: automation isn’t about clever scripts. It’s about removing friction with discipline, governance, and the right interfaces. MCP is one of those interfaces.

💬 Want to talk more about MCP? Connect with me on LinkedIn or stop by and say hi at the upcoming AutoCon 4 event in Austin!

Peter Sprygada

Chief Architect ‐ Itential

Peter Sprygada serves as the Chief Architect at Itential after serving as the Chief Technology Officer at Pureport where he was responsible for their multi-cloud network as a service interconnect platform. Prior to Pureport, Sprygada was a Distinguished Engineer for Red Hat, where he played the role of Chief Architect for the Ansible Automation Platform. Sprygada also held senior technical and leadership positions at Arista and Cisco, as well as several networking startups.

More from Peter Sprygada