{"id":183,"date":"2026-10-08T00:00:00","date_gmt":"2026-10-07T20:30:00","guid":{"rendered":"https:\/\/www.anynet.ir\/blog\/%d8%a7%d8%b3%d8%aa%d9%81%d8%a7%d8%af%d9%87-%d8%a7%d8%b2-%d9%85%d8%af%d9%84%d9%87%d8%a7%db%8c-%d8%b2%d8%a8%d8%a7%d9%86%db%8c-%d8%a8%d8%b2%d8%b1%da%af-llm-%d8%a8%d8%b1%d8%a7%db%8c-%d8%b3%d8%a7%d8%ae-en\/"},"modified":"2026-10-18T19:07:20","modified_gmt":"2026-10-18T15:37:20","slug":"%d8%a7%d8%b3%d8%aa%d9%81%d8%a7%d8%af%d9%87-%d8%a7%d8%b2-%d9%85%d8%af%d9%84%d9%87%d8%a7%db%8c-%d8%b2%d8%a8%d8%a7%d9%86%db%8c-%d8%a8%d8%b2%d8%b1%da%af-llm-%d8%a8%d8%b1%d8%a7%db%8c-%d8%b3%d8%a7%d8%ae-en","status":"publish","type":"post","link":"https:\/\/www.anynet.ir\/blog\/en\/%d8%a7%d8%b3%d8%aa%d9%81%d8%a7%d8%af%d9%87-%d8%a7%d8%b2-%d9%85%d8%af%d9%84%d9%87%d8%a7%db%8c-%d8%b2%d8%a8%d8%a7%d9%86%db%8c-%d8%a8%d8%b2%d8%b1%da%af-llm-%d8%a8%d8%b1%d8%a7%db%8c-%d8%b3%d8%a7%d8%ae-en\/","title":{"rendered":"Using LLMs to build a Crosswork Planning MCP server"},"content":{"rendered":"
<\/div>\n
\n
<\/div>\n<\/div>\n
\n
\n
\n

Introduction<\/h2>\n

Crosswork Planning predicts the impact of network changes, traffic growth, new services, and potential failures. Operators usually perform these tasks in the Design application, which provides an interactive graphical interface for simulation, optimization, and analysis.<\/p>\n

The same capabilities are available programmatically. The Optimization and Prediction Module (OPM) Python library connects to the DesignAPI service on a Crosswork Planning instance, opens a plan, and runs route simulation, failure impact, and Simulation Analysis on the server. The tutorial Using LLMs for Crosswork Planning script prototyping<\/a> showed how an LLM coding agent can be leveraged to write a one-off script against this library.<\/p>\n

This tutorial goes one step further. Instead of asking the agent for a script that answers a specific question, we ask it to build a Model Context Protocol (MCP) server<\/strong> that exposes Crosswork Planning capabilities as a set of tools that any MCP-capable LLM client can use. Once the server is connected, you may ask questions such as “What happens if the San Jose to Kansas City link fails?”<\/em> in natural language, and the LLM decides which simulation to run and explains the results to the operator.<\/p>\n

\n

Note:<\/strong> Crosswork Planning is slated to ship with a fully supported MCP server in a future release. This tutorial shows how you can build and use your own MCP server with LLMs, using the Crosswork Planning Python library.<\/p>\n<\/blockquote>\n

Building on these capabilities, Crosswork AI offers an Agent Development Kit (ADK) for developing and operating AI agents, enabling MCP-powered network planning applications. An illustrative use case is presented in the Cisco Community blog, From Static to Autonomous: The Evolution of Network Planning<\/a>. Beyond agent development, the Crosswork AI framework brings together agent observability and tracing, agent evaluation, planning and orchestration services, governed model access, standardized tool integration, and knowledge-graph grounding. Together, these capabilities provide a structured foundation for AI-driven network operations that may not be available through general-purpose LLM interactions alone.<\/p>\n

What you’ll build<\/h2>\n

In this tutorial, you will ask an LLM coding agent to build a single-file Python MCP server for Crosswork Planning, register it in Cursor, and use it to analyze a sample WAN plan.<\/p>\n

When the server is connected, a conversation like this:<\/p>\n

User: I have us_wan.txt in my workspace. Upload it and tell me what happens\n<\/span> if the SJC-KCY link fails. Also run simulation analysis on circuits.\n<\/span><\/code><\/pre>\n
produces an answer grounded in real simulation output from Crosswork Planning:<\/p>\n
Agent: 1. upload_plan(us_wan.txt) \u2192 plan_ref upload:abc123, 33 nodes \/ 50 circuits \/ 95 demands\n<\/span> 2. failure_sim(plan_ref=upload:abc123, node_a=cr1.sjc, node_b=cr1.kcy)\n<\/span> \u2192 10 reroutes; cr2.wdc:to_cr1.nyc oversubscribed at 113.39%\n<\/span> 3. get_wc_traffic(plan_ref=upload:abc123, failure_sets=circuits)\n<\/span> \u2192 top interface NYC-WDC 113.39% (scenario_count 29 when reported)\n<\/span> 4. Summarize findings for the user\n<\/span><\/code><\/pre>\n
You don’t need to write the server yourself. The agent reads the Cisco SDK and writes the code; your job is to set up connectivity, describe the server clearly, and check the results against the Design application.<\/p>\n
This takes about 90 minutes, most of it spent on one-time certificate setup.<\/p>\n
How the MCP server works<\/h2>\n
Model Context Protocol (MCP) defines how AI clients discover and invoke tools<\/strong> (functions with JSON schemas) over a standard transport. An MCP server can also expose resources<\/strong> (read-only data, such as a plan summary) and prompts<\/strong> (workflow templates the LLM can pull into context). The LLM client decides when to call each tool based on the user’s question.<\/p>\n
The server in this tutorial uses stdio<\/strong> transport, which requires it to run on the same Linux workstation as the LLM client (for example, Cursor). Cursor launches the server as a child process and exchanges JSON-RPC messages over stdin and stdout. No network port is opened on your workstation, and there is no separate “start the server” step for daily use. The server in turn connects to DesignAPI on the Crosswork Planning instance over mutual TLS (mTLS) on port 30744.<\/p>\n
\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n<\/span>\u2502 Linux Workstation (same host as Cursor) \u2502\n<\/span>\u2502 \u2502\n<\/span>\u2502 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 stdin\/stdout \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u2502\n<\/span>\u2502 \u2502 Cursor \u2502 \u25c4\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25ba \u2502 cp_sample_mcp.py \u2502 \u2502\n<\/span>\u2502 \u2502 MCP client \u2502 JSON-RPC stream \u2502 --transport stdio \u2502 \u2502\n<\/span>\u2502 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2502.plan_staging\/ \u2502 \u2502\n<\/span>\u2502 \u2502 CARIDEN_HOME=cw-planning\u2502 \u2502\n<\/span>\u2502 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2502\n<\/span>\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n<\/span> \u2502 mTLS:30744\n<\/span> \u25bc\n<\/span> \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n<\/span> \u2502 Crosswork Planning VM \u2502\n<\/span> \u2502 designapid \u2502\n<\/span> \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n<\/span><\/code><\/pre>\n
Figure 1: The MCP client spawns the server locally; the server runs simulations on DesignAPI<\/em><\/p>\n
The LLM never reads plan files from the Crosswork Planning server. Instead, it reads the plan from your workspace and sends its content to the upload_plan<\/code> tool. The server stages the file locally and returns a plan_id<\/code> and canonical plan_ref<\/code> (upload:<plan_id><\/code>). Pass that plan_ref<\/code> to every later tool call.<\/p>\n
The finished server exposes 14 tools, 5 resources, and 2 prompts:<\/p>\n\n\n\n\n\n\n\n\n\n\n
Category<\/th>\nTools<\/th>\nWhat they do<\/th>\n<\/tr>\n<\/thead>\n
Plan lifecycle<\/td>\nupload_plan<\/code>, list_uploaded_plans<\/code>, delete_uploaded_plan<\/code><\/td>\nStage a plan from the client and manage staged plans.<\/td>\n<\/tr>\n
Catalog<\/td>\nget_plan_summary<\/code>, list_circuits<\/code>, list_demands<\/code>, list_lsps<\/code><\/td>\nRead nodes, circuits, demands, and label-switched paths (LSPs).<\/td>\n<\/tr>\n
Route simulation<\/td>\nget_demand_path<\/code>, get_igp_path<\/code>, get_lsp_path<\/code><\/td>\nShow how a demand, an Interior Gateway Protocol (IGP) shortest path, or an RSVP-TE tunnel or Segment Routing (SR) policy is routed.<\/td>\n<\/tr>\n
What-if<\/td>\nfailure_sim<\/code><\/td>\nFail a specific circuit and report reroutes and utilization changes.<\/td>\n<\/tr>\n
Analysis<\/td>\nget_wc_traffic<\/code>, get_traffic_growth<\/code><\/td>\nRun Simulation Analysis for worst-case utilization, and forecast traffic growth.<\/td>\n<\/tr>\n
Health<\/td>\ndesignapi_health_check<\/code><\/td>\nVerify certificates, configuration, and DesignAPI reachability.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Compared with other ways of automating Crosswork Planning:<\/p>\n\n\n\n\n\n\n\n\n
Approach<\/th>\nStrength<\/th>\nConsideration<\/th>\n<\/tr>\n<\/thead>\n
Collector external scripts<\/td>\nIntegrated into collection chains<\/td>\nRuns only during collection; file-path based<\/td>\n<\/tr>\n
Job Manager script jobs<\/td>\nScheduled, visible in the user interface<\/td>\nEach question needs its own script<\/td>\n<\/tr>\n
MCP server (stdio)<\/td>\nNatural-language interface; immediate what-if analysis; no network listener<\/td>\nThe MCP client and OPM SDK must run on a host that can reach DesignAPI<\/td>\n<\/tr>\n
REST API (CP 8.0)<\/td>\nPlatform-agnostic; does not require the SDK<\/td>\nSimulations must run as a Job Manager script or CLI job<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Before you begin<\/h2>\n
You need:<\/p>\n