How do I use DrayTek Vigor MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DrayTek Vigor MCP Server Check the DSL status" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

DrayTek Vigor MCP Server

by thelad-dev

Overview Schema Related Servers Score Discussions

Python

Local

DrayTek Vigor 167 MCP Server

MCP-Server für DSL-Diagnose und CLI-Zugriff am DrayTek Vigor 167 (Firmware 5.2.8) über interaktive SSH-Shell.

Befehle werden nicht geraten: Discovery läuft live gegen das Gerät (? / help) und wird unter cache/command_tree.json gecacht. Convenience-Tools und Parser basieren auf verifiziertem CLI-Output.

Status

Komponente	Status
Python venv (`.venv`)	`mcp[cli]` + `paramiko` installiert
Cursor MCP (`~/.cursor/mcp.json`)	Noch nicht eingetragen — siehe Abschnitt Cursor einbinden
`.env` mit Modem-Credentials	Lokal vorhanden, nicht im Git

Related MCP server: ssh-mcp

Voraussetzungen

Python 3.11+
Netzwerkzugang zum Modem (Standard: 192.168.167.1:22)
Cursor oder anderer MCP-Client
DrayTek Vigor 167 mit eingeschränkter Bridge-CLI (kein voller DrayOS-Befehlssatz)

Schnellstart

cd ~/Workspaces/draytek-vigor-mcp
python -m venv .venv
source .venv/bin/activate
pip install "mcp[cli]" paramiko

.env anlegen (Format siehe unten), dann Discovery testen:

.venv/bin/python discover.py 2 --refresh
.venv/bin/python -c "from vigor_ssh import run_command; print(run_command('exec dslinfo'))"

Server manuell starten (stdio-MCP):

.venv/bin/python server.py

Credentials (`.env`)

Nicht committen (steht in .gitignore). Kein Standard-dotenv — Parsing: erstes : trennt Schlüssel und Wert, umschließende " am Wert werden entfernt.

mcp:"geheim"
VIGOR_HOST:"192.168.167.1"
VIGOR_PORT:"22"

Optional:

VIGOR_PROMPT:"vigor>\\s*$"
VIGOR_IDLE_SEC:"0.8"

Die erste Zeile ohne reservierten Schlüssel (VIGOR_*) ist der CLI-Benutzername; der Wert ist das CLI-Passwort.

SSH- und CLI-Ablauf (Vigor 167)

Am 167 unterscheidet sich der Ablauf von klassischen DrayTek-Routern:

SSH-Transport: auth_none (kein SSH-Passwort/Key nötig)
Interaktive Shell: invoke_shell + PTY — exec_command liefert oft leere Ausgabe
CLI-Login: Gerät fragt Username: / Password: (Credentials aus .env)
Prompt: vigor>
Neue Session pro Aufruf: Das Modem beendet idle SSH-Sessions

enable ist in der CLI vorhanden, aber am Vigor 167 ohne konfigurierbares Passwort nutzlos (Access denied). DSL-Diagnose funktioniert ohne privilegierten Modus.

Cursor einbinden

Eintrag in ~/.cursor/mcp.json unter mcpServers ergänzen:

{
  "mcpServers": {
    "draytek-vigor": {
      "command": "/home/ladwein/Workspaces/draytek-vigor-mcp/.venv/bin/python",
      "args": ["/home/ladwein/Workspaces/draytek-vigor-mcp/server.py"],
      "cwd": "/home/ladwein/Workspaces/draytek-vigor-mcp"
    }
  }
}

Danach Cursor neu laden oder MCP-Server in den Einstellungen aktivieren.

MCP-Tools

Tool	CLI-Befehl	Beschreibung
`discover_commands`	`?`, `exec ?`, `config ?`, `help`	Befehlsbaum vom Gerät (gecacht)
`run_command`	beliebig	Einzelbefehl ausführen
`run_commands`	beliebig	Mehrere Befehle in einer SSH-Session
`get_dsl_info`	`exec dslinfo`	Sync-Status, Profil, Raten, SNR
`get_system_info`	`exec sysinfo`	Modell, Firmware, Build-Infos
`get_device_time`	`exec date`	Gerätezeit
`get_services`	`exec services`	Offene Dienste/Ports
`get_config_status`	`exec cfg status`	Config-Profil-Status
`get_command_tree_summary`	—	Gecachter Discovery-Baum

