How do I use zte-f680-mcp?

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., "@zte-f680-mcp open port 8080" 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.

zte-f680-mcp

by Picaresco

Overview Schema Related Servers Score Discussions

Python

Local

zte-f680-mcp

MCP Server (Model Context Protocol) to manage and inspect a ZTE ZXHN F680 GPON router from any MCP-compatible client (Claude Desktop, Claude Code, Cursor, Windsurf, OpenAI Agents SDK, Cline, Continue, etc.).

Control NAT / port forwarding and read WiFi, DHCP, DMZ, WAN and device status from your router conversationally, without opening the web UI.

Features

NAT / port forwarding

Tool	Description
`zte_get_port_forwards`	List all NAT rules
`zte_open_port`	Quick-open a port with smart defaults (auto-detect local IP, same port both sides)
`zte_get_local_ip`	Return the host IP in the router's subnet (cross-platform)
`zte_add_port_forward`	Add a rule with full control (ranges, custom internal IP/port)
`zte_modify_port_forward`	Modify an existing rule by index
`zte_delete_port_forward`	Delete a rule by index

Read-only status (v0.3.0+)

Tool	Description
`zte_get_device_info`	Model, serial, firmware, hardware, bootloader, WiFi chipsets
`zte_get_wan_status`	Public IP, gateway, DNS, WAN MAC, connection type, uptime
`zte_get_wifi_info`	Both bands (SSID, channel, real PSK key, BSSID, traffic stats)
`zte_get_dhcp_leases`	Connected devices (IP, MAC, hostname, connection type, lease expiry)
`zte_get_dmz`	DMZ state + configured internal host
`zte_get_wifi_clients`	Associated WiFi clients with RSSI signal strength

Generic

Tool	Description
`zte_run_page`	Fetch and parse any page from the router

Quick-open flow

Ask your assistant plainly and it will confirm before touching the router:

You: open port 8080 Assistant: Your local IP is 192.168.1.128. Should I forward 8080 → 192.168.1.128:8080? You: yes Assistant: ✓ Rule added.

Under the hood the assistant calls zte_get_local_ip (to pick the correct interface even on multi-homed hosts) and then zte_open_port(port=8080). If you want a different internal port or IP, just say so and the assistant switches to zte_add_port_forward with your values.

What's new in v0.3.0

v0.3.0 adds six read-only tools that translate the router's cryptic internal fields into human-friendly tables. For example:

WiFi 2.4 GHz
  SSID:        HomeNetwork          Canal:     1 (manual)
  Estado:      ON                   Estandar:  g,n     Ancho: 20MHz
  Seguridad:   WPA/WPA2 AES         Clave:     YourRealPassword
  BSSID:       24:d3:f2:c6:97:b6    Oculta:    NO
  TxPower:     100%                 Max clientes: 16
  Trafico:     TX 1.29 GB / RX 97.9 MB       Asociaciones: 1

Under the hood, the codebase was split into focused modules (http_client, parsers, pages, formatters, server) and a new parser handles the router's third HTML layout (plain <td class="tdright"> tables used for WAN status). The project now ships with 32 unit tests running against real HTML fixtures captured from the router — no hardware needed to develop.

Related MCP server: mcp-fritzbox

Requirements

Python 3.10+
A ZTE ZXHN F680 router reachable on the local network
The admin credentials of the router's web panel

Install & configure

The easiest way is with uv (or pipx). No cloning, no venv.

Claude Desktop

Edit claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "zte": {
      "command": "uvx",
      "args": ["zte-f680-mcp@latest"],
      "env": {
        "ZTE_HOST": "192.168.1.1",
        "ZTE_USER": "1234",
        "ZTE_PASSWORD": "your_password_here"
      }
    }
  }
}

Tip: @latest makes uvx check PyPI on every launch and use the newest version, so users get updates automatically. Remove @latest (just "zte-f680-mcp") to pin to whatever was installed first.

Claude Code (CLI)

claude mcp add zte \
  --env ZTE_HOST=192.168.1.1 \
  --env ZTE_USER=1234 \
  --env ZTE_PASSWORD=your_password_here \
  -- uvx zte-f680-mcp@latest

Cursor / Windsurf / Cline / Continue

