Loading ToolBench
GNS3 lab automation MCP server with AI agent integration for network simulation and device management
The server has 8 tools with well-structured schemas and reasonable descriptions. Most tools follow verb-noun naming conventions (list_*, create_*, update_*, get_*, set_*, send_*, read_*, http_client). Descriptions are present and actionable for most tools (ranging 50-150 chars), meeting the 10-1024 char baseline. Input schemas are complete with proper types and descriptions for all parameters. However, there are gaps in output schema documentation, error handling guidance, and some parameter descriptions lack constraint details (format, range). The http_client tool is somewhat generic and lacks clarity on why it's needed alongside other tools. Security considerations around credential handling are not visible in the provided code samples. Overall, this is a competent, domain-specific tool set that follows established patterns but lacks the production-grade polish of A-tier servers.
Create a drawing object (rectangle, ellipse, line, or text)
List all network links in the current project
HTTP client implementation for making HTTP/HTTPS requests to lab devices
List all drawing objects in the current project
Read console output (auto-connects if needed). Reads accumulated output from background console buffer.
Send data to console (auto-connects if needed). Sends data immediately without waiting for response.
Manage network connections (links) in batch with two-phase validation for atomic topology changes
Update properties of an existing drawing object
Output schemas not documented. No clear specification of what list_drawings, get_links, read_console, and http_client return to the agent. Agents need to know returned field names and types to chain tools and extract data correctly.
Error handling guidance missing. Tools do not document what errors can occur, whether they are retryable, or what the agent should do next. E.g., set_connection claims 'two-phase validation for atomic topology changes' but does not document what validation errors are returned or how the agent recovers.
http_client tool naming and purpose unclear. Name 'http_client' is generic and does not follow verb_noun convention (should be 'make_request', 'fetch_url', or similar). Description does not explain when to use this vs. other tools, and 'Lab devices' is vague, what lab context? Why is this a separate tool?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 22 | - | v1 |
Parameter constraint documentation incomplete. Several parameters lack format or range details: 'color' in create_drawing accepts 'hex or name' but does not document the format (e.g., '#RRGGBB' vs 'red'); 'drawing_type' enum is complete but other string params like 'font_family' are unbounded. Agents may pass invalid values.
set_connection tool mixes concerns. Description mentions 'batch' operations with 'two-phase validation' but schema only shows array of actions without documented transaction semantics. Unclear if partial failures roll back or succeed partially. Agents cannot predict outcome of a mixed connect/disconnect batch.
read_console output structure undefined. The 'mode' parameter offers 'diff', 'last_page', 'num_pages', 'all' but does not specify what structure each mode returns. Does 'diff' return {added, removed}? Does 'last_page' return {page_number, lines, total_pages}? Agent cannot plan downstream processing without this schema.
Pagination support missing. list_drawings and get_links do not document limit, offset, or total_count parameters/fields. If a project has hundreds of drawings or links, the agent gets all at once, risking context window exhaustion and degraded reasoning.