run_command / run_commands decken per Definition alle vom Gerät akzeptierten Befehle ab. Ungültige Befehle liefern die Geräte-Fehlermeldung im Ergebnis, keine Exception nach außen.

Beispiel `get_dsl_info` (FW 5.2.8, verifiziert)

Status : Showtime
Mode : VDSL2
Profile : 17a
Annex : ANNEX B
DSL Version : 5.12.31.0_B_A60901
Line Uptime : …
Downstream Line Rate : … kbps
Upstream Line Rate : … kbps
SNR Downstream : … dB
SNR Upstream : … dB

Nicht verfügbar in exec dslinfo auf 5.2.8: Attenuation, CRC/FEC/ES/SES — dafür gibt es bewusst kein Convenience-Tool.

Verifizierter Befehlsbaum (Kurzüberblick)

Top-Level (`?`)

help, quit, logout, history, enable, exit, config, exec

Exec (`exec ?`)

date, ping, reboot_system, operation_mode, lan_mtu, wan_mtu, dot3ah_oam, y1731, dsl_dbg, dsl_35b_enhance, dsl_35b_target, process_dbg, tr069, coredump, sysinfo, telnet, cfg, services, dslinfo, nat_prio

Config (`help`, Auszug)

config Configuration Physical_Interface
config Configuration WAN WAN_Connections
config Monitoring DSL_Status Monitoring_DSL_General
config Monitoring DSL_Status Monitoring_DSL_Tone
config System_Maintenance Device_Settings Time
config System_Maintenance Management Access_Control
…

Config-Zweige nutzen Web-Form-CLI (show / edit); ohne enable kaum schreibbar.

Vollständiger Baum: cache/command_tree.json oder discover.py 2 --refresh.

Discovery manuell

.venv/bin/python discover.py 2 --refresh

Parameter: Tiefe (Standard 2), --refresh erzwingt Neuerkennung.

Projektstruktur

server.py       MCP-Server (FastMCP)
vigor_ssh.py    SSH auth_none, CLI-Login, Prompt-Handling
discover.py     Befehls-Discovery via ?
parsers.py      Regex-Parser für verifizierte Ausgaben
pyproject.toml  Abhängigkeiten
cache/          command_tree.json (generiert, nicht committen)
.env            Credentials (lokal, nicht committen)

Hinweise und Grenzen

Bridge-Modem: Absichtlich eingeschränkte CLI — kein voip/qos/etc. wie bei großen DrayOS-Routern.
Kein enable: Privilegierte Config-Befehle über CLI nicht erreichbar.
Timing: VIGOR_IDLE_SEC erhöhen (z. B. 1.0), falls Ausgaben abgeschnitten werden.
Credentials: Niemals in Code, Logs oder Commits — nur in .env.
Parser: Nur für tatsächlich gelieferte Felder; bei Firmware-Änderungen Discovery und Parser neu verifizieren.

Fehlerbehebung

Symptom	Ursache / Lösung
Leere SSH-Ausgabe	Kein PTY / `exec_command` — dieser Server nutzt `invoke_shell`
`Access denied` bei `enable`	Erwartet; am 167 kein Enable-Passwort
`Authentication failed` (Paramiko)	Am 167 `auth_none` + CLI-Login — `vigor_ssh.py` nutzt Transport, nicht Passwort-SSH
Abgeschnittene CLI-Ausgabe	`VIGOR_IDLE_SEC` in `.env` erhöhen
MCP-Tools fehlen in Cursor	Eintrag in `~/.cursor/mcp.json` fehlt — siehe oben

Lizenz / Gerät

Getestet gegen DrayTek Vigor 167, Firmware 5.2.8, Host 192.168.167.1.

Available Tools

9 tools

discover_commandsB

