The packet-coders-mcp server enables an LLM to interact with and manage network labs (mock or real EVE-NG), offering tools for device visibility, diagnostics, and guarded configuration.
list_lab_devices — Retrieve the full inventory of lab devices the server can reach, without exposing credentials.
send_command — Execute a read-only show/display command on a specific device; configuration commands are blocked at the tool level.
run_health_check — Run basic health diagnostics on a single device or across the entire lab.
get_ospf_neighbors — Fetch OSPF neighbor state using the correct platform-appropriate command automatically.
get_bgp_summary — Fetch BGP summary state using the correct platform-appropriate command automatically.
configure_device — Push configuration lines to a device with strong safety guardrails: dry-run is enabled by default, and actually applying changes requires dry_run=false plus an out-of-band confirmation code that the model never sees (a human must read it from the server console).
Additional capabilities include operating in mock mode (no physical hardware needed), connecting to a live EVE-NG environment, and compatibility with Claude Code, Claude Desktop, Ollama, and vLLM with Open WebUI.
Provides tools to manage Cisco IOS, IOS-XE, and NX-OS network devices via SSH, including sending show commands, running health checks, retrieving OSPF and BGP neighbor states, and pushing configuration changes.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@packet-coders-mcp run a health check on the lab"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A compact demo MCP server (FastMCP) that lets an LLM safely drive a network lab. Runs in mock mode with no hardware, or against a real EVE-NG lab by swapping one inventory file. Works from Claude Code, Claude Desktop, or a fully local LLM stack (Ollama / vLLM).
Tool | Purpose |
| Show the inventory the server can reach. |
| Run a read-only show command on one device. |
| Health bundle against one device or the whole lab. |
| OSPF neighbor state (right command per platform). |
| BGP summary state (right command per platform). |
| Push config — gated by an out-of-band confirm code (read-only is one flag). |
Spins up the whole stack — chat UI, lab tools, and a local model — with one command.
git clone https://github.com/E-Conners-Lab/Packet-Coders-Demo.git
cd Packet-Coders-Demo
docker compose up # first run pulls images + the qwen3:8b model (a few minutes)Open http://localhost:3000 (no login) → Settings → Integrations → add
http://localhost:8000 as a tool server → set the model's Function Calling → Native →
ask "list the lab devices." Defaults to the mock lab (no hardware needed).
Want… | Do this |
Faster on a Mac (host Ollama, Metal GPU) |
|
The real EVE-NG lab | |
Change port / model / inventory | copy |
Read-only (hide the write tool) |
|
Stop everything |
|
Port
8000already in use? SetMCPO_PORTin.env. More fixes in docs/troubleshooting.md.
Related MCP server: meraki-dashboard-api
Point any MCP client at the server (start with the mock inventory). Full per-client steps — Claude Code, Claude Desktop, Ollama / vLLM + Open WebUI — are in docs/clients.md.
# Claude Code, from the repo root:
claude mcp add packet-coders-lab \
--env PACKET_CODERS_INVENTORY="$PWD/configs/inventory.mock.yaml" \
-- uv run --project "$PWD" packet-coders-mcpVerify with claude mcp list, then ask it to list_lab_devices.
A demo, not a production change tool. Strongest guardrails:
Writes need an out-of-band code the model never sees — configure_device prints a
one-time code to the server console; a human reads it back, so the model can't self-approve.
Read-only is one flag — PACKET_CODERS_ALLOW_WRITES=false hides the write tool entirely.
Hosts that confirm each call (Claude Desktop / Code) can use their own approval instead —
set PACKET_CODERS_REQUIRE_CONFIRM_CODE=false.
Don't point it at production. Full model: docs/safety.md.
docs/clients.md — connect Claude Code / Desktop / Ollama / vLLM + Open WebUI
docs/real-lab.md — inventory model + EVE-NG setup + keeping creds private
docs/configuration.md — every .env knob + native (no-Docker) run
docs/topology.md — the four-switch reference lab (OSPF + eBGP)
docs/safety.md — full guardrail model
docs/troubleshooting.md — common errors and fixes
uv run --extra dev pytest
uv run --extra dev ruff check .Apply config lines to a lab device, with dry-run enabled by default.
| Name | Required | Description | Default |
|---|---|---|---|
| device_name | Yes | Inventory name, such as r1 or spine1. | |
| commands | Yes | Config lines only. Do not include configure terminal or end. | |
| dry_run | No | When true, preview the change without sending config. | |
| confirm | No | Must be true with dry_run=false before config is sent. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: dry-run enabled by default and confirm parameter logic. Annotations already indicate destructive behavior, and description aligns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information: verb, resource, and default behavior. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers core purpose and dry-run behavior, but lacks details on prerequisites, effect on device, or what happens after applying config.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions; description adds value by noting that dry_run defaults to true, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Apply config lines' and the resource 'lab device', and distinguishes from sibling tools like 'send_command' by mentioning dry-run default.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like 'send_command'. Usage is implied but not clarified with exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read BGP summary from a lab device using a platform-appropriate command.
| Name | Required | Description | Default |
|---|---|---|---|
| device_name | Yes | Inventory name, such as r1 or spine1. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'using a platform-appropriate command', indicating output variability by platform, beyond the readOnlyHint annotation. It clearly identifies a read operation with no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero wasted words, front-loaded with the action verb. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and an output schema, the description is complete. It provides necessary context (platform-appropriate command) without redundancy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter 'device_name' is already described in the schema. The tool description does not add further semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read BGP summary') and the target resource ('from a lab device'). It distinguishes from siblings like get_ospf_neighbors (different protocol) and send_command (generic command).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading BGP summaries, and sibling tools provide context for alternatives. However, it does not explicitly state when not to use it or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read OSPF neighbors from a lab device using a platform-appropriate command.
| Name | Required | Description | Default |
|---|---|---|---|
| device_name | Yes | Inventory name, such as r1 or spine1. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds 'platform-appropriate command' hint but lacks details on command parsing or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter, output schema, and annotations, the description is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the only parameter (device_name) with description. Description adds 'lab device' context but no extra parameter meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies 'Read OSPF neighbors' with clear verb and resource, and distinguishes from siblings like get_bgp_summary and send_command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives; no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List lab devices available to this MCP server without returning secrets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description adds that secrets are not returned, which is an important behavioral disclosure. It aligns with the read-only nature implied by the annotation and clarifies a security aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It conveys the essential purpose and constraint efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the description is fairly complete. It states the resource, scope, and the key constraint of not returning secrets. However, it omits details like ordering or pagination, which might be relevant but are not critical given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and schema coverage is 100%. The description adds context by specifying that the list includes only devices available to the MCP server, which provides meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'lab devices', and the scope 'available to this MCP server'. It distinguishes from siblings like configure_device or send_command, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run basic health checks against one device, or all devices when omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| device_name | No | Optional inventory device name. If omitted, checks the whole lab. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that health checks are 'basic' and can run on one or all devices, but does not disclose what specific checks are performed or their effect, which is acceptable given read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and scope. There is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter and an output schema (not shown but exists), the description is nearly complete. It explains the core behavior, though it could specify what 'basic health checks' entail. Still, it suffices for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description matching the tool description ('Optional inventory device name. If omitted, checks the whole lab.'). The description adds no new meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Run' and resource 'health checks', clearly indicating the action. It also distinguishes between targeting a single device or all devices when omitted, which helps differentiate the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings like 'get_bgp_summary' or 'send_command'. The purpose is clear but lacks context on when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one read-only show/display command on a lab device.
| Name | Required | Description | Default |
|---|---|---|---|
| device_name | Yes | Inventory name, such as r1 or spine1. | |
| command | Yes | A read-only show/display command. Configuration commands are blocked. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable context by specifying that only show/display commands are allowed and that configuration commands are blocked, which goes beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the essential purpose. Every word serves a clear function, with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, good schema descriptions, output schema present, annotations), the description provides sufficient context. It specifies the domain (lab device), the command type (show/display), and restrictions (read-only, blocked config). Sibling tools are also listed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for both parameters. The tool description does not add new parameter information beyond what the schema already provides, so it defaults to a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('run'), the resource ('one read-only show/display command'), and the scope ('on a lab device'). It effectively distinguishes from sibling tools like 'configure_device' by specifying read-only and blocking config commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates when to use the tool (for read-only show/display commands) and when not (configuration commands are blocked). It provides clear context for choosing this over siblings like 'configure_device'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation: configure_device for config, get_bgp_summary and get_ospf_neighbors for specific routing info, list_lab_devices for device enumeration, run_health_check for overall health, and send_command for generic show commands. No overlapping purposes.
All tool names follow a consistent verb_noun pattern with underscores (e.g., configure_device, get_bgp_summary, list_lab_devices). No mixing of conventions or irregular naming.
With 6 tools, the set is well-scoped for a network lab management server. Each tool covers a core need without redundancy or excessive specialization.
The tool set covers essential lifecycle operations: listing devices, configuring, retrieving BGP/OSPF status, health checks, and a generic command. Minor gaps include missing support for other routing protocols, but send_command provides a fallback.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for network documentation, generated by doc2mcp.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
An MCP server for deep research or task groups
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/E-Conners-Lab/Packet-Coders-Demo'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
