Applicability of MCP for the Network Management

2.1. MCP

• MCP Protocol: MCP is an open standard designed to facilitate communication between LLMs and external data sources or tools.¶

• MCP Host: The entity initiating the LLM request.¶

• MCP Client: A built-in module within a host, specifically designed for interaction with the MCP server.¶

• MCP Server: A dedicated entity that exposes tools, resources, or prompts to MCP clients.¶

• CLI: Command Line Interface¶

2.2. Others

• LLM: Large Language Model¶

• NETCONF: Network Configuration Protocol [RFC6241]¶

• RESTCONF: RESTful Network Configuration Protocol [RFC8040]¶

• SNMP: A Simple Network Management Protocol [RFC3584]¶

5.1. The Third Party as IETF network Exposure Consumer

       3rd Party
  +------------------+
  |     Consumer     |
  |   +------------+ |
  |   |            | |       4. Authoriz and Consume
  |   | MCP Client <-+------------------------+
  +---+-+-------^--+-+                        |
    2.Discover  |3. List of                   |
    and Authz   | Available APIs              |
        |       |                             |
        |       |                             |
  +---+-V-------+--+------------+         +---V--------+
  |   | MCP Server |            |         |Tools       |
  |   +------------+            |1.Publish|+----------+|
  |                             <---------+|Simulation||
  |   Network Exposure Agent    |         ||  API     ||
  |   /Network Controller       |4. Authz |+----------+|
  | +---+   +---+ +---+         <--------->            |
  | |NF1|   |NF2| |NF3| ...     |         |+----------+|
  | +---+   +---+ +---+         |  Heart  ||Other APIs||
  |                             <--------->+----------+|
  +-----------------------------+  Beat   +------------+

Step 1: External tools or data source publish a set of APIs to MCP server in the Network Controller.¶

Step 2: MCP client sends a specific tool request to discover tools and MCP Server provides authorization to the MCP client.¶

Step 3: After successful authorization, MCP server returns the API list corresponding to the tool request sent by the MCP client.¶

Step 4: MCP Client invokes tools with authorization.¶

5.2. The Network Controller Consumes external sources

                               +---------------+
                               |  Data Source  |
                               | +-----------+ |
                               | | MCP Server| |
                               +-+-----^-----+-+
                                       |2. Consume external sources
                                       |
                          +------+-----V-----+-----------+
                          |      | MCP Client|0.Preconfig MCP
  +--------------+        |      +-----------+  Server Address
  |     IETF     |1.MCP Service Request                  |
  |   Network    +-------->                              |
  |  Management  |3.MCP Service Response                 |
  |  AI Agents   <--------+                              |
  +--------------+        |                              |
                          |       Network Controller     |
                          |                              |
                          +------------------------------+

Step 0: MCP Client is preconfigured with the MCP Server address.¶

Step 1: IETF Network Management AI Agent sends a MCP Service Request to the MCP client within the Network Controller.¶

Step 2: The MCP client discovers tools provided by the external MCP server.¶

Step 3: The MCP client provides the available tools list to the IETF Network Management AI Agent.¶

6.1. MCP core function

          +------------+ 2.Discovery ---------------+
          | Agents     +-----------+      MCP       |
          |(MCP Client)+-----------+   Repository  |
          +-+----------+ 3. Authz  +--------^-------+
            |4. Consume                     |1.Registration
            | +-------------+---------------+-------+-
 +----------V-+       +-----+-------+        +------+------+
 |MCP Server 1|       |MCP Server 2 |        | MCP Server 3|
 +------------+       +-------------+        +-------------+
    -------                -----                  -----
 ///FM  PM \\\          ///     \\\            ///     \\\
|             |       ||  Memory   |         ||           |
| Routing  ACL|       |             |        |    Templates|
 \\\Policy ///        || Database  |         ||           |
    -------             \\\     ///            \\\     ///
                           -----                  -----

o MCP Repository: * Maintain the description of MCP servers * Support MCP server discovery for Client.¶