Discover CLI commands via '?' on the device. Results are cached on disk.

ParametersJSON Schema

Name	Required	Description	Default
`depth`	No
`refresh`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that results are cached on disk, which is useful behavioral information. However, it does not mention if the tool has side effects, requires authentication, or how long the cache persists.

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 at two sentences. The first sentence delivers the core purpose, and the second adds an important behavioral note (caching). No word is wasted.

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

Completeness3/5

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

With an output schema present, the description does not need to detail return values. However, it lacks explanation of caching behavior (e.g., how to clear cache) and does not describe the depth parameter's effect on result breadth. For a low-complexity tool, additional context on parameters would improve completeness.

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

Parameters2/5

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

Schema description coverage is 0%, yet the description does not explain the parameters 'depth' or 'refresh'. These parameters are critical for controlling behavior, and their semantics are left entirely to the schema names and defaults.

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's action ('Discover CLI commands'), the target resource ('CLI commands'), and the method ('via '?' on the device'). It distinguishes itself from sibling tools like run_command and get_command_tree_summary by focusing on discovery rather than execution or retrieval.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, such as get_command_tree_summary or run_commands. It mentions caching but does not explain when caching is beneficial or when a refresh is needed.

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

get_command_tree_summaryA

Return cached discovery tree or refresh if missing.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses the read-like behavior (return cached or refresh), but does not explain whether refresh blocks, has side effects, or any performance implications. Basic transparency but lacks depth.

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?

Single sentence, no filler, efficiently communicates the tool's purpose and special behavior. Every word earns its place.

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 empty input schema, existence of output schema (handles return values), and siblings, the description is adequate. It could elaborate on what 'refresh if missing' entails, but overall sufficient for a simple cached read 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?

Input schema is empty (0 parameters) and schema description coverage is 100%. Description adds no parameter info, but no parameters exist, so baseline score of 4 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?

The description clearly states the tool returns a cached discovery tree and refreshes if missing. The verb 'return' and resource 'cached discovery tree' are specific, and the mention of caching distinguishes it from sibling tools like discover_commands which likely performs a full discovery.

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?

Usage context is implied (use when you want the cached tree), but there is no explicit guidance on when to use this versus alternatives like discover_commands. No exclusions or prerequisites are mentioned.

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

get_config_statusA

Config profile status via verified command 'exec cfg status'.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

The description discloses the exact underlying command 'exec cfg status' and labels it as verified, indicating safety; no annotations exist, so it carries the burden well.

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 a single sentence that conveys the entire purpose without 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?

With no parameters and an output schema present, the description fully covers the tool's behavior in context with sibling tools.

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 exist, so the description's silence on parameters is acceptable; baseline 4 for zero-parameter tools applies.

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 retrieves config profile status via a specific verified command, distinguishing it from generic command execution tools like run_command.

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 implies usage for safe, verified config status retrieval, but does not explicitly exclude alternative tools or scenarios.

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

get_device_timeA

Device clock via verified command 'exec date'.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the command is 'verified', implying safety and reliability, but does not detail any potential side effects or prerequisites. Adequate for a simple read-only operation.

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?

Single sentence, front-loaded with key information, no unnecessary words. Perfectly concise for a tool with no arguments.

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 zero parameters and an existing output schema, the description is nearly complete. However, it does not hint at the output format (e.g., timestamp type), leaving a small gap for an agent expecting detailed return structure.

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 exist, and schema coverage is 100%, so the description adds no additional parameter meaning. Baseline 4 is appropriate given no params require explanation.

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 states 'Device clock via verified command exec date', clearly indicating the tool retrieves the device time using a specific command. It differentiates from siblings like run_command by emphasizing verification and specificity.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like run_commands. The description fails to mention that this tool is safer or more authoritative for time retrieval.

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

get_dsl_infoB

DSL sync status via verified command 'exec dslinfo'.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavioral traits. It mentions executing a command but does not state if it is read-only, if it requires authentication, or if there are any side effects. The term 'verified' hints at safety but is insufficient.

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?

