OpenWrt Network Diagnostics MCP

by gomixo

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools target clearly distinct diagnostic aspects (snapshot, config, DNS, client, flow, capture, subscriptions, logs). The only potential overlap is between observe_client and inspect_flow, but their descriptions clarify different scopes (client-level vs. flow-level).
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., snapshot_network, inspect_config_state, capture_flow). Even with repeated verbs like 'inspect', the nouns clearly differentiate the tools.
Tool Count5/5
9 tools is well-scoped for a specialized network diagnostics server, covering both data collection and analysis without unnecessary bloat or missing core functionality.
Completeness4/5
The tool set covers major diagnostic workflows: snapshots, config comparison, DNS tracing, client observation, flow inspection, packet capture, subscription metadata, and logs. Minor gaps exist such as an explicit connectivity test or snapshot management, but core capabilities are solid.
Average 3.6/5 across 9 of 9 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

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 'non-persistent' and 'generated restricted filter,' which are behavioral details not captured by the annotations, giving the agent a clearer sense of what the tool does and its 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 a single, front-loaded sentence that states the core action and key constraints without wasted words. It is concise, though it sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters and no output schema, but the description fails to explain what the capture returns, what 'bounded' means, or how parameters map to the filter. This is inadequate for an agent to use the tool correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 8 parameters, the description provides no explanation of how parameters like client_ip, port, domain, or protocol shape the generated filter. This is a critical gap for a tool with so many parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a packet capture, which is a specific verb+resource, and the title adds 'bounded packet metadata.' However, it doesn't explicitly distinguish from sibling tools like observe_client or inspect_flow, though 'non-persistent' and 'generated restricted filter' hint at a unique approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The phrase 'explicitly requested' implies on-demand use, but there are no explicit scenarios, prerequisites, or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true and destructiveHint false, so the description's focus on 'evidence' aligns without adding much safety-relevant context. It does not disclose potential performance costs, required permissions, or interpretation details, which would exceed what annotations provide.
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 a single, well-structured sentence that front-loads the primary verb and resources. It is concise and free of filler, though the heavy jargon ('Mihomo', 'nftables', 'conntrack') may hinder quick comprehension for unfamiliar agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and complex multi-source correlation, the one-sentence description lacks essential context. It does not describe what the returned evidence looks like, how to interpret the correlation, or how to use parameters like 'detail' or 'protocol'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden for explaining parameters. It mentions 'client and destination' (client_ip, destination_ip) but fails to clarify port, detail, domain, protocol, or client_ipv6. This is insufficient given the 7-parameter schema with enums and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Correlate live Mihomo, routing, aggregated nftables, and conntrack evidence for a client and destination.' It uses a specific verb ('correlate') and resource list, and the focus on a client/destination differentiates it from sibling tools like inspect_config_state or trace_dns.
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 gives no explicit guidance on when to use this tool versus alternatives. It implies a targeted investigation of a flow, but there is no mention of exclusions or alternative tools like capture_flow or trace_dns, leaving the agent to infer the appropriate 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, so the read-only nature is covered. The description adds the 'bounded' aspect (likely referring to the duration limit) and specifies the observed data types, but it does not disclose additional behavioral traits such as output format, side effects, or timing behavior beyond what the schema implies.
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 starts with the action verb and packs the essential scope into minimal words. There is no fluff or repetition, making it easy for an agent to quickly parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should explain what the tool returns or how results are presented. It mentions 'connection/log activity and conntrack state' as the observed data, which gives an idea of the output domain, but it does not specify the format, structure, or whether results are aggregated or streamed. The 'bounded' hint suggests a time-limited observation, but this is not fully elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only vaguely references 'one client address' and 'bounded' activity, without explaining the distinct roles of client_ip vs client_ipv6 or clarifying how duration (default 60, min 5, max 60) influences the observation. This under-specification is a significant gap for a three-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Observe') and clearly identifies the resource ('Mihomo connection/log activity and conntrack state') scoped to one client address. It distinguishes from broader sibling tools like snapshot_network or inspect_flow by emphasizing the single-client focus, though 'bounded' is somewhat ambiguous without referencing the duration parameter.
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 phrase 'one client address' implies this tool is for observing a specific LAN client, providing a clear use case. However, it offers no explicit guidance on when to use it over alternatives (e.g., inspect_flow for general flow inspection) and no exclusions or conditions indicating 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?
Annotations already indicate a safe read-only operation, and the description adds valuable behavioral context: logs are filtered and redacted, and Mihomo logs are 'newly observed'—implying a checkpoint mechanism. This goes beyond the structured annotations and clarifies output expectations, though it still leaves the exact redaction and 'newly observed' semantics somewhat vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and scope. Every word contributes meaning, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and annotations cover safety, the description omits important behavioral details such as the meaning of 'bounded' (from the title), return format, and the semantics of 'newly observed'. With no output schema, this leaves moderate ambiguity. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no parameter-level explanations. It mentions 'filtered' which loosely aligns with `contains`, but does not clarify duration, max_records, or the source enum's differences. The agent must infer parameter behavior from names and constraints alone, which is insufficient.
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 a specific action (Read) with a defined scope (filtered and redacted logs from OpenWrt, Nikki, or Mihomo). It distinguishes itself from sibling tools, none of which are log-readers, and mentions filtering and redaction which add precision.
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. The description implies it is for reading router-side logs, but does not explicitly state scenarios, prerequisites, or exclusions. Sibling tools exist for network inspection but no comparison is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the computation is mechanical and restricted to the current MCP process, but it does not disclose behavior for invalid/missing snapshot IDs or return format expectations.
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, front-loaded sentence with no filler words. It immediately conveys the action and object, making it highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain the return structure, but it only says 'field changes' without specifying format or error handling. The tool is simple and annotations cover safety, but given the missing output schema, the description is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only says 'between snapshots,' leaving before_id and after_id semantics to be inferred from names. It does not clarify which parameter is the baseline or their temporal order, so the description fails to compensate for the lack of schema documentation.
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 states 'Return mechanically computed field changes between snapshots from the current MCP process' – a specific verb (return) and resource (field changes between snapshots). It distinguishes itself from sibling tools like snapshot_network (which creates snapshots) and read_logs.
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 clearly indicates that the tool operates on in-memory snapshots from the current MCP process, implying a prerequisite that snapshots must have been captured. However, it does not explicitly name alternatives or state when not to use this tool, so there are no exclusions.
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, so the safety profile is known. The description adds the specific comparison scope but does not disclose return format, pagination, or any potential side effects—though for a read-only compare, this is acceptable. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the core action. Every word contributes meaning, with no fluff or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and strong read-only annotations, the description is mostly complete. It clearly states what is compared, but the term 'whitelisted' and the nature of 'provider summaries' remain undefined, and there is no output schema to clarify the result format. Still, it covers essential points.
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 zero parameters, and schema coverage is 100% (vacuously). Per the baseline rule for 0 params, a score of 4 is appropriate. The description doesn't need to explain parameters but does add context about what is being compared, slightly enhancing understanding.
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 compares whitelisted Nikki-generated startup fields with Mihomo runtime General state and provider summaries. It uses a specific verb ('Compare') and identifies the exact resources, distinguishing it from sibling tools like inspect_flow or snapshot_network.
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, notably 'compare_snapshots', which also involves comparison. There are no explicit exclusions or context cues to help the agent choose between these related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the annotations: it reveals that the snapshot is 'bounded' (resource-limited) and that it is 'retained in memory' (a stateful side effect), which the read-only and non-destructive annotations do not convey. It does not contradict the 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, well-structured sentence that front-loads the core action and purpose, with no unnecessary words or repetition of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose and memory retention behavior, but it omits parameter semantics and does not explain how the retained snapshot is retrieved or used by sibling tools like compare_snapshots. Given the simplicity of the tool and the presence of annotations, the description is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'detail', is documented in the schema with an enum (summary/full) and a default, but the description does not explain what the difference between these values is or how they affect the snapshot. With schema coverage at 0%, the description's silence on the parameter leaves its meaning ambiguous.
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 function with a specific verb ('Collect') and resource ('bounded router-side network snapshot'), and explicitly mentions its purpose ('retain it in memory for later comparison'), distinguishing it from siblings like compare_snapshots (which performs the comparison) and capture_flow (which captures traffic).
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 before comparison by stating 'retain it in memory for later comparison', but it does not explicitly state when to use this tool versus alternatives such as capture_flow or inspect_config_state, nor does it provide exclusion criteria or prerequisites.
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 behavioral context by listing the compared elements (observations, generated settings, Fake-IP addresses, listeners), which clarifies what the tool actually inspects. 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 sentence, front-loaded with the verb and object, with no wasted words. It communicates scope effectively in under 20 words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only compare tool with 3 parameters and no output schema, the description gives a high-level overview but lacks details on return value format, how to interpret comparisons, or parameter effects. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention domain, qtype, or server parameters. It gives an indirect hint that a domain is needed (DNS observations), but qtype and server semantics remain undocumented. The description fails to compensate for the missing 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 uses the specific verb 'Compare' and identifies the exact resources: OpenWrt and Mihomo DNS observations, generated DNS settings, Fake-IP addresses, and listeners. This clearly distinguishes it from sibling tools like snapshot_network or read_logs.
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 a diagnostic comparison use case but does not explicitly state when to prefer this tool over alternatives or mention exclusions. It provides clear context (router-side DNS evidence) but lacks direct guidance on selection.
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, and the description adds significant context: it returns 'safe' metadata and explicitly excludes 'URLs or credentials'. This goes beyond the annotations by clarifying what content the tool will and will not expose, which is valuable for an agent. No additional behavioral traits (e.g., error behavior) are disclosed, but the annotation coverage lowers the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose, scope, and safety guarantee. There is no redundant or filler content; every word contributes to understanding.
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, no output schema, and strong annotations, the description provides enough information for an agent to select and invoke it correctly. It explains what the tool returns and what it deliberately excludes, making it complete for this low-complexity tool.
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 zero parameters, so the description carries no burden for explaining parameter meaning. The baseline for 0 params is 4, and the description does not add or need to add parameter-related details.
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 states a specific verb ('Return') and resource ('Nikki cache metadata and Mihomo provider summaries'), and explicitly notes what is excluded ('without URLs or credentials'). This clearly distinguishes it from sibling inspection tools like inspect_config_state and inspect_flow, which focus on other aspects of state.
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 that this tool is for reviewing subscription-related metadata and provider summaries, but it provides no explicit guidance on when to use it versus sibling tools. There are no stated prerequisites, exclusions, or alternative tool recommendations, so it falls into 'implied usage' rather than clear context or exclusions.
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

openwrt-network-diagnostics-mcp MCP server

Copy to your README.md:

[![openwrt-network-diagnostics-mcp MCP server](https://glama.ai/mcp/servers/gomixo/openwrt-network-diagnostics-mcp/badges/card.svg)](https://glama.ai/mcp/servers/gomixo/openwrt-network-diagnostics-mcp)

Score Badge

Copy to your README.md:

[![openwrt-network-diagnostics-mcp MCP server](https://glama.ai/mcp/servers/gomixo/openwrt-network-diagnostics-mcp/badges/score.svg)](https://glama.ai/mcp/servers/gomixo/openwrt-network-diagnostics-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gomixo/openwrt-network-diagnostics-mcp'

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