Add the same block as Claude Desktop in the corresponding MCP settings file of each client.

OpenAI Agents SDK (Python)

from agents.mcp import MCPServerStdio

zte = MCPServerStdio(
    params={
        "command": "uvx",
        "args": ["zte-f680-mcp@latest"],
        "env": {
            "ZTE_HOST": "192.168.1.1",
            "ZTE_USER": "1234",
            "ZTE_PASSWORD": "your_password_here",
        },
    }
)

Upgrading existing installs

If you registered the server before and want to jump to the newest release:

# Option 1: force-refresh the cache
uvx --refresh zte-f680-mcp

# Option 2: wipe the cache for this package only
uv cache clean zte-f680-mcp

After this, the next time your MCP client launches the server, uvx will fetch the latest version.

Alternative: classic pip install

pip install --upgrade zte-f680-mcp

Then point your MCP client at the installed script:

{
  "mcpServers": {
    "zte": {
      "command": "zte-f680-mcp",
      "env": {
        "ZTE_HOST": "192.168.1.1",
        "ZTE_USER": "1234",
        "ZTE_PASSWORD": "your_password_here"
      }
    }
  }
}

Configuration

The server reads three environment variables (or a local .env file):

Variable	Default	Description
`ZTE_HOST`	`192.168.1.1`	Router IP
`ZTE_USER`	`1234`	Admin username
`ZTE_PASSWORD`	(none)	Admin password (required)

Example prompts

Once the MCP is registered you can ask your assistant things like:

List the NAT rules on my ZTE router
Open TCP port 8080 forwarded to 192.168.1.100
Delete port forwarding rule number 2

Show the WiFi status (both bands)
Which devices are connected to the router?
What's my public IP and how long has the WAN been up?
Show me the WiFi clients with their signal strength
Is the DMZ enabled?
What firmware version is running?

How it works

Auth: SHA256(password + random) with dynamic tokens (Frm_Logintoken, Frm_Loginchecktoken) extracted from the login page.
Session: Expires ~60 s idle. The server re-authenticates automatically every 45 s.
Anti-CSRF: Each write operation requires a fresh _SESSION_TOKEN fetched from the page.
HTML parsing: Three formats coexist on the router — Transfer_meaning('field','value') JS calls (most config pages), <td id="Frm_*"> tables with HTML entity values (device info), and plain <td class="tdright"> tables (WAN status). Each has its own dedicated parser.
Protocol codes: 0 = TCP+UDP, 1 = UDP, 2 = TCP.
Transport: MCP over stdio.

Stack

FastMCP (mcp[cli])
httpx (async HTTP client)
python-dotenv
pydantic

Development

git clone https://github.com/Picaresco/MCP-ZTE-F680.git
cd MCP-ZTE-F680
python -m venv venv && . venv/Scripts/activate   # Windows
# source venv/bin/activate                         # Linux / macOS
pip install -e ".[test]"
cp .env.example .env   # fill in your credentials
python -m zte_f680_mcp.server

Run the test suite (no router required — tests use captured HTML fixtures):

pytest tests/ -v

To regenerate fixtures from your own router (if firmware differs):

python scripts/capture_fixtures.py

License

MIT © Alberto Diaz

Available Tools

13 tools

zte_add_port_forwardA

Anade una regla de port forwarding con control total.

Para el caso comun (un solo puerto -> IP local en el mismo puerto), considera usar zte_open_port, que tiene defaults inteligentes.

Args: name: Nombre descriptivo de la regla (max 32 chars). protocol: "TCP", "UDP" o "TCP+UDP". external_port_start: Puerto externo inicial. external_port_end: Puerto externo final (igual que start para 1 puerto). internal_host: IP interna destino (ej: 192.168.1.100). internal_port_start: Puerto interno inicial. internal_port_end: Puerto interno final.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`protocol`	Yes
`external_port_start`	Yes
`external_port_end`	Yes
`internal_host`	Yes
`internal_port_start`	Yes
`internal_port_end`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior3/5

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

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description does not elaborate on behavioral traits beyond 'control total'. It does not contradict annotations but adds minimal 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?

The description is brief and front-loaded with purpose and guidance, followed by a concise parameter list. Every sentence serves a purpose.

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 complexity (7 required parameters and no schema descriptions), the description fully explains all parameters, provides usage guidance, and references an alternative tool. The presence of an output schema reduces the need to explain return values.

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?

Schema coverage is 0%, so description compensates by explaining each parameter. For example, 'external_port_end: Puerto externo final (igual que start para 1 puerto)' adds meaning beyond the schema's titles and types.

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 adds a port forwarding rule with full control, using specific verbs and resource. It distinguishes itself from the sibling tool 'zte_open_port' by noting that 'zte_open_port' is for common cases with smart defaults.

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 provides guidance: 'Para el caso comun (un solo puerto -> IP local en el mismo puerto), considera usar zte_open_port, que tiene defaults inteligentes.' This tells the agent when to use this tool vs an alternative.

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

zte_delete_port_forwardA

Destructive

Borra una regla de port forwarding por su indice.

Args: index: Indice de la regla (obtenido con zte_get_port_forwards).

ParametersJSON Schema

Name	Required	Description	Default
`index`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

Annotations already indicate destructiveHint: true and readOnlyHint: false, which inform the agent that this is a destructive operation. The description adds no further behavioral context beyond what annotations provide, such as whether the deletion is irreversible or has 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.

Conciseness4/5

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

The description is concise, with a single-line summary followed by an Args section. It front-loads the main action. Minor improvements could remove the blank line or simplify the docstring format, but overall it is efficiently structured.

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 it is a simple delete operation with one parameter, the description provides necessary context (source of index) and the tool has both an output schema and annotations covering destructiveness. It does not explain return values, but repetition is mitigated by the output schema. Overall, it is sufficiently complete for its complexity.

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 one parameter 'index' with type integer but no description (0% schema coverage). The description adds essential context: 'Indice de la regla (obtenido con zte_get_port_forwards)', explaining how to obtain the index. This compensates well for the lack of schema 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?

The description clearly states 'Borra una regla de port forwarding por su indice' (Delete a port forwarding rule by its index). It specifies the verb (delete), resource (port forwarding rule), and method (by index). This distinguishes it from siblings like zte_add_port_forward and zte_modify_port_forward.

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 advises that the index is obtained via zte_get_port_forwards, implying the tool should be used after listing rules. However, it does not explicitly state when to prefer this tool over alternatives (e.g., modify vs delete) or provide any when-not-to-use guidance.

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

zte_get_device_infoA

Read-only

Devuelve modelo, serie, firmware, hardware, bootloader y chipsets WiFi.

Lee status_dev_info_t.gch. Esta pagina no incluye uptime, CPU ni RAM en el firmware Jazztel; esos datos viven en otras paginas.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Las anotaciones ya indican que es de solo lectura y no destructiva. La descripción añade que lee una página específica y señala limitaciones en el firmware Jazztel, proporcionando contexto adicional útil para el agente.

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?

Dos oraciones sencillas y directas, con la información principal al inicio. Sin relleno ni repetición de lo que ya está en la entrada.

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?

Para una herramienta sin parámetros y con esquema de salida, la descripción es completa: indica los datos devueltos, lo que no incluye y dónde encontrar esa información faltante. No se necesita más.

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 hay parámetros, por lo que la línea base es 4. La descripción no necesita añadir semántica de parámetros, y cumple al no haber ambigüedad.

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?

La descripción enumera claramente los datos que devuelve (modelo, serie, firmware, hardware, bootloader, chipsets WiFi) y menciona la página que lee. Se distingue de los hermanos porque estos se enfocan en otras funcionalidades como puertos o DHCP.

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?

La descripción indica qué datos no incluye (uptime, CPU, RAM) y que esos se encuentran en otras páginas, dando una guía implícita para cuándo usar esta herramienta. No menciona explícitamente herramientas alternativas por nombre, pero la información es útil.

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

zte_get_dhcp_leasesA

Read-only

Lista los dispositivos conectados al router: IP, MAC, hostname, tipo de conexion (LAN/WiFi) y tiempo de expiracion del lease DHCP.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true. The description adds value by listing the returned fields (IP, MAC, hostname, etc.), which is useful beyond the annotations. No mention of other behavioral traits like pagination or rate limits, but the tool is simple with no parameters.

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?

A single sentence that is clear, concise, and front-loaded with the action ('Lista') and the object ('dispositivos conectados al router'). Every word is earned.

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 has no parameters, an output schema exists (though not shown), and annotations provide safety signals, the description is complete. It identifies what the tool returns and is sufficient for an agent to select and invoke 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?

The tool has no parameters, so the description cannot add parameter semantics. The baseline is 4 as per guidelines.

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 lists connected devices with specific fields (IP, MAC, hostname, connection type, lease expiration). It distinguishes from siblings like 'zte_get_wifi_clients' which likely focuses on WiFi only.

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?

While the purpose is clear, there is no explicit guidance on when to use this tool versus alternatives (e.g., 'zte_get_wifi_clients') or when not to use it. Usage context is implied but not stated.

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

zte_get_dmzA

Read-only

Devuelve el estado de la zona desmilitarizada (DMZ) y el host interno configurado como destino.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by specifying exactly what is returned (status and host). 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?

Single clear sentence with no waste. Front-loaded with purpose.

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 an output schema present, the description need not detail return values. It sufficiently explains the tool's output (status and host). Simple getter with no parameters is fully covered.

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%. Baseline of 4 is appropriate; description does not need to add parameter info.

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 DMZ status and the configured internal host, using a specific verb ('Devuelve') and resource. It is distinct from sibling tools like port forwarding or device info.

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 alternatives, such as when to check DMZ vs WAN status. The description only states what it does, not usage context.

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

zte_get_local_ipA

Read-only

Detecta la IP local del host en la subred del router.

En hosts multi-homed devuelve la IP del interfaz que enrutaria hacia ZTE_HOST, que es la que hay que usar como destino en port forwarding. Funciona en Linux, Windows y macOS sin dependencias externas.

Usa este tool ANTES de abrir un puerto para sugerir al usuario la IP por defecto. Ejemplo de flujo:

Usuario: "abre el puerto 8080"
zte_get_local_ip() -> "192.168.1.133"
Preguntar: "Redirijo 8080 -> 192.168.1.133:8080?"
Si confirma: zte_open_port(port=8080)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Las anotaciones ya indican readOnlyHint=true y destructiveHint=false. La descripción añade detalles sobre compatibilidad multiplataforma (Linux, Windows, macOS) y el comportamiento en hosts multi-homed, proporcionando información valiosa más allá de las anotaciones.

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?

La descripción es concisa, bien estructurada y sin información redundante. Cada oración aporta valor: propósito, comportamiento especial, compatibilidad y un ejemplo de uso. Es eficiente y fácil de procesar.

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?

Dada la simplicidad de la herramienta (sin parámetros), la descripción es completa. Cubre el propósito, el comportamiento, las plataformas compatibles y un caso de uso típico. La existencia de un esquema de salida (no mostrado) no requiere más detalles.

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 hay parámetros, por lo que la línea base es 4. La descripción añade significado explicando que devuelve la IP del interfaz que enrutaría hacia ZTE_HOST, lo cual es útil para entender el resultado.

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?

La descripción indica claramente que la herramienta detecta la IP local del host en la subred del router, especificando el comportamiento en hosts multi-homed. El propósito es único entre los siblings (ningún otro obtiene la IP local), lo que facilita la selección correcta.

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?

Proporciona una guía explícita de uso: 'Usa este tool ANTES de abrir un puerto para sugerir al usuario la IP por defecto', junto con un flujo de ejemplo. No menciona cuándo no usarlo ni alternativas, pero el contexto es suficiente para la tarea.

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

zte_get_port_forwardsA

Read-only

Lista todas las reglas NAT/port forwarding configuradas.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool is known to be safe and read-only. The description adds no further behavioral traits beyond confirming it lists rules, which aligns with annotations. 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?

The description is a single, concise sentence that front-loads the tool's purpose without any wasted words. It is appropriately sized for the tool's simplicity.

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 no parameters and the presence of an output schema, the description is reasonably complete for a straightforward list tool. It could mention that it returns all rules, but the output schema covers return values.

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 has zero parameters, and schema description coverage is 100%. The description does not add parameter-specific information, which is unnecessary here. 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?

The description clearly states 'Lista todas las reglas NAT/port forwarding configuradas' (Lists all configured NAT/port forwarding rules), providing a specific verb and resource. It effectively distinguishes from sibling tools like add, delete, and modify.

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 does not provide explicit guidance on when to use this tool versus alternatives. While the purpose is implied by its name and siblings, no when/when-not or alternative mentions are present.

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

zte_get_wan_statusA

Read-only

Devuelve IP publica, gateway, DNS, MAC WAN, tipo de conexion y uptime del enlace WAN del router.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by listing the specific fields returned, but does not disclose additional behavioral traits such as response format or any side effects. Since annotations cover safety, a score of 3 is appropriate.

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, well-structured sentence that front-loads the key information. No wasted words; every element is necessary to convey the tool's purpose.

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 has no parameters and an output schema exists, the description fully explains what data is returned. It covers all relevant aspects for a simple read operation, making it complete for an AI agent to understand.

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 tool has no parameters, and schema coverage is trivially 100%. The description does not need to add parameter-level meaning, and it clearly explains the output. With no parameters, the description is sufficient.

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 explicitly states the tool returns public IP, gateway, DNS, WAN MAC, connection type, and uptime of the router's WAN link. It specifies the verb 'devuelve' (returns) and the resource 'enlace WAN del router', clearly distinguishing it from sibling tools that handle port forwarding, device info, etc.

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 for retrieving WAN status, but provides no explicit guidance on when to use this tool versus alternatives like zte_get_device_info or other status tools. No when-not-to-use or prerequisite information is given.

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

zte_get_wifi_clientsA

Read-only

Lista los dispositivos conectados por WiFi con su RSSI (senal), banda, modo (11ac/11n) y tasa TX/RX.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the returned attributes (RSSI, band, mode, TX/RX), which gives the agent a clear behavioral expectation beyond the safety profile. 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 a single sentence that front-loads the action and resource, then lists the key data fields. Every word contributes meaning, making it highly concise with no 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?

For a parameterless read-only tool with an output schema, the description adequately explains what the tool does and what data it returns. No additional context is necessary 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?

There are zero parameters, and schema coverage is 100% (empty schema). Per the rules, a baseline of 4 is appropriate since no parameter information is needed beyond what is provided.

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 specifies the action 'Lista' (lists) and the resource 'dispositivos conectados por WiFi' (WiFi connected devices), and enumerates the exact data fields (RSSI, band, mode, TX/RX). This clearly distinguishes it from the sibling tool 'zte_get_wifi_info', which likely retrieves WiFi settings rather than client lists.

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 when needing a list of connected WiFi clients with signal details, but does not explicitly state when to use this tool versus alternatives (e.g., zte_get_dhcp_leases for all devices). There is no guidance on when not to use it.

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

zte_get_wifi_infoA

Read-only

Devuelve SSIDs, canal, estandar, seguridad, clave PSK, BSSID y estadisticas de ambas bandas WiFi (2.4 y 5 GHz).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, establishing safety. The description adds behavioral context by enumerating the specific WiFi data fields returned, such as PSK key and statistics, which is not present in the structured 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 a single sentence in Spanish, efficiently conveying the tool's purpose without extraneous information. It is front-loaded with the key action and resource.

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 tool with no parameters, the description is complete. It lists the data returned, and the presence of an output schema means the description does not need to detail return values. No gaps are evident.

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 tool has no parameters (0 params, schema coverage 100%). The description does not need to add parameter information; baseline score 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 that the tool returns WiFi information including SSIDs, channel, standard, security, PSK key, BSSID, and statistics for both 2.4 and 5 GHz bands. It uses a specific verb ('Devuelve') and distinguishes itself from sibling tools like zte_get_wifi_clients or zte_get_device_info.

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. There is no mention of context, exclusions, or conditions for invocation, leaving the agent to infer usage implicitly.

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

zte_modify_port_forwardA

Modifica una regla de port forwarding existente.

Args: index: Indice de la regla (obtenido con zte_get_port_forwards). name: Nuevo nombre de la regla. protocol: "TCP", "UDP" o "TCP+UDP". external_port_start: Puerto externo inicial. external_port_end: Puerto externo final. internal_host: IP interna destino. internal_port_start: Puerto interno inicial. internal_port_end: Puerto interno final.

ParametersJSON Schema

Name	Required	Description	Default
`index`	Yes
`name`	Yes
`protocol`	Yes
`external_port_start`	Yes
`external_port_end`	Yes
`internal_host`	Yes
`internal_port_start`	Yes
`internal_port_end`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior2/5

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

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description does not elaborate on behavioral traits beyond stating that it modifies a rule. No mention of side effects, authentication needs, or what happens on failure. The description adds minimal value over 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, uses a clear structure with a purpose statement followed by a parameter list. Every sentence provides value, no unnecessary content.

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 high parameter count, the description sufficiently explains each parameter and the tool's purpose. An output schema exists, so return values are not required. Lacks details on constraints (e.g., index must exist) but overall complete for selection and invocation.

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?

Schema has 0% description coverage; the description provides clear definitions for all 8 parameters, including that 'index' is obtained from another tool and protocol values. This significantly aids proper invocation.

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 explicitly states 'Modifica una regla de port forwarding existente' (modifies an existing port forwarding rule), which is a specific verb+resource. It clearly distinguishes from siblings like 'add' and '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 purpose is clear from the tool name and description, implying usage for modifying existing rules rather than adding or deleting. However, there is no explicit when-to-use or when-not-to-use guidance, nor mention of prerequisites or constraints.

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

zte_open_portA

Abre un puerto con defaults sensatos. Flujo conversacional recomendado.

Args: port: Puerto externo a abrir. protocol: "TCP", "UDP" o "TCP+UDP" (default). internal_host: IP interna destino. Si None o "auto", se detecta automaticamente la IP local del host en la subred del router (llamando al helper equivalente a zte_get_local_ip). internal_port: Puerto interno. Si None, se usa el mismo que port. name: Nombre descriptivo. Si None, se genera como "port_".

Para rangos de puertos o control total, usa zte_add_port_forward.

Flujo recomendado: 1. Pide al usuario el puerto a abrir. 2. Llama a zte_get_local_ip y propon la IP detectada. 3. Confirma con el usuario antes de abrir (destino IP y puerto interno). 4. Llama a zte_open_port con los valores acordados.

ParametersJSON Schema

Name	Required	Default
`port`	Yes
`protocol`	No	TCP+UDP
`internal_host`	No
`internal_port`	No
`name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations show readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds context about automatic detection of internal host and defaulting of internal_port and name. It does not detail risks or reversibility, but the annotation coverage is adequate.

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 an intro, parameter list, alternative reference, and recommended workflow. It is somewhat lengthy but every sentence adds value; could be slightly more concise.

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?

The description covers parameter semantics, usage guidelines, and behavioral context. An output schema exists, so return values are not needed. It is complete for an agent to select and invoke the tool correctly.

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?

Schema description coverage is 0%, but the description thoroughly explains every parameter: port, protocol (with default), internal_host (auto-detect if None), internal_port (defaults to port), name (auto-generated). 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 opens a port with sensible defaults and contrasts with sibling tool 'zte_add_port_forward' for ranges or full control, making the purpose distinct and specific.

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?

The description provides explicit when-to-use guidance: for single ports with defaults. It directly recommends an alternative for ranges. It also outlines a multi-step conversational flow, including calling zte_get_local_ip and confirming with the user.

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

zte_run_pageA

Read-only

Obtiene y parsea cualquier pagina del router ZTE.

Args: page_name: Nombre de la pagina (ej: 'app_virtual_conf_t.gch'). raw: Si True, devuelve HTML crudo. Si False, parsea Transfer_meaning.

Paginas conocidas: - app_virtual_conf_t.gch (port forwarding) - app_dmz_conf_t.gch (DMZ) - app_upnp_conf_t.gch (UPnP) - net_dhcp_dynamic_t.gch (DHCP leases) - status_dev_info_t.gch (device info) - IPv46_status_wan_if_t.gch (WAN status) - net_wlanm_conf1_t.gch (WiFi 2.4GHz) - net_wlanm_conf2_t.gch (WiFi 5GHz) - sec_firewall_conf_t.gch (firewall)

ParametersJSON Schema

Name	Required	Description	Default
`page_name`	Yes
`raw`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations (readOnlyHint=true, destructiveHint=false) are consistent. The description adds value by explaining the raw parameter's effect and that it parses 'Transfer_meaning' when raw=False. No hidden behaviors are omitted.

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: first sentence states purpose, second explains parameters, followed by a clear list of known pages. Every sentence adds value with 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?

Given the presence of an output schema (not shown), the description does not need to detail return values. It adequately covers purpose, parameters, and known pages, leaving output details to the schema.

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?

The input schema has no descriptions (0% coverage). The description compensates fully by explaining page_name with examples, and raw with its boolean behavior, adding semantic 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 the tool's purpose: 'Obtiene y parsea cualquier pagina del router ZTE' (Gets and parses any page of the ZTE router). It distinguishes itself from sibling tools by being generic, while siblings handle specific features like port forwarding or DMZ.

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 a list of known pages, indicating suitable contexts. However, it does not explicitly state when to prefer this generic tool over specific siblings, which would improve guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

13 tool updatesv0.3.0May 29, 2026
- First observedzte_add_port_forward
- First observedzte_delete_port_forward
- First observedzte_get_device_info
- First observedzte_get_dhcp_leases
- First observedzte_get_dmz
- First observedzte_get_local_ip
- First observedzte_get_port_forwards
- First observedzte_get_wan_status
- First observedzte_get_wifi_clients
- First observedzte_get_wifi_info
- First observedzte_modify_port_forward
- First observedzte_open_port
- First observedzte_run_page

Install Server

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

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct router function (port forwarding CRUD, device info, DHCP, DMZ, WiFi, WAN), with clear descriptions. The overlap between zte_add_port_forward and zte_open_port is explicitly differentiated by purpose and defaults.

Naming Consistency5/5

All tools follow a consistent 'zte_verb_noun' pattern (e.g., zte_get_device_info, zte_add_port_forward), using imperative verbs and snake_case throughout.

Tool Count5/5

13 tools cover the essential router management operations without bloat. The count is well-scoped for a single-device admin server.

Completeness4/5

Core port forwarding operations (add, delete, modify) are covered, plus device info, DHCP, DMZ, WiFi, and WAN status. Missing some configuration like setting DMZ or WiFi settings, but a generic page runner (zte_run_page) allows extending functionality.

Maintenance

ActivityInactive

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

network
io.github.doc2mcp
MCP server for network documentation, generated by doc2mcp.
Networking & Infrastructure Documentation Access
12
thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
registry A
io.github.urnetwork
Cloud-hosted MCP server for URnetwork VPN and Proxy
Cloud Platforms Security App Automation
2
SRI — MCP Server Inspector A
biz.sri-test
2,000+ MCP servers read at source level. Know what one does before you connect. Free, no key.
Developer Tools
21

Related MCP Servers

MikroTik WiFi Users
Networking & Infrastructure Monitoring
piotron
A
license
Not graded
quality
D
maintenance
MCP server for querying connected WiFi devices from MikroTik RouterOS, enriched with DHCP leases and ARP table entries.
Updated 6 months ago (2026-03-14 21:59 UTC)
MIT
mcp-fritzbox
Home Automation & IoT Networking & Infrastructure
ghbalf
F
license
A
quality
C
maintenance
A Model Context Protocol (MCP) server for interfacing with AVM FRITZ!Box routers. Control smart home devices, monitor network status, and administer your router through any MCP-compatible client.
Updated 5 months ago (2026-04-08 23:25 UTC)
10
-
router-mcp
Networking & Infrastructure Home Automation & IoT
sudip490
A
license
A
quality
C
maintenance
MCP server for monitoring and controlling WiFi routers (OpenWrt) via SSH, enabling device listing, status checks, WiFi configuration, rebooting, and more.
Updated 2 months ago (2026-07-01 05:51 UTC)
7
25
MIT
mcp-mikrotik
Networking & Infrastructure Observability
thalisantunes
A
license
B
quality
B
maintenance
MCP server for managing MikroTik RouterOS devices, enabling reading device state and performing guarded write operations such as setting identity via natural language.
Updated 2 months ago (2026-07-13 18:15 UTC)
10
Apache 2.0

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/Picaresco/MCP-ZTE-F680'

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