Skip to main content
Glama
cacack

vyos-mcp

by cacack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

vyos_traceroute

Trace network paths from a VyOS router to a host and return per-hop loss and latency, helping diagnose reachability and routing issues.

Instructions

Traceroute to a host from the router.

Returns the API response with an mtr report (per-hop loss and
latency) in its data field. Useful for diagnosing reachability and
path issues from the router's perspective. The host must be a valid
hostname or IP address.

Args:
    host: Destination hostname or IP, e.g. "8.8.8.8"
    vrf: Optional VRF to trace from. Needs VyOS rolling 2026-08-24 or
        later; older routers silently ignore it and use the default VRF.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vrfNo
hostYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.0
    • addedInput schema / properties / vrf
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Vrf"
+}
  2. Addedv0.3.0

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses the return shape (mtr report with per-hop loss and latency in the data field) and a genuine failure mode — the vrf argument is silently ignored on routers older than VyOS rolling 2026-08-24. Missing are execution characteristics such as timeout/duration or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The behavior, purpose, and return format are front-loaded before the Args block, and every sentence carries information. The Args section is somewhat verbose but each entry earns its place; nothing is repetitive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no annotations exist, so the description is the sole source of contract information, and it covers return format, parameter meaning, and the version caveat. It is nearly complete for a read-only diagnostic tool, lacking only execution-time and permission details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does: host is defined as a hostname or IP with an example, and vrf is documented as optional with a version prerequisite and its silent-fallback behavior. Both parameters gain meaning the schema alone does not provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Traceroute to a host from the router') and clarifies the perspective ('from the router's perspective'), which separates it from client-side tracing. It does not explicitly name the obvious sibling vyos_ping or contrast with it, so sibling differentiation is only implied.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Useful for diagnosing reachability and path issues' gives a use case, but there is no when-not guidance and no named alternative (e.g. use vyos_ping when you only need round-trip reachability). Usage is implied rather than prescribed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools