Comprehensive MCP server for GNS3 network simulation and automation - 42 tools, modular architecture, AI-powered network management
GNS3 MCP server has basic tool definitions with consistent parameter schemas, but significant gaps in description quality and error handling guidance. All 11 tools have descriptions (some adequate, most minimal), and parameter schemas are present with type information. However, descriptions average ~90 chars (well below the 194-char baseline for A+ tools), lack depth about WHEN to use each tool, and many lack guidance on prerequisites or failure recovery. No tool annotations (readOnlyHint/destructiveHint) despite having 6 WRITE/DESTRUCTIVE tools. Output schemas are not documented. Error responses return generic {"status": "error", "error": str(e)} with no recovery guidance per the pattern:recovery-guide requirement.
Close an open project. All nodes will be stopped.
Create a new GNS3 project.
Permanently delete a project and all its files. WARNING: This action cannot be undone!
Duplicate an existing project with a new name. Creates an exact copy of the project including all nodes and configurations.
Get detailed information about a specific project. Returns complete project configuration and statistics.
Get GNS3 server version and information. Returns server version, supported features, and system information.
List all available compute servers (local, VMs, remote). Shows compute ID, name, protocol, host, port, and status.
No tool annotations despite 6 WRITE/DESTRUCTIVE tools. The gns3_delete_project tool modifies state destructively but lacks destructiveHint annotation to signal to LLMs that this is irreversible and should trigger confirmation logic.
Error responses provide no recovery guidance. All tools return {"status": "error", "error": str(e)} with raw exception text. Per pattern:recovery-guide, errors must tell the LLM what to do next (e.g., 'project_id not found; call gns3_list_projects() to find valid IDs'). Current errors like 'Connection refused' give the agent nothing actionable.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 30 | - | v1 |
List all nodes (devices) in a project. Shows node name, type, status, console port, and position.
List all projects on the GNS3 server with detailed status. Shows project name, ID, node/link counts, and status.
Open an existing GNS3 project for editing.
Update project settings. Only specified parameters will be updated.
Descriptions are generic and underdimensioned (avg 90 chars vs. 194-char baseline). Example: gns3_update_project: 'Update project settings. Only specified parameters will be updated.', lacks WHEN to use (is this for renaming, changing auto-start behavior?), lacks dependency info (do you need project_id first?), lacks output details.
Output schemas are undocumented. Tools return {"status": "success", "<data>"} but the structure of <data> is not declared (e.g., what fields does server_info contain? what is the shape of a project object?). LLMs cannot plan downstream calls without knowing what fields to extract.
gns3_delete_project lacks confirmation step. Per pattern:confirmation-request, irreversible operations should support dry-run or require explicit confirmation. Current tool deletes permanently with just a project_id, inviting catastrophic agent mistakes.
Credentials passed as parameters. All tools accept username/password as optional parameters. Per pattern:secret-injection, credentials must never be tool parameters, they should be injected server-side via environment variables or vault. Agent call logs will expose credentials.
No pagination support on list tools. gns3_list_projects and gns3_list_nodes return all results without limit, offset/page, or total_count. Per pattern:paginated-result, large result sets blow the context window. Should accept limit (default 20) and offset/cursor parameters.
Parameter descriptions lack validation rules and constraints. E.g., 'project_id' and 'new_name' have only one-sentence descriptions with no guidance on format, length limits, allowed characters, or examples. Per pattern:constrained-input, descriptions should state: 'Project ID (UUID format, 36 chars)' or 'Project name (1-100 chars, alphanumeric + spaces/hyphens)'.