Loading ToolBench
MCP server for connecting to network devices (Arista, Cisco, Juniper, FortiGate) via SSH and executing operational commands, retrieving configurations, and running diagnostics
Five tools with complete descriptions (194 - 392 chars, well above 10-char minimum) and explicit input schemas. All parameters have type definitions and descriptions. Tool names follow verb_noun convention (get_config, run_show_command, run_ping, run_traceroute, trust_host_key). Schemas are properly structured with required fields and type constraints. However, output schemas are not documented, LLMs cannot predict response structure. Error handling guidance is absent; tools do not indicate what to do on failure. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles. Parameter descriptions lack format constraints (e.g., 'host' should specify IP or FQDN format). Device-type enums are implicit in descriptions rather than formal schema constraints.
Connect to an Arista, Cisco Nexus, Cisco Catalyst, Juniper JunOS, or FortiGate FortiOS device via SSH and retrieve its running or startup configuration. Sensitive values (passwords, secrets, SNMP community names, BGP/OSPF/TACACS/RADIUS/IKE keys) are automatically obfuscated with deterministic hashes, allowing safe comparison across devices. Set device_type='junos' for Juniper routers — this issues 'show configuration' instead of 'show running-config'. Set device_type='fortios' for FortiGate firewalls — this issues 'show full-configuration'. JunOS and FortiOS do not support config_type='startup'.
Connect to an Arista, Cisco Nexus, Cisco Catalyst, Juniper JunOS, or FortiGate FortiOS device via SSH and run a ping command. Useful for verifying reachability from the device's perspective — for example, testing connectivity to a BGP peer, next-hop, or management target. Use device_type to select the correct syntax: 'eos' (Arista), 'ios' (Cisco IOS/IOS-XE), 'nxos' (Cisco NX-OS), 'junos' (Juniper JunOS), or 'fortios' (FortiGate/FortiOS). If device_type is omitted, EOS/IOS syntax is used. Optional parameters: count (number of probes), source (source IP or interface), vrf (VRF or routing-instance name on JunOS), size (packet size in bytes), timeout (FortiOS only), outgoing_interface (FortiOS only). FortiOS 7.4+ does not support vrf for ping via this tool.
Connect to an Arista, Cisco Nexus, Cisco Catalyst, Juniper JunOS, or FortiGate FortiOS device via SSH and run an operational read command. Arista/Cisco/JunOS commands must start with 'show'. FortiOS commands must start with 'get'. Running-config and startup-config are not allowed here — use the get_config tool instead. For JunOS, set device_type='junos'; 'show configuration' is also blocked and redirected to get_config. For FortiOS, 'show', 'config', 'execute', and 'diagnose' commands are blocked here. Append '| json' for structured output (Arista/Cisco), or '| no-more' to disable pagination. Examples: 'show bgp summary | json', 'show interfaces status | json', 'show lldp neighbors detail | json', 'show inventory | json', 'show version | json', 'get system status', 'get router info routing-table all'.
Output schemas not documented. LLMs cannot predict response structure, forcing them to guess what fields are returned and how to chain tools.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). trust_host_key is WRITE; get_config, run_show_command, run_ping, run_traceroute are READ_ONLY. Annotations enable agents to reason about safety and retry logic.
Parameter constraints are implicit in descriptions rather than formal schema enums. device_type accepts 'eos', 'ios', 'nxos', 'junos', 'fortios' but no enum constraint prevents LLM hallucination of invalid values like 'arista' or 'cisco'.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | <=2025-11-25 | v2 |
Connect to an Arista, Cisco Nexus, Cisco Catalyst, Juniper JunOS, or FortiGate FortiOS device via SSH and run a traceroute. Shows the hop-by-hop path to a destination and per-hop latency. Useful for locating where connectivity breaks, verifying traffic follows the expected path, and identifying which hop introduces latency. Use device_type to select the correct syntax: 'eos' (Arista), 'ios' (Cisco IOS/IOS-XE), 'nxos' (Cisco NX-OS), 'junos' (Juniper JunOS), or 'fortios' (FortiGate/FortiOS). On IOS, vrf must be specified via device_type='ios' so it is placed correctly before the destination in the command. On JunOS, max_hops maps to the ttl keyword, timeout maps to wait, probe is not supported, and vrf maps to routing-instance. On FortiOS 7.4+, probe maps to execute traceroute-options queries, source maps to source, and outgoing_interface maps to device; max_hops, timeout, and vrf are not supported. Optional parameters: max_hops, timeout (per-probe seconds), probe (probes per hop, not used on JunOS), source (source IP or interface), vrf (routing-instance on JunOS), outgoing_interface (FortiOS only).
Fetch the SSH host key currently presented by a device and optionally add it to the configured known_hosts file. Call it first with confirm=false to inspect the fingerprint, then call it again with confirm=true after the user verifies the fingerprint. If a host key has legitimately changed, set replace_existing=true to replace the stored key after verification.
No error handling guidance. Tools do not document what errors are retryable, what indicates user misconfiguration, or what recovery steps to take (e.g., 'SSH connection failed, verify host, port, and credentials').
Parameter descriptions lack format specifications. 'host' should state 'IPv4, IPv6, or FQDN'; 'port' should state 'integer 1 - 65535, defaults to 22'; 'count' should state 'integer 1 - 100'. Without constraints, LLMs pass invalid values.