Single sentence with no unnecessary words. Front-loads the purpose ('DSL sync status'). Highly concise.

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

Completeness3/5

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

For a tool with no parameters and an output schema, the description is brief but misses high-level explanation of what 'sync status' entails. Could mention key fields or whether it's real-time data. Output schema may supplement, but description could be more informative.

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 in input schema, so description does not need to add parameter meaning. The mention of 'exec dslinfo' provides context on what is executed, which is a bonus.

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?

Description clearly states the tool retrieves DSL sync status via a specific command. The verb 'get' and resource 'DSL sync status' are clear, and it distinguishes from siblings like get_device_time by specifying the exact command used.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as run_command or other info tools. The description does not mention prerequisites or context where this tool is preferred.

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

get_servicesA

Open CPE services via verified command 'exec services'.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It states 'verified command' implying safety, but does not disclose whether it is read-only, what side effects (if any) occur, error conditions, or permission requirements. The description lacks sufficient behavioral detail.

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 a single, clear sentence with no redundant words. It directly conveys the tool's action and the method used.

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

Completeness3/5

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

Given zero parameters and an existing output schema, the description is partially complete. However, it does not explain what 'services' are returned (e.g., list of names, status details) or any prerequisites (e.g., device must be connected). The description could provide more context about the output format or typical use cases.

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 has no properties, so parameter semantics are trivially satisfied. The description adds no parameter information, but since there are no parameters to document, a baseline score of 4 is appropriate (no missing information).

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 retrieves CPE services using a specific command ('exec services'). It distinguishes from sibling tools like run_command (which executes arbitrary commands) and discover_commands (which lists available commands).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as run_command or get_system_info. It mentions a 'verified command' but does not explain when this is appropriate or when other tools might be better.

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

get_system_infoA

Firmware and device info via verified command 'exec sysinfo'.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

Discloses that the tool runs a verified command 'exec sysinfo', implying a safe read operation. With no annotations, this is sufficient behavioral transparency.

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?

Single, direct sentence with no unnecessary words. Efficiently conveys 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?

While brief, the description is complete for a no-parameter tool. Output schema exists, so return values need not be explained. Covers what the tool does adequately.

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 exist, so schema coverage is 100%. The description adds no parameter details, but none are needed. Baseline 4 applies.

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 the tool retrieves firmware and device information via a specific verified command 'exec sysinfo', distinguishing it from sibling tools like run_command.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as discover_commands or get_device_time. The description does not mention context or exclusions.

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

run_commandC

Run an arbitrary DrayTek CLI command over SSH.

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, so the description bears full burden. It mentions SSH but does not disclose authentication needs, potential destructive effects, or command restrictions. The tool runs arbitrary commands which could be dangerous.

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

Conciseness3/5

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

A single sentence is efficient, but given the lack of parameter explanation and guidelines, it is too terse. It is not well-structured for an AI agent.

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

Completeness2/5

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

The tool has an output schema (not shown) so returns are not required, but the description omits essential context like authentication, safety, and limitations for a command execution tool.

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

Parameters1/5

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

Schema description coverage is 0% and the description adds no meaning to the 'command' parameter. It does not explain format, examples, or constraints 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 the action (run a command) and the resource (DrayTek CLI command over SSH). It is specific but does not differentiate from the sibling tool 'run_commands' which might handle multiple commands.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus its siblings like 'discover_commands' or 'run_commands'. The description lacks context for appropriate usage.

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

run_commandsC

Run multiple CLI commands in one SSH session.

ParametersJSON Schema

Name	Required	Description	Default
`commands`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full disclosure burden. It mentions 'one SSH session' implying statefulness but omits critical traits like error handling, command separation, output behavior, or safety implications.

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 a single, front-loaded sentence with no superfluous words. It efficiently conveys core purpose.

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

Completeness2/5

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

Despite having an output schema, the description does not mention return values, which is critical for a tool that runs multiple commands. Combined with missing parameter details, the description is insufficient for complete understanding.

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

Parameters1/5

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

