vyos-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: set, delete, comment, batch configure, check existence, generate keys, manage images, get system info, load/merge/save config, reset sessions, read multi-valued nodes, run show commands, retrieve config subtrees, and system control. No two tools overlap in purpose.
Naming Consistency4/5
All tools follow the vyos_<verb>_<noun> pattern (e.g., vyos_configure_batch, vyos_save_config) with a few noun-only names like vyos_info and vyos_image. The naming is largely consistent and intuitive, with minor exceptions.
Tool Count5/5
With 17 tools, the set is well-scoped for VyOS router management. It covers configuration operations, system control, monitoring, and diagnostics without being excessive or sparse.
Completeness5/5
The tool surface provides comprehensive lifecycle coverage: create, read, update, delete, commit confirm, save, load, merge, existence check, multi-value retrieval, operational show commands, image management, and system reboot/poweroff. No obvious gaps.
Average 4.3/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (write), destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds the default path and return type but does not provide additional behavioral context such as permissions needed or side effects beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences covering purpose, default behavior, optional parameter, and return value. No extraneous text, every sentence serves a clear function. Structure is clean and front-loaded.
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?
Given the tool's simplicity (one optional parameter, a clear return type, and annotations covering safety and idempotency), the description covers the essential aspects: purpose, default path, optional custom path, and return. It lacks mention of file accessibility or overwrite behavior, but these are minor given the context. Overall, fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'file — optional save path', repeating the schema's description. The schema already documents the 'file' parameter as optional with default null. With schema description coverage reported as 0%, the description adds minimal extra meaning beyond the schema, achieving only the baseline.
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?
The description clearly states 'Save the running configuration to disk' with a specific verb and resource. This distinguishes it from siblings like vyos_load_config (load config) and vyos_show_config (show config), ensuring unambiguous purpose.
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?
The description implies usage by describing the action (save to disk, default path, optional custom path), but does not explicitly state when to use this tool vs alternatives or when not to use it. No exclusions or alternative tool names are given, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and readOnlyHint=false. The description adds context that the entire running config is replaced, which goes beyond annotations. However, it does not detail other behaviors like commit behavior or rollback information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a main sentence, warning, args line, and returns line. Every sentence adds value, and the warning is front-loaded for immediate attention.
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?
For a simple tool with one parameter and a clear output schema, the description covers the core behavior and warning. It could mention error handling or post-load state, but the output schema (success/error) and annotations provide sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the 'file' parameter with an example path. The tool description repeats this info ('absolute path on VyOS filesystem') without adding new meaning. Schema coverage is effective, so baseline 3 is appropriate.
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?
Clearly states 'Load a configuration file, replacing the running configuration.' This specifies the action (load) and resource (configuration file) and distinguishes from sibling vyos_merge_config by indicating replacement versus merging.
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?
The warning 'replaces the entire running config' implicitly advises against use when partial changes are desired, but no explicit comparison to alternatives (e.g., vyos_merge_config) or context for when to choose this tool is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds minimal extra behavioral context (e.g., returns success/error message) but does not elaborate on side effects or permissions. No contradiction with annotations.
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 description is well-structured with a clear first line, args/returns summary, and examples. It is informative but somewhat lengthy; could be trimmed without losing clarity. Still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single set operation, the description covers the purpose, parameters, return value, and usage examples. It is sufficient for an AI agent to understand and invoke the tool correctly, especially given the output schema.
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?
The input schema provides good descriptions for both parameters, including the path structure as an array of strings. The description adds value by clarifying that the last element is the value and by providing multiple concrete examples (e.g., setting address, hostname).
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?
The description clearly states 'Set a single VyOS configuration path' and equates it to 'set <path>' in configure mode, providing specific verb+resource. It distinguishes from sibling tools like vyos_delete and vyos_show.
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?
The description explains the tool's function as equivalent to the 'set' command but does not provide explicit guidance on when to use this tool versus siblings (e.g., vyos_configure_batch for batch operations). Usage context is implied but lacks exclusionary criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior; the description adds that it removes the node and all children, and equates to CLI delete mode, providing useful behavioral context beyond annotations.
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 description is well-structured with a clear first sentence, then effect explanation, parameter list, and examples. Though slightly verbose, it remains readable and front-loaded.
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?
The description covers deletion behavior, parameters, and examples. Output schema exists, so return value detail is sufficient. Minor gap: behavior on non-existent path is not explicitly addressed, but idempotent hint partially covers it.
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% per context, so the description compensates by listing parameters with brief meanings and providing concrete examples that illustrate path usage for common deletions.
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?
The description clearly states the tool deletes a VyOS configuration path and explains it is equivalent to the CLI 'delete <path>' command, which distinguishes it from set, show, and other sibling tools.
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?
The description explains the tool's function but does not explicitly compare it to siblings or provide when-to-use vs. when-not-to-use guidance. It implies usage for deleting config nodes but lacks direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds transparency by explaining that merging does not remove unrelated configuration and supports commit-confirm for safe rollback, which is useful behavioral context beyond annotations.
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 description is well-structured with paragraphs, bullet-pointed args, and examples. It is concise without being overly terse, though the example section could be slightly trimmed.
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?
The description covers purpose, parameters, return type, and examples. With an output schema present (though not shown), the return value is adequately handled. Minor gaps exist for error conditions and prerequisites, but overall it is sufficient for a merge operation.
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?
Despite schema description coverage being 0%, the description adds value by explaining the exclusive OR relationship between 'file' and 'string' parameters, and clarifies that 'confirm_time' is for rollback timeout. This goes beyond the schema's individual descriptions.
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?
Description clearly states the verb 'merge', the resource 'configuration', and the source ('file or inline string'). It also differentiates from siblings like vyos_load_config by explaining the merge semantics (adds/overwrites without removing unrelated config).
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?
The description explains what the tool does but does not explicitly state when to use it over alternatives like vyos_set or vyos_load_config. It implies usage through the merge behavior and commit-confirm support, but lacks explicit guidance on exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds context about the return format (JSON) and the behavior of empty vs. non-empty paths. It does not contradict annotations and provides useful behavioral details beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a short introduction, clear Args and Returns sections, and multiple examples. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose of retrieving configuration, the description covers how to invoke it with any path, the return type, and provides practical examples. With an output schema present, the description is sufficient for an AI agent to use the tool correctly.
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?
The schema has partial description for the path parameter, but the overall schema coverage is listed as 0%. The description compensates by explicitly explaining the 'path' argument in Args and providing concrete examples, adding semantic value beyond the schema.
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?
The description clearly states 'Retrieve the running VyOS configuration (full or partial).' specifying the action and resource. It does not explicitly differentiate from sibling tools like vyos_show or vyos_info, but the purpose is well-defined.
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?
The description provides explicit usage guidance: passing an empty path for full config or specifying path segments for a subtree. It includes multiple examples for different use cases. However, it does not mention when to use alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds minimal behavioral context beyond the command equivalence, but doesn't elaborate on side effects like whether the comment persists through reboots or affects validation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs, includes an 'Args' and 'Returns' structure, and contains no superfluous text. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety, the description sufficiently explains the tool's purpose, usage, and parameter semantics. No additional information is needed 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?
The description clarifies that the last element of the path list is the comment text, which adds meaning beyond the schema's generic 'config path segments' description. This helps the agent construct proper inputs.
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?
The description clearly states the tool adds a comment to a VyOS configuration node and specifies it is equivalent to the 'comment <path>' command in configure mode. This specific verb+resource combination distinguishes it from siblings like vyos_set and vyos_delete.
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?
The description includes the configure-mode equivalence, which helps understand when to use it. However, it does not explicitly state when not to use it or list alternative tools for similar tasks, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining atomic commit behavior and the confirm_time parameter's rollback mechanism. No contradiction with annotations, but it doesn't cover failure behavior or full side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose, followed by usage, Args/Returns, and examples. Every sentence adds value without redundancy, making it concise yet comprehensive.
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?
Given the tool's complexity and the presence of an output schema, the description covers core behavior, parameters, and examples. It lacks edge-case handling but is sufficient for an agent to use correctly.
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?
The input schema already provides descriptions for parameters (operations, confirm_time, ConfigOp), so baseline is 3. The description adds concrete examples that illustrate parameter usage and structure, improving clarity.
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?
The description clearly states it applies multiple configuration operations in a single atomic commit, with specific use cases (VXLAN, firewall rules) that differentiate it from single-operation siblings like vyos_set or vyos_delete.
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?
The description explicitly says to use it for changes that must be applied together and provides examples, but does not explicitly say when not to use it or contrast with alternatives beyond implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only, non-destructive, non-idempotent, and open-world behavior. The description adds context by stating the return type (generated output or error) and examples of what is generated. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences plus examples) and well-structured with Args, Returns, and Examples sections. The first sentence immediately communicates the tool's purpose.
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?
The description covers purpose, usage guidelines, parameters, and return type. For a simple generate tool with one parameter and an output schema, it provides sufficient context, though error handling could be slightly more detailed.
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?
Although schema description coverage is 0% for the top-level parameter, the description explains 'params: path — generate command path segments' and provides domain-specific examples for generating keys, adding value beyond the generic schema description.
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?
The description clearly states the tool runs a VyOS 'generate' command for generating cryptographic keys, certificates, and other system components. It uses a specific verb ('generate') and resource, distinguishing it from sibling tools like vyos_set or vyos_delete.
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?
The description provides concrete examples (WireGuard keypair, OpenVPN keys) and states the general use case. It does not explicitly mention when not to use the tool or contrast with siblings, but the examples offer clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. Description confirms add/delete behavior but adds little beyond annotations, such as irreversible nature of deletion or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two-sentence summary followed by structured args and returns. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple image management tool with output schema, the description covers all essential aspects: purpose, parameters, and return value. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description explains conditional parameter requirements (url required for add, name required for delete) beyond the schema's property descriptions, adding clear semantics.
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?
Clearly states it adds or deletes VyOS system images, with explicit verb+resource. Distinguishes from siblings like vyos_set or vyos_delete that handle configuration, not images.
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?
Provides clear instructions for when to use 'add' vs 'delete' and required parameters. Lacks explicit when-not or alternatives compared to sibling tools, but sufficient for basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. Description adds that it returns a JSON array, which is actionable. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise with clear sections (use, args, returns, examples). Every sentence adds value. No redundancy.
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?
Simple tool with one parameter, output described. Examples cover common use. Could mention edge cases, but adequate for correct usage.
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%, so description must compensate. It describes 'path' as 'path to the multi-valued node', adding context beyond schema's generic description.
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?
Description clearly states it returns values of a multi-valued config node, with examples (interface addresses, DNS servers). Differentiates from siblings like set/delete/show.
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?
Explicitly says 'Use this for nodes that hold multiple values', providing clear context. Lacks explicit when-not-to-use or comparison to siblings, but implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it returns text output and is equivalent to the VyOS CLI show command, which is consistent with annotations and provides helpful operational context.
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 description is well-organized with sections for description, equivalence, args, returns, and examples. It is somewhat lengthy but every part contributes to clarity, making it easy to read and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only command tool with one parameter, the description is complete. It covers the purpose, parameter meaning, return type, and provides examples. Annotations cover safety. No output schema is shown, but the return type 'str' is stated, which is sufficient.
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?
The schema for path has detailed descriptions, but the top-level 'params' parameter lacks a description. The tool's description explains that params are path segments and provides numerous examples, adding value beyond the schema, especially since schema coverage is reported as 0% for the parameter.
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?
The description clearly states it runs an operational-mode 'show' command, equivalent to 'show <path>' in VyOS CLI. It provides specific examples of command paths (e.g., system images, interfaces, BGP summary), distinguishing it from siblings like vyos_show_config which likely shows configuration.
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?
The description gives explicit examples of when to use the tool for various status queries. It implicitly excludes configuration tasks but does not explicitly state when not to use it or name alternatives. The examples cover a wide range of common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral detail beyond annotations: it explains the timer and rollback mechanism. Annotations indicate idempotentHint=true and destructiveHint=false, but the description provides actionable context about what happens if the tool is not called. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states action, second explains usage context, third declares return type. Front-loaded and every sentence earns its place. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, an output schema present, and annotations covering safety, the description is fully complete. It explains purpose, when to use, and what to expect as output.
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?
There are zero parameters, so schema coverage is 100%. The description correctly avoids adding parameter info. Baseline of 4 is appropriate for a parameterless tool.
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?
The description clearly states the tool confirms a pending commit-confirm timer, using a specific verb and resource. It distinguishes itself from sibling tools like vyos_configure_batch or vyos_set by focusing on the confirmation action.
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?
Explicitly specifies when to use: when a previous configure or merge operation had confirm_time, and before the timer expires. It explains the consequence of not using it (automatic rollback). While no alternative tools are named, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the return value is the string 'true' or 'false', which is useful but not critical given the output schema exists. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single sentence stating purpose, followed by return type, usage hint, parameter description, return description, and two examples. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, read-only, no destruction), the description covers all necessary aspects: purpose, return type, usage, parameter, and examples. It is complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats the parameter name ('path') and mentions it is a list of path segments, but the input schema already provides a thorough description of the path parameter. Thus, the description adds minimal new semantics.
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?
The description clearly states the tool checks whether a configuration path exists and returns true/false. It uses a specific verb ('Check') and resource ('configuration path'), distinguishing it from sibling tools like vyos_set or vyos_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Useful before setting or deleting a path,' providing clear when-to-use guidance. Examples further clarify typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds context that it resets runtime state only, not saved configuration, and provides examples of what gets reset. This complements the annotations well without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections (Args, Returns, Examples). Every sentence adds value, and the examples are immediately useful. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers all necessary aspects: purpose, parameters, return type, and behavioral notes. The examples make it clear how to use the tool for common tasks.
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?
The schema has 0% description coverage (the PathInput description is included but not the parameter itself). The description explains 'params: path — reset command path segments' and gives multiple examples that clarify how to form the path for different resets. This adds significant meaning beyond the schema.
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?
The description clearly states it runs a VyOS 'reset' command, specifies that it resets protocol sessions, counters, or runtime state, and explicitly distinguishes from saved configuration. This differentiates it from sibling tools like vyos_set, vyos_delete, etc.
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?
The description provides concrete examples (BGP peer, all BGP, OSPF, counters) and notes that it does not affect saved config. However, it does not explicitly state when not to use it or compare with alternatives like vyos_delete or vyos_configure_batch. The examples give clear guidance on typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: explicitly warns that the router goes offline, matches destructiveHint true. Also notes return value. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one-line purpose, critical warning, bullet-point parameters, return. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, criticality, parameter details, and return value. For a simple control tool with output schema, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description repeats the schema info for action and confirm. While schema coverage for top-level params is 0%, the schema internally describes the parameters well. Description adds minimal extra value.
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?
Description clearly states 'Reboot or power off the VyOS router', which is a specific verb-resource pair. It distinguishes from sibling tools that handle configuration, show commands, etc.
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?
Explicitly states when to use (reboot/poweroff) and highlights critical condition (confirm must be true). Does not explicitly mention when not to use or alternatives, but the context of sibling tools makes this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral info beyond annotations: no auth required, returns JSON with specific fields. Annotations already indicate read-only and idempotent; description aligns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete given zero parameters and existing output schema. Covers purpose, auth, and output format.
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?
No parameters; baseline 4. Description adds no param info but none needed.
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?
Description clearly states it retrieves public system info (version, hostname, banner). Distinct from siblings like vyos_show which likely show configuration.
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?
Mentions no auth required and useful for connectivity verification. Lacks explicit comparison to siblings or when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![vyos-mcp MCP server](https://glama.ai/mcp/servers/alch3mistdev/vyos-mcp/badges/card.svg)](https://glama.ai/mcp/servers/alch3mistdev/vyos-mcp)

Score Badge

Copy to your README.md:

[![vyos-mcp MCP server](https://glama.ai/mcp/servers/alch3mistdev/vyos-mcp/badges/score.svg)](https://glama.ai/mcp/servers/alch3mistdev/vyos-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/alch3mistdev/vyos-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server