zte-f680-mcp

by Picaresco

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.3.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.
Average 4.3/5 across 13 of 13 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![MCP-ZTE-F680 MCP server](https://glama.ai/mcp/servers/Picaresco/MCP-ZTE-F680/badges/card.svg)](https://glama.ai/mcp/servers/Picaresco/MCP-ZTE-F680)

Score Badge

Copy to your README.md:

[![MCP-ZTE-F680 MCP server](https://glama.ai/mcp/servers/Picaresco/MCP-ZTE-F680/badges/score.svg)](https://glama.ai/mcp/servers/Picaresco/MCP-ZTE-F680)

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