Schema description coverage is 0%, yet the description adds no detail about the 'commands' parameter. It does not clarify expected format, delimiters, or constraints, failing to compensate for the schema gap.

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 action ('Run'), the resource ('multiple CLI commands'), and the context ('in one SSH session'). It effectively distinguishes from sibling 'run_command' by indicating batch execution.

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

Usage Guidelines2/5

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

No explicit guidance is provided on when to use this tool versus alternatives like 'run_command' or discover tools. The description lacks usage context, conditions, or exclusions.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose. For example, discover_commands and get_command_tree_summary are related but serve different stages (discovery vs. cached retrieval), while run_command and run_commands differ in the number of commands executed. No two tools could be easily confused.

Naming Consistency5/5

All tools use snake_case with a consistent pattern: get_ prefix for status retrieval, discover_ for discovery, and run_ for command execution. The naming is uniform and predictable.

Tool Count5/5

9 tools is well-scoped for a network device management server. It covers discovery, common status queries, and arbitrary CLI execution without being too many or too few.

Completeness4/5

The tool set covers discovery, status checks, and command execution. While it lacks dedicated tools for some operations (e.g., interface stats, reboot), these can be achieved via run_command. Minor gaps exist but do not severely hinder common use cases.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp A
com.domainposture
Remote MCP server: 19 domain-hygiene and email-auth tools (DNS, SPF, DMARC, DKIM, TLS).
Security Networking & Infrastructure
222
termalin-web A
in.termal
Run commands and read/write files on your servers over Termalin's keyless tunnels (hosted MCP).
Shell Access File Systems
61
Tailscale RMCP
ai.dinglebear
Tailscale device, route, DNS, key, user, and ACL management over MCP and CLI.
Networking & Infrastructure Security Cloud Platforms
15
meok-mcp-hardening-mcp
io.github.CSOAI-ORG
MEOK MCP Hardening MCP — automated security red-team for any MCP server. Maps OWASP LLM Top 10
Penetration Testing Security
1

Related MCP Servers

TermSSH MCP
Shell Access Command Line
rayss868
A
license
Not graded
quality
C
maintenance
Terminal-first SSH access for MCP clients and AI agents, enabling interactive remote sessions, file uploads, and stateful workflows.
Updated 9 days ago (2026-08-26 01:01 UTC)
11
1
MIT
ssh-mcp
Shell Access Command Line
SC-ML-cmd
F
license
Not graded
quality
C
maintenance
Enables SSH interactive session management through MCP, supporting commands, menus, and session lifecycle operations.
Updated 3 months ago (2026-06-14 14:42 UTC)
1
Device MCP Server
Networking & Infrastructure Shell Access
rajib884
A
license
A
quality
B
maintenance
A comprehensive MCP server for network device management via SSH/Telnet. Supports multiple vendors such as Cisco IOS and BDCOM, enabling AI assistants to execute commands and manage routers, switches, and firewalls.
Updated a month ago (2026-07-28 08:11 UTC)
4
MIT
mikrotik-mcp
Networking & Infrastructure Security
mikrotik-mcp
A
license
Not graded
quality
A
maintenance
Turns a MikroTik router into 310 MCP tools for AI-driven configuration over SSH, covering firewall, routing, VPN, and more.
Updated 15 days ago (2026-08-19 10:45 UTC)
316
11
MIT

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/thelad-dev/draytek-vigor-mcp'

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

DrayTek Vigor 167 MCP Server

Status

Voraussetzungen

Schnellstart

Credentials (.env)

SSH- und CLI-Ablauf (Vigor 167)

Cursor einbinden

MCP-Tools

Beispiel get_dsl_info (FW 5.2.8, verifiziert)

Verifizierter Befehlsbaum (Kurzüberblick)

Top-Level (?)

Exec (exec ?)

Config (help, Auszug)

Discovery manuell

Projektstruktur

Hinweise und Grenzen

Fehlerbehebung

Lizenz / Gerät

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Credentials (`.env`)

Beispiel `get_dsl_info` (FW 5.2.8, verifiziert)

Top-Level (`?`)

Exec (`exec ?`)

Config (`help`, Auszug)