o MCP client: consuming the services provided by MCP servers¶

o MCP servers: including authentication/session/policy tools, the memory/prompts used for Agents¶

6.2. Procedure for Multi-MCP servers Discovery

The following procedure illustrates a registry-based deployment. Registration and synchronization mechanisms are deployment-specific.¶

 +------------------+    +----------+   +-------+     +------+
 |Network Management|    |          |   |       |     |      |
 |    AI Agent      |    |  MCP     |   | MCP   |     |Tools |
 |   (MCP Client)   |    |Repository|   |Servers|     |      |
 +---------+--------+    +----+-----+   +---+---+     +---+--+
           |                  |             | 0. Sync the info of tools
           |                  |             |<------------+
           |                  |1. Registration            |
           |                  |<------------+             |
           |                  |             |             |
           |    +-------------+----------+  |             |
           |    |       Repository       |  |             |
           |    |MCP Server1:ID 1, Capability, Tools      |
           |    |                        |  |             |
           |    |MCP Server2:ID 2, Capability, Tools      |
           |    +------------- ----------+  |             |
           | 2.1 Discovery    |             |             |
           +------------------>             |             |
           |           +------+------+      |             |
           |           | Search for  |      |             |
           |           | Proper MCP  |      |             |
           |           | Server      |      |             |
                       +-------------+      |             |
           | 2.2 Address of MCP Server      |             |
           <------------------+             |             |
              3. oAuth Authz                |             |
           <------------------------------->|             |
           |  4. Consume Tools/Resources/Prompts          |
           +------------------+-------------|-------------|
                              |             |             |

Step 0: The MCP Server syncs up on the info of tools, when tools are added or removed, tools changes will be automatically synced up with the MCP server.¶

Step 1: Each new MCP server will register to the centralized MCP registry.¶

Step 2.1: MCP Client sends the MCP service request to the MCP registry for specific capability.¶

Step 2.2: The MCP registry returns a specific MCP server to the MCP client.¶

Step 3: The MCP Client request authorization from the MCP server.¶

Step 4: The MCP Client invokes specific tools with authorization.¶

6.3. Network Management Capability Metadata

In MCP-based network management environments, exposed tools may represent operationally sensitive network management actions, including telemetry retrieval, diagnostics, configuration modification, service provisioning, policy updates, or device control operations. While the MCP repository maintains information about MCP servers, tools, and capabilities, additional network-management-specific capability metadata may improve operational safety, interoperability, and automated decision-making.¶

MCP repositories and MCP servers may associate tools with metadata describing both functional capabilities and operational constraints of the exposed capability as follows:¶

• Functional capability metadata: operation type, operational scope, supported management protocols, rollback support capability, and operational risk level.¶

• Operational constraint metadata authorization requirements, human approval requirements, freshness indicators, and synchronization version information.¶

Such metadata may assist MCP clients, AI agents, and orchestration systems in evaluating the suitability, applicability, and operational safety of MCP tools prior to authorization and invocation, particularly in large-scale distributed network management deployments.¶

7.1. Network Element Inter-Communication using MCP

In this network scenario, the MCP client is deployed in one smart network element while the MCP server is deployed in another smart network element. The MCP client communicates with the MCP server using the MCP protocol and invokes specific tools and gets access to specific data in the network element as a data source. In addition, human operator can use natural language to interact with smart network element to investigate protocol troubleshooting information.¶

Network elements usually have limited resources (CPU, memory, etc.). Deploying MCP Client together with SLM may occupy a large amount of resources, affecting the normal operation of the device.¶

         Human Operator
              |
              |
          Natural Language               Data Source
  +-----------+-------------+     +-------------------------+
  |   +-------+----------+  |     |   +------------------+  |
  |   |Routing Protocol  |  |     |   |Routing Protocol  |  |
  |   |       Agent      |  |     |   |       Agent      |  |
  |   |+---+ +----------+|  |     |   | +----------+     |  |
  |   ||SLM| |MCP Client++--+-----+---+->MCP Server|     |  |
  |   |+---+ +----------+|  |     |   | +----------+     |  |
  |   +------------------+  |     |   +------------------+  |
  +-------------------------+     +-------------------------+
    Smart Network Element           Smart Network Element

