Skip to main content
Glama
cacack

vyos-mcp

by cacack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

vyos_config_diff

Show what a VyOS commit revision changed. Returns a unified diff of the specified revision (default most recent) to track configuration changes.

Instructions

Show what a commit revision changed (not a running-config comparison).

Returns a unified diff of revision rev+1 -> rev, i.e. what that
commit changed. Defaults to the most recent commit (rev 0). Revision
numbers are the `revision` values listed by vyos_config_history.

Note: the VyOS HTTP API cannot compare the running config against
the saved config, so this tool only diffs committed revisions.

Args:
    rev: Commit revision number (omit or 0 = most recent)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
revNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.3/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 type (unified diff), the exact direction (rev+1 -> rev), the default target, and an important API limitation. It omits permission/auth/rate-limit context, but the core behavior is transparent.

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?

Front-loads the one-line purpose before the detail, and the note about API limitations earns its place. The Args restatement is slightly redundant but brief and useful given the empty schema description.

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 exists, but the description explains the return format (unified diff of consecutive revisions), so an agent knows what to expect. Combined with the default behavior and the source of revision numbers, it is sufficient for correct invocation.

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 coverage is 0% and the description fully compensates: it defines rev as a commit revision number, states that omitting it or passing 0 yields the most recent commit, and points to vyos_config_history for obtaining valid values.

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

Purpose5/5

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

States a specific verb (diff/show changes) and resource (commit revision) and explicitly distinguishes itself from a running-config comparison. It also names the sibling vyos_config_history as the source of revision numbers, letting an agent place it precisely among the many vyos_* config tools.

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

Usage Guidelines4/5

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

Explains the default (most recent commit, rev 0) and the key when-not constraint ('cannot compare the running config against the saved config'), which steers agents away from a misuse. It does not explicitly route to an alternative tool, but the scope and default are clear enough to invoke correctly.

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