| Internet-Draft | MCP for Network Management: Problem Stat | February 2026 |
| Zeng | Expires 18 August 2026 | [Page] |
The emergence of large language models (LLMs) and AI agents is reshaping how network operators interact with infrastructure. However, current network management systems lack a standardized, secure, and intent-driven interface that enables AI agents to discover, invoke, and reason over network capabilities. This document presents a problem statement for integrating the Model Context Protocol (MCP) into network management, outlines key use cases—including troubleshooting, measurement, security, and optimization—and specifies functional, security, and interoperability requirements for MCP-based network management architectures.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 August 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Traditional network management relies on protocol-specific interfaces (e.g., SNMP, NETCONF, RESTCONF) and manual scripting, which are rigid, siloed, and ill-suited for natural-language-driven automation. The Model Context Protocol (MCP), originally designed to standardize tool interaction for AI agents, offers a promising abstraction layer to unify network capabilities as callable “tools” and readable “resources.” This document formalizes the motivation, scenarios, and technical prerequisites for adopting MCP in network management.¶
Modern networks face increasing complexity due to scale, heterogeneity, and dynamic service demands. Operators struggle with:¶
Existing management frameworks address parts of these issues but lack a lightweight, agent-centric protocol that decouples AI logic from network implementation details. MCP fills this gap by providing a uniform, JSON-RPC–based interface for AI agents to securely interact with network elements as first-class tools.¶
Without standardizing how networks expose capabilities to AI agents, the industry risks fragmented, vendor-specific integrations that hinder interoperability, auditability, and safe automation.¶
This section describes four representative use cases where MCP enables intelligent, intent-driven network management.¶
An operator reports: “Users in Floor 3 cannot reach the cloud application.”¶
Under this scenario, the MCP Workflow runs as follows:
The LLM interprets the intent and identifies required tools: get_interface_status, ping, show_route, check_acl.
The MCP Client (in controller or local device) invokes these tools across relevant switches and routers.
In D2D (Device-to-Device) mode, affected devices collaboratively gather data even if the controller is unreachable.
The LLM correlates results and concludes: “ACL ‘block_external’ on Switch-F3 denies outbound traffic.”
A repair suggestion is generated and presented for approval.¶
The MCP Workflow reduces mean time to resolution (MTTR) from hours to minutes with explainable root-cause analysis.¶
An operator requests: “Monitor end-to-end latency between all branch offices every 5 minutes and alert if >50ms.”¶
Under this scenario, the MCP Workflow runs as follows:
The request is parsed into a recurring measurement task.
MCP Tools such as measure_latency, collect_interface_stats, and query_bgp_rib are scheduled across edge routers.
Structured results (with timestamps, paths, and metadata) are returned via MCP Resources.
The LLM detects anomalies using historical baselines and triggers alerts or auto-remediation.¶
The MCP Workflow enables continuous, intent-defined observability without custom collectors or polling scripts.¶
An operator requests: “Detect and isolate any device exhibiting abnormal outbound traffic patterns.”¶
Under this scenario, the MCP Workflow runs as follows:
The security AI agent subscribes to flow data via MCP Resource netflow_records.
Upon anomaly detection (e.g., sudden spike to unknown IP), it invokes get_device_info, list_connected_hosts, and apply_quarantine_acl.
All actions are logged with cryptographic signatures for compliance.
The agent may also query external threat intelligence via an external MCP Server.¶
The MCP Workflow enables real-time, closed-loop security response.¶
An operator requests: “Optimize WAN bandwidth utilization during business hours without violating SLAs.”¶
Under this scenario, the MCP Workflow runs as follows:
The optimizer agent collects real-time metrics (bandwidth_utilization, application_qos_stats) via MCP Resources.
It simulates policy changes (e.g., adjusting QoS profiles, shifting SD-WAN paths) using sandboxed MCP Tools.
After validation, it applies the optimal configuration via update_qos_policy or modify_sdwan_rules.
Post-change telemetry confirms SLA compliance.¶
The MCP Workflow enables continuous, data-driven optimization aligned with business intent, reducing manual tuning.¶
To support the above use cases safely and scalably, MCP-based network management must satisfy the following requirements.¶
ietf-mcp-nm).¶
This document’s requirements (Section 4.2) are designed to mitigate risks inherent in AI-driven network control, including prompt injection, unauthorized configuration changes, and data leakage. Additional considerations include:¶