7.2. Network Controller consumes API or Data source using MCP

In this network scenario, the MCP client is deployed in the network controller while the MCP server is deployed in either the 3rd party management system or external data source. The MCP client communicates with the MCP server using the MCP protocol and invokes specific tools and gets access to specific data in the 3rd party management system or external data source.¶

+------------------------+     +------------+
|                        |     | 3rd party  |
|   Network Controller   |     | Management |
|              +-------+ |     |    System  |
|              |  MCP  +-+--+  |+----------+|
|              | Client+-+--+--->MCP Server||
|              +-------+ |  |  |+----------+|
|                        |  |  +------------+
|                        |  |
|                        |  |  +------------+
|                        |  |  |            |
|                        |  |  |Data Source |
|                        |  |  |+----------+|
|                        |  |--->MCP Server||
|                        |     |+----------+|
|                        |     |            |
+------------------------+     +------------+

7.3. Standalone MCP server to Expose APIs and tools to the Network Controller

In this network scenario, the MCP client is deployed in the network controller while the MCP server is deployed standalone to manage all the network elements. For legacy networks, native MCP implementation on individual Network Elements can be redundant or resource-constrained. Instead, pre-existing network automation scripts (e.g., Python scripts powered by pyATS or Netmiko) can be directly refactored as MCP tools.¶

In this scenario, the standalone MCP server or Network Controller hosts these scripts and exposes them to the MCP client via standardized tool descriptors. When an AI agent requests a device operation, the MCP server invokes the corresponding Python script via local shell execution or tool pools. This approach achieves direct device control and backward compatibility without modifying the legacy device control plane.¶

                     +----------------------+
                     |                      |
                     |   Network Controller |
                     |                      |
                     |    +------------+    |
                     |    |            |    |
            +--------+----| MCP Client +----+----------+
            |        |    |            |    |          |
            |        |    +-----+------+    |          |
            |        +----------+-----------+          |
            |                   |                      |
            |    +--------------V---------------+      |
            |    |         MCP Server           |      |
            |    +--------^-------------^-------+      |
            V             |             |              V
   +-------------+        |             |        +-------------+
   |             |        |             |        |             |
   | Data Source |--------+-            |--------+    Tools    |
   |             |                               |             |
   +------+------+                               +------+------+
          |                                             |
   (Telemetry/gNMI)                              (CLI/FastCLI/Shell)
          |                                             |
   +------V---------------------------------------------V------+
   |    Automation & Adaption Scripts (e.g., Python, pyATS)   |
   +------------------------------+----------------------------+
                                  |
                                  V
                           +--------------+
                           | Legacy Device|
                           +--------------+
                           Network Element

7.4. The Network Gateway/Controller and the Network Element Communication using MCP

In this network scenario, the MCP client is deployed in the network gateway device while the MCP server is deployed in each network device. The MCP client communicates with the MCP server using the MCP protocol. The LLM is a pre-trained model and deployed in the same Network gateway as the MCP client.¶

Network devices usually have limited resources (CPU, memory, etc.). Deploying MCP Server may occupy a large amount of resources, affecting the normal operation of the device.¶

      +------------------------+
      |   Network Controller/  |
      |   Network Gateway      |
      |                        |
      |        Natural         |
      | +------Language------+ |
      | |  MCP  |     | LLM  | |
      | | Client|-----|      | |
      | +-+-----+     +------+ |
      |   |MCP                 |
      +---+--------------------+
          +----------------+
 +--------+---+     +------+------+
 |  +-----++  |     |  +---+--+   |
 |  | MCP  |  |     |  | MCP  |   |
 |  |Server|  |     |  |Server|   |
 |  +------+  |     |  +------+   |
 +------------+     +-------------+
Network Element      Network Element

7.5. Co-located Agent and MCP Server within a Network Element

An agent and an MCP server can run on the same network element. The agent uses an MCP client to invoke local tools for device operations or documentation retrieval. A local HTTP deployment can bind the server to the loopback address. Binding to loopback limits network exposure but does not establish the identity or permissions of local callers.¶

The server can dispatch requests to local plugins. A CLI plugin can invoke a local command adapter, while a retrieval plugin queries a documentation backend. Device-internal communication remains behind these plugins. The client-server interface follows MCP; the plugin interface and device-internal messages are implementation-specific. Appendix A.3 illustrates this arrangement.¶

8.1. Encapsulating Device Operations into MCP Tools

• Objective: Expose device operations through tool descriptions and tool calls.¶

• Implementation:¶

  • Tool Abstraction: Vendor-specific commands are wrapped into discrete MCP Tools with uniform schemas.¶

  • Tool Registry: A centralized database stores MCP Tools with metadata (e.g., names, descriptions, parameters).¶

• Benefits:¶

  • Eliminates manual translation of commands across different vendors¶

  • Enables the plug-and-play integration of new device types.¶

  • Objective: Expose device operations through tool descriptions and tool calls.**¶

• Implementation:¶

  • Tool Description: Define the tool name, description, input schema, and, where provided, output schema.¶

  • Local Tool Registry: Maintain a mapping between tool names, descriptions, and execution handlers. This can be an in-memory table; it is separate from the repository used to discover MCP servers.¶

  • Plugin Loading: One implementation option is to load configured shared libraries at server startup. Each plugin provides an initialization entry point and an execution handler. The server registers a tool after loading and initializing its implementation. Shared libraries and their calling conventions are local implementation choices.¶

  • Schema Consistency: Check that configuration-derived tool descriptions match the parameters and results handled by the plugin. Validate invocation arguments before dispatch.¶

  • Execution: Dispatch the request to the registered handler and map its output or failure into an MCP tool result. Handlers need to support concurrent calls safely, or the server needs to serialize calls to them.¶

• Benefits:¶

  • Tool implementations can be maintained separately from request dispatch and logging.¶

  • Vendor-specific command handling remains in the tool implementation. A common tool interface does not by itself translate commands between vendors.¶

8.2. LLM for Intent-to-Tool-Request Translation

• Objective: Allow AI models (such as Claude) to understand natural language commands and trigger operations.¶

• Workflow:¶

  • Intent Recognition: The LLM first analyzes the user's natural language query to identify：¶

    • The user's intent or goal¶

    • Required actions or operations¶

    • Entities, parameters, and constraints mentioned¶

    • Context from previous interactions¶

  • Network Entity Object Extraction：The LLM or a apecialized sub-module extracts network-specificsemantic entities (e.g.,Device Names, Interface IDs, Protocal Instances, VRF contexts) from the input. These extracted entities are mapped onto a network semantic graph or topology data model to ensure that the paramenters paased to the MCP tool correspond to valid, existing operational assets.¶

  • Tool Discovery and Toolchain Generation: The LLM accesses tool descriptions provided by MCP servers, and matches the identified intent with available tools.¶

  • Parameter Extraction and Mapping: The LLM maps natural language references to structured parameter names and extracts relevant information from the user query.¶

  • Structured Invocation Generation: The LLM generates properly formatted tool calls following MCP's protocol.¶

• Benefits:¶

  • Bridge natural language to tool invocation requests in a fixed format, then return this request to the client, enabling the client to properly parse the request.¶

8.3. Tool Invocation and Execution Workflow

This workflow separates documentation retrieval from device execution. It does not assume automatic recovery or rollback. - Tool Discovery: After MCP initialization, the client obtains tool descriptions with tools/list. The host provides relevant descriptions and the operator's request to the LLM. - Context Retrieval: If documentation is needed, the host invokes a retrieval tool through the MCP client. The tool can query a local backend or an existing retrieval service and return relevant document excerpts. Retrieval supplies context; it does not execute device commands or authorize configuration changes. - Tool Selection: The LLM proposes the next tool and its arguments. The host applies permission and approval checks before invocation. An informational question can be answered from retrieved material without calling a device configuration tool. - Device Execution: The client sends a tools/call request. The server validates the arguments and dispatches them to the selected handler. A CLI handler can invoke a local command adapter and capture its output and error information. - Result Handling: The server returns the result or execution error. The host can display the result directly or supply it to the LLM for explanation. Command output alone does not establish that the requested network state has been reached. - Logging: The server records each tool invocation. Request and session identifiers can correlate calls with execution records. Log format and retention are implementation choices. Such records document tool execution; they do not necessarily capture the model's reasoning. These steps use MCP methods rather than dedicated REST paths. With Streamable HTTP, tools/list and tools/call are JSON-RPC messages sent by HTTP POST to the MCP endpoint. A custom such as GET /tools or POST /execute API requires adaptation before it can serve a standard MCP client.¶

A closed-loop workflow additionally requires checks of the resulting device state. Retry and rollback depend on the operation and backend support; they are not guaranteed by MCP tool invocation.¶

A.1. Routing Protocol Troubleshooting using Embedded SLM Model and Natural Language Interface

The figure shows a troubleshooting workflow. To integrate this workflow with MCP, the troubleshooting application can use an MCP client to invoke scripts exposed as tools by an MCP server. This is a possible integration point; the figure does not specify the MCP roles or transport.¶

+-----------------------------------------------------------------+
| Smart Network Element                                           |
|                                                                 |
| +-------------------------------------------------------------+ |
| |  Dev  Env: Offline Generate fault location workflow code    | |
| |                                                             | |
| |      +----------+                         +---------+       | |
| |      | Expert   | +----------+            |fault    |       | |
| |      |experience| | Protocol |  +-----+   |Locating |       | |
| |      |accumulate+-> Knowledge+--> LLM +--->Workflow |       | |
| |      | protocol | |   RAG    |  +-----+   |  Code   |       | |
| |      |  fault   | +----------+            +----+----+       | |
| |      +----------+                              |            | |
| +------------------------------------------------+------------+ |
|                                                  |              |
|                                                  |              |
|                                                  |              |
| +------------------------------------------------+------------+ |
| |OPS Env:Online Natural Language Interaction------V-------+    | |
| |                             +----------+Troubleshooting|    | |
| |                             |          |  Package Build|    | |
| |                             |          +---------------+    | |
| |+--------+              +----V---+    +-------------+        | |
| ||  User  |  +-------+   |Intent  |    | Execute     |        | |
| || Nature |  | Device|   |Parse   |    |Workflow     |        | |
| ||Language+-->  SLM  +--->Fault   +---->  Script     |        | |
| || Prompt |  |  ONNX |   |Pattern |    |Locating root|        | |
| |+--------+  +-------+   |Match   |    |  Cause      |        | |
| |                        +--------+    +-------------+        | |
| |                                                             | |
| +-------------------------------------------------------------+ |
+-----------------------------------------------------------------+

Step 1. When ISIS neighbour establishment fails, the network maintenance engineer queries the fault cause via natural language in the CLI interface.¶

Step 2. A small model deployed on the device's CPU understands the user's intent and matches the fault pattern.¶

Step 3. Troubleshooting scripts are invoked to locate the root cause of the fault.¶

Step 4. The query is repeated until service operations get back to normal.¶

A.2. Device Configuration using MCP+CLI

In this example, the network element implements the MCP Server and exposes all CLI interfaces and documentation as tools to the MCP Client. The Network controller implements the MCP client and interact with MCP server in the Network element.¶

The MCP server provides the following registered tool descriptor information:¶

Tools description: It describes the name, use, and parameters of tools.¶

Tools implementation: MCP implementation describes how the tools are invoked.¶

See Tool descriptor information example as follows:¶

Tool Descriptor:¶

[
  {
    "name": "batch_configure_devices",
    "description": "Batch Configure Network Devices",
    "parameters": {
      "type": "object",
      "properties": {
        "device_ips": {
          "type": "array",
          "items": {"type": "string"},
          "description": "Device IP List"
        },
        "commands": {
          "type": "array",
          "items": {"type": "string"},
          "description": "CLI Sequence"
        },
        "credential_id": {
          "type": "string",
          "description": "Credential ID"
        }
      },
      "required": ["device_ips", "commands"]
    }
  },
  {
    "name": "check_device_status",
    "description": "Check the Status of Network Devices",
    "parameters": {
      "type": "object",
      "properties": {
        "device_ip": {"type": "string"},
        "metrics": {
          "type": "array",
          "items": {"enum": ["cpu", "memory", "interface"]}
        }
      },
      "required": ["device_ip"]
    }
  }
]

Tool Implementation¶

from netmiko import ConnectHandler
from mcp_server import McpServer

app = FastAPI()
server = McpServer(app)

#Connection Pool Management
devices = {
    "192.168.1.1": {
        "device_type": "VendorA-XYZ",
        "credential": "admin:XYZ@password"
    },
    "192.168.1.2": {
        "device_type": "VendorB-ABC",
        "credential": "admin:ABC@password"
    },
    ...
}

@server.tool("batch_configure_devices")
async def batch_config(device_ips: list,commands: list,credential_id: str):
    results = {}
    for ip in device_ips:
        conn = ConnectHandler(
            ip = ip,
            username = devices[ip]["credential"].split(':')[0],
            password = devices[ip]["credential"].split(':')[1],
            device_type = devices[ip]["device_type"]
        )
        output = conn.send_config_set(commands)
        results[ip] = output
    return {"success": True, "details": results}

@server.tool("check_device_status")
async def check_status(device_ip: str, metrics: list):
    status = {}
    if "cpu" in metrics:
        status["cpu"] = get_cpu_usage (device_ip)
    if "memory" in metrics:
        status["memory"] = get_memory_usage(device_ip)
    return status

Suppose a user submits a request (via the client) such as "Configure OSPF Area 0 with process ID 100 for all core switches in the Beijing data center," the MCP client retrieves the necessary tooling descriptor information from the MCP server and forwards it along with the request to the LLM. The LLM determines the appropriate tools and responds in JSON format as follows:¶

{
"method": "batch_configure_devices",
"params": {
   "device_ips":["192.168.10.1",....,"192.168.10.10"],
   "command": [
     "router ospf 100",
     "network 192.168.0.0 0.0.255.255 area 0"
   ]
 }
}
}

The MCP server responds to the call instruction, converts it into the below CLIs of different vendors, and then the devices execute the CLIs. The results are returned to the MCP client in JSON as below and are forwarded to the LLM. The LLM parses the response, generates a natural-language summary, and sends it back to the client for final presentation to the user.¶

# Convert to CLI commands of different vendors
"commands": [
    "system-view",
    "ospf {{process_id}}",
    "area {{area_id}}",
    "network {{network_address}} {{wildcard_mask}}"
  ]

"commands": [
    "configure terminal",
    "router ospf {{process_id}}",
    "network {{network_address}} {{wildcard_mask}} area {{area_id}}",
    "end",
    "write memory"
  ]

#Feedbacks received by the MCP client of different vendors
{
    "status": "success",
    "message": "OSPF configuration applied successfully on device
                192.168.10.1",
    "commands_executed": [
        "system-view",
        "ospf 100",
        "area 0.0.0.0",
        "network 192.168.10.0 0.0.0.255"
    ]
}

{
    "status": "success",
    "message": "OSPF configuration applied successfully on device
                192.168.10.1",
    "commands_executed": [
        "configure terminal",
        "router ospf 100",
        "network 192.168.10.0 0.0.0.255 area 0",
        "end",
        "write memory"
    ]
}

# Natural language summary of success or failure:
{
  "192.168.10.1": "Configure Successfully, take 2.3 seconds",
  "192.168.10.2": "Error: no response from the device",
}