openwrt-luci-mcp

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation4/5
Most tools target distinct network/system domains (routes, neighbors, firewall, WiFi, DHCP, packages), and descriptions are precise. The only mild confusions are `router_wifi_details` vs `router_wifi_clients` and `router_network_diagnostics` vs `router_run_diagnostic`, but the descriptions make the differences clear.
Naming Consistency5/5
All tools share a consistent `router_` prefix and use snake_case noun phrases organized by domain. The convention is uniform; `router_run_diagnostic` introduces a verb but still follows the same overall pattern.
Tool Count2/5
With 30 tools, the set exceeds the practical limit for easy agent selection and includes many low-level status endpoints that could be consolidated into grouped retrieval tools. Although the domain is broad, 30 tools is too many for a cohesive MCP surface.
Completeness5/5
The tool surface covers all major read-only OpenWrt/LuCI domains: interfaces, routes, WiFi, firewall, logs, system stats, packages, clients, diagnostics, and security. No obvious dead ends or missing core read-only operations exist for a status/diagnostics MCP server.
Average 4/5 across 30 of 30 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds minor context by framing the data as 'samples' from LuCI, but it does not disclose output format, device behavior, or any other behavioral traits beyond 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 concise sentence that front-loads the tool's purpose and lists all major modes. There is no filler, repetition, or unnecessary detail.
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?
Given the low schema coverage, no output schema, and the large set of sibling tools, the description leaves important gaps: it does not explain the 'device' parameter, describe return values, or clarify how this relates to similar status/detail tools. An agent could call it correctly for 'mode' but is left guessing about the optional parameter and expected result.
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 partially covers the 'mode' parameter by listing the four sample categories, though it uses 'bandwidth' where the schema says 'interface'. It says nothing about the optional 'device' parameter, so a non-trivial part of the invocation is left unexplained.
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 clear verb ('Get') and specific resource ('LuCI bandwidth, wireless, conntrack, or load samples'), and enumerates the main modes. It does not explicitly differentiate from sibling tools like router_wifi_overview or router_interface_details, so it stops short of a 5.
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?
There is no guidance about when to use this tool versus the many sibling tools that also report router status, interface details, or wireless information. The description merely states what it returns, not why an agent should choose it over alternatives.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that the tool returns status and counters for one device, slightly expanding the contract, but it does not mention counter semantics (e.g., cumulative, per-boot), error behavior for unknown device names, or whether status includes link state.
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 conveys the operation, scope, and examples without wasted words. Everything in the description earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one fully documented parameter and safety annotations, the description is nearly complete. The only notable omission is a more concrete statement of what 'status and counters' includes, but an agent can correctly invoke this tool based on the provided text.
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?
Schema description coverage is 100%, and the schema already explains the name parameter with the same examples (eth0, br-lan). The tool description repeats these examples but adds no semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('status and counters for one network device'), with concrete examples (eth0, br-lan). It distinguishes this from list-style siblings by emphasizing 'one,' but it does not explicitly differentiate from similarly scoped tools like router_interface_details.
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 given about when to choose this over siblings, such as router_interfaces for a list, router_realtime_stats for live metrics, or router_interface_details for fuller interface details. There are no prerequisites, exclusions, or alternative routing statements.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the LuCI host-hints source and the nature of the data, but does not disclose potential staleness, cache behavior, or whether it reflects live network state. 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?
A single, front-loaded sentence with no filler. It names the verb, resource, and data content compactly, making it easy for an agent to parse quickly.
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 zero-parameter read-only tool this is workable, but there is no output schema and the description does not state the return shape (e.g., list of objects with hostname/ip/mac fields). It also omits caveats about data freshness or the distinction between host hints and active DHCP leases, which would matter for correct selection and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description carries no parameter burden. Baseline for zero parameters is 4, and the description adds useful meaning about what the returned data represents, which is more than the empty schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get') and resource ('LuCI host hints') and specifies the data dimensions (hostnames, IP addresses, MAC addresses). It is not a tautology and gives a concrete idea of what the tool returns, though it does not explicitly differentiate itself from sibling tools like router_dhcp_leases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: an agent can infer this tool is appropriate when it needs LuCI's host hint correlations. However, the description provides no explicit when-to-use guidance, exclusions, or mention of alternatives such as router_neighbors or router_dhcp_leases.
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 read-only, idempotent, non-destructive behavior, so the description only needs to add context beyond that. It adds 'bounded result' and the installed/world scope, but does not explain query matching behavior, ordering, or pagination. 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 front-loaded sentence with no filler. Every word contributes to scope ('installed/world') or outcome ('bounded result').
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 simple read-only search with two optional parameters and no output schema, the description gives the core purpose but leaves query behavior and result shape unspecified. It is minimally viable but has clear gaps an agent would need to make confident calls.
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 for documenting query and limit. 'Search' and 'bounded result' only hint at the parameters without explaining query matching semantics or how the bound is applied. This is insufficient for a tool with undocumented parameters.
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 a specific verb 'Search' and identifies the resource as the 'installed/world package list', which distinguishes this tool from the sibling router_package_catalog (available packages). It clearly states the operation and scope.
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 'installed/world package list' implies this tool is for installed packages rather than the catalog, but the description never explicitly says when to use it versus alternatives or lists exclusions. Usage guidance is largely inferred from the resource wording.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the 'bounded' behavior, which is useful, but it does not disclose output shape, pagination behavior, or any operational nuances beyond the schema's limit parameter. 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?
A single, compact sentence that front-loads the core action and scope. Every word earns its place, with no filler or 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?
For a simple read-only snapshot tool with one well-constrained parameter and safe annotations, the description is largely sufficient. It could be more complete by hinting at the returned process fields (e.g., PID, command), but the scope and bounded nature are clear enough for invocation.
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 single parameter 'limit' is not described in the description, but the JSON schema provides clear type, default, minimum, and maximum constraints. The word 'bounded' weakly reinforces the limit parameter's purpose, but the description does not meaningfully compensate for the 0% schema description coverage.
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 'Get a bounded snapshot of running processes' uses a specific verb and resource, clearly identifying the tool as a process-list reader. It also distinguishes itself from siblings like router_services and router_system_info by focusing on running processes and a bounded snapshot.
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. It does not mention that this is for current running-process state, nor does it contrast with related tools such as router_services or router_system_info. The usage context is only implied by the tool name and description.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds the useful scoping detail that the operation targets one wireless interface, but it does not disclose edge-case behavior such as empty client lists or invalid interface names.
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 states the operation, the target resource, and a concrete example. Every word earns its place, and the key scoping information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description gives enough context for an agent to call it correctly: what it lists and on which interface. It could mention result format or error behavior, but given the tool's simplicity and strong annotations, the current description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the 'device' parameter is already described as 'Wireless interface name, for example phy1-ap0'. The tool description repeats the same example and adds no new semantic information beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List clients') and the specific resource scope ('one wireless interface'), with a concrete interface example. It is unambiguous and meaningful, though it does not explicitly compare itself to sibling tools like router_wifi_overview or router_client_summary.
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: call this tool when you need clients for a particular wireless interface. However, it does not state when not to use it or mention any alternative tool, leaving some routing decisions to the agent's inference.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful context by identifying the underlying source (LuCI status view) and the broad output categories, but it does not discuss response formatting, device filtering behavior, or any operational constraints beyond 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 one focused sentence with no filler. The main action and resource are front-loaded, and the content details are presented compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional, fully documented parameter and rich annotations, the description adequately conveys what will be returned: radio details, frequencies, and associated clients. It does not specify the exact response structure, but this is acceptable given the low complexity and the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the single optional parameter with a description and example ('Optional wireless interface, for example phy1-ap0'), so schema coverage is 100%. The tool description does not add additional parameter meaning, but the schema is sufficient on its own.
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 a specific verb ('Get') and a specific resource ('LuCI wireless status view'), then enumerates the content: radio details, frequencies, and associated clients. This distinguishes it from nearby siblings like router_wifi_overview, router_wifi_clients, and router_wifi_scan even without naming them.
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?
There is no guidance about when to use this tool versus alternatives such as router_wifi_overview, router_wifi_clients, or router_wifi_scan. The description states what it returns but gives no context for choosing it over similar wireless 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds useful behavioral context with 'fixed, non-configuring', clarifying that the command does not modify router state and is not interactive or configurable. 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?
A single, tight sentence that front-loads the action and the key qualifiers ('fixed', 'non-configuring'). Every word earns its place; there is no filler or repetition of the tool name.
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 tool is simple and annotations cover safety, but the description omits parameter details and return behavior. For a diagnostic command runner, an agent would benefit from knowing that 'target' is an address or hostname and whether output is raw command output. The description is minimally viable but has 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?
With 0% schema description coverage, the description must compensate by explaining the parameters. It names operation values Ping, Traceroute, and DNS, which maps to the 'operation' enum, but it says nothing about 'target' or 'family'. An agent would still be left guessing what target format is expected or how family is used.
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 ('Run') and a clear resource: the fixed, non-configuring Ping, Traceroute, or DNS command used by the LuCI diagnostics page. It conveys what the tool does and hints at its scope, though it does not explicitly differentiate it from the sibling 'router_network_diagnostics'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool executes the same diagnostic commands as the LuCI diagnostics page, which implies when an agent would use it. However, it does not explicitly state when not to use it or name alternative tools, so it stops short of full routing 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?
The description repeats the read-only intent already stated by readOnlyHint=true and does not contradict annotations. It adds the 'LuCI status view' framing, but no further behavioral details such as what happens if the interface does not exist or whether data is a snapshot; annotations already cover the safety profile.
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 entire description is one short, front-loaded sentence with no filler. Every word contributes to the tool's purpose and scope.
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 one documented parameter, read-only annotations, and a single-interface scope, the description is mostly complete. The only missing piece is a brief indication of what fields the status view contains, but no output schema exists and 'status view' reasonably conveys the return nature.
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?
Schema description coverage is 100% because the 'interface' parameter is already documented as a logical interface name with examples. The description adds no parameter-specific detail beyond the schema, so it meets the baseline for high coverage but does not enhance it.
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 ('Get'), a clear resource ('LuCI interface status view'), and a singular scope ('one logical interface'), so an agent can tell it targets a single interface rather than all interfaces. It does not explicitly name sibling tools like router_interfaces, so it lacks explicit sibling differentiation.
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 phrase 'for one logical interface' gives clear context for when to invoke this tool: when a single interface's status is needed. It does not explicitly mention alternative tools or exclusion conditions, but the singular scope usefully implies not to use it for listing all interfaces.
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 establish the tool as read-only, idempotent, and non-destructive, so the description does not need to restate those. It adds valuable context by disclosing that kernel access is restricted to a fixed command, /bin/dmesg -r, which rules out arbitrary command execution or privileged paths.
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?
Two tight sentences with no filler. The core action is front-loaded, and the security-relevant fixed-command constraint earns its place as the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two well-schematized parameters and strong annotations, the description gives enough information for an agent to invoke it correctly. The main omission is that no output shape is described, but for a log-tail tool this is relatively minor and no output schema exists.
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?
Schema description coverage is 0%, so the description must carry semantic weight. It does clarify that 'source' maps to system or kernel logs and that 'lines' controls a bounded tail, but it never explicitly ties 'bounded tail' to the lines parameter or explains the numeric bounds beyond what the schema's default/min/max already show.
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?
States a specific verb ('Read') and a precise resource ('bounded tail of system or kernel logs'), making the tool's function immediately clear. The kernel-specific note about /bin/dmesg -r further distinguishes the kernel log path from general system logging.
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 given about when to use this tool instead of any of the many router_* siblings, nor are there exclusions or prerequisites. The fixed-command note is about operational safety, not tool 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, so the safety profile is covered. The description adds useful context by specifying that it shows 'active' rules (not just configured ones) and that the view is 'filtered' and 'paginated', which goes beyond 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 one efficient sentence that front-loads the verb and resource, includes key qualifiers ('filtered', 'paginated', 'read-only', 'active'), and contains 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?
The tool has 5 undocumented parameters and no output schema, so a complete description would need to explain parameter relationships and the return shape. While the description names the resources and mentions filtering/pagination, it lacks details on how filters interact, pagination defaults, or what the output contains, making it adequate but not 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% for 5 parameters, so the description must compensate by explaining their meaning. It only hints at 'filtered' and 'paginated' behavior without mapping them to the chain, table, family, limit, and offset parameters, leaving the agent to infer which parameters correspond to which behavior.
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 a specific verb ('Get') and a precise resource ('active nftables rules, sets, maps, and counters'), which clearly distinguishes it from sibling tools like router_firewall_status or router_routes. The qualifier 'filtered, paginated read-only view' further clarifies the tool's exact scope.
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 resource name and description imply the tool is for nftables-related inspection, but there is no explicit statement of when to use this tool vs alternatives, nor mention of any exclusions. Sibling tools like router_firewall_status could overlap conceptually, and no guidance is given to differentiate them.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the LuCI catalog and reinforces that no package mutations occur, but it does not disclose behavior around pagination, query matching, or result structure.
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, well-structured sentence that front-loads the core action and then adds the key non-obvious context about package mutations. Every phrase earns its place with no redundancy or filler.
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 browse tool with strong annotations, the description is mostly sufficient, but gaps remain: no output schema, no parameter explanations, and no mention of pagination/filtering behavior. An agent could call it correctly, but would be uncertain about the exact meaning of query and result formatting.
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 carries the burden of explaining parameters. It only hints at the scope dimension by mentioning 'installed and available', but leaves limit, query, and offset entirely unexplained; these are not self-evident beyond their names.
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 identifies the action ('Browse') and the resource ('package catalog shown by LuCI'). It explicitly scopes the tool to installed and available packages and contrasts it with updating, installing, or removing packages, making it easy to distinguish from package-management siblings.
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 communicates a clear read-only browsing context and signals when this tool is appropriate relative to mutation operations. It does not explicitly name an alternative sibling like router_packages, but the 'without updating, installing, or removing' phrasing effectively conveys the intended use case.
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 establish this as readOnlyHint=true, idempotentHint=true, and destructiveHint=false; the description's 'Get' is consistent with those. It adds context about the returned content but does not disclose details like whether the PoE state is hardware-dependent, how current the counters are, or any response-size caveat.
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 delivers the verb, resource, and key output fields with no filler. It is front-loaded and every phrase adds value.
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 no-parameter, read-only status tool, the description is largely complete: it names the exact table and its data fields. The only minor gap is that 'optional PoE state' is not explained (e.g., when it is present), and there is no explicit mention of the return shape, but the annotations cover safety and no parameters need clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero properties, and the description references the optional PoE state without claiming a parameter to toggle it. With no parameters to document, the baseline is 4; the description correctly focuses on the result content instead of inventing parameter guidance.
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 a specific verb ('Get') and a precise resource ('the LuCI overview port table'), then enumerates the returned data categories (bridge/VLAN, link, counters, zones, optional PoE state). This is distinct from sibling tools like router_interface_details or router_realtime_stats because it targets a particular LuCI overview table.
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 states what the tool returns but gives no guidance about when to prefer it over sibling tools. There are no alternatives named, no exclusions, and no context such as 'use for port-level visibility'.
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 carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description is consistent with them. The description adds return-content context (byte counts for mounted filesystems) but does not disclose edge behavior such as whether virtual/pseudo filesystems are included or whether any mount access is required.
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 11-word sentence with no filler. The verb is front-loaded, and every detail (resource and three data fields) earns its place without 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?
For a zero-parameter, read-only tool, the description adequately covers what the tool does and what it returns. With no output schema present, the description carries the return-shape burden and meets it by naming the three byte counts, though it omits minor optional details like filesystem type filtering.
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 takes zero parameters, so the baseline is 4. The empty schema is trivially fully covered, and no parameter-level semantics need to be explained in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a concrete resource ('mounted filesystems') and states the returned data (total, available, free byte counts). This clearly differentiates it from the 29 siblings, which cover routes, neighbors, wifi, logs, services, and other distinct domains.
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?
There is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. Given the large sibling group, an agent must infer appropriate usage purely from the resource name rather than receiving any routing help.
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 establish read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context by saying the result is a bounded snapshot, which signals a point-in-time view with a size limit. 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, efficient sentence that front-loads the action and scope. Every word adds meaning, and there is no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and strong annotations, the description is nearly sufficient. The main gaps are the lack of explicit return-shape information and no direct comparison to sibling tools, but these are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explicitly explain the `limit` parameter, but 'bounded' hints at it. The schema fully documents `limit` with default, minimum, and maximum values, so the agent can invoke the tool correctly despite the lack of description-level parameter detail.
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 a specific verb ('Get') and a specific resource ('active conntrack entries'), and 'bounded snapshot' further clarifies scope. This clearly distinguishes it from sibling tools like router_routes, router_neighbors, or router_firewall_status.
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 use for viewing current connection-tracking entries, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. There is enough context to infer the general purpose, but no explicit routing 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 declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds the behavioral detail that leases are 'current' (live), but says nothing about return format or edge cases. With annotations carrying the safety profile, this is acceptable though minimal.
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?
One short sentence with no wasted words. The resource and scope are front-loaded and entirely relevant.
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 no-parameter, read-only, non-destructive tool, the description sufficiently identifies what is retrieved. It does not detail the output structure, but no output schema exists and the resource name conveys the expected result. Minor gaps around empty results or formatting exist but are not critical.
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 parameter schema coverage is trivially 100%. The description adds no parameter information, which is unnecessary. Baseline 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and exact resource ('current DHCPv4 and DHCPv6 leases'), which clearly distinguishes it from sibling tools like router_client_summary or router_connections. It is specific and avoids tautology.
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: use when you need current DHCP leases. However, it does not explicitly mention when to prefer this over the many sibling router status tools, nor does it name alternatives. The context is clear but the guidance is not explicit.
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 establish that this is read-only, idempotent, and non-destructive. The description adds modest context by specifying the scope as 'current status' across 'all logical' interfaces, but it does not disclose the output structure or edge cases such as empty results.
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 or redundancy; every word contributes meaning.
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 zero-parameter read-only tool with thorough safety annotations, the description is nearly sufficient. The main gap is the lack of any indication about the shape or fields of the returned status, which would be useful since there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics for the description to explain. This aligns with the baseline for parameterless tools and requires no additional compensation.
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 action ('Get') and a bounded resource ('the current status of all logical network interfaces'). The qualifiers 'all logical' clearly distinguish this from physical port or single-interface/detail tools like router_port_status and router_interface_details.
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 when to use it: when the current status of all logical interfaces is needed. However, it does not explicitly mention alternatives or exclusion cases, and with closely related siblings like router_interface_details, explicit guidance would have been valuable.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the context that these are the methods 'allowed by this MCP server', implying a restricted set. It does not contradict annotations, but it adds little beyond what annotations provide. There is no description of output format or side effects, though side effects are covered by 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 with no wasted words. The key information (listing method signatures, read-only scope, server allowance) is front-loaded, making it easy for an agent to parse quickly.
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 zero-parameter tool with annotations covering safety, the description is largely sufficient. However, since there is no output schema, the agent is left to infer what 'list method signatures' returns exactly—whether it's a flat list of signatures, a mapping of object names to signatures, or something else. This ambiguity could affect how the agent interprets the response. Additional clarification on the response format would make it completely complete.
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% (empty properties object). There is nothing for the description to explain about parameters. The baseline of 4 for 0-parameter tools is appropriate; the description does not need to compensate for any undocumented parameters.
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 ('List') and a precise resource ('method signatures for the read-only ubus objects allowed by this MCP server'). It clearly distinguishes itself from sibling tools that query actual router data (stats, routes, neighbors, etc.) by focusing on available method signatures rather than data itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering what read-only ubus methods are available on this server, which contrasts with the data-returning sibling tools. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions (e.g., 'use this before calling other tools to see allowed methods'). The context is clear but not fully explicit.
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, idempotentHint true, and destructiveHint false. The description adds value by enumerating the exact categories of information returned (board, firmware, kernel, etc.), which goes beyond the annotations and gives the agent a precise expectation of the response content. No contradictions 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 sentence with no redundancy. The verb and resource are front-loaded, and the enumerated fields are carefully chosen to be both comprehensive and compact. Every word contributes to the agent's 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?
For a read-only system info tool with no parameters and no output schema, the description fully specifies what the agent will get. It lists all relevant information categories (board, firmware, kernel, load, memory, uptime, LuCI version), which is sufficient for an agent to decide to call it and interpret the result. Nothing essential is missing.
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 takes zero parameters, so the description does not need to explain parameter semantics. Per the rubric, a 0-parameter tool gets a baseline of 4. The description's list of fields further clarifies what the agent will receive, so no additional parameter explanation is required.
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 verb 'Get' and the resource 'system info' with a specific enumeration of fields: board, firmware, kernel, load, memory, uptime, and LuCI version. This distinguishes it from sibling tools like router_realtime_stats or router_routes, making the purpose unambiguous.
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. With 29 sibling tools, an agent cannot know whether to pick this over more specific ones (e.g., router_realtime_stats for real-time data, router_storage for disk usage). No exclusions or conditions are mentioned.
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 establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by indicating that the tool merges and reconciles three different client data sources into one inventory, which is more than a simple fetch and clarifies the tool's integration behavior.
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, focused sentence that starts with the action verb and immediately states the inputs and output concept. Every word contributes meaning, with no filler or repetition.
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 no-parameter, read-only, idempotent summary tool, the description provides the essential information: what data sources are merged and what the result represents. It could be slightly more explicit about the output shape (e.g., what fields a client entry contains), but the core invocation context is sufficiently complete.
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 there is no parameter documentation burden to carry. The description does not need to add parameter semantics, and the schema is fully consistent with the tool being a no-input summary operation.
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 a specific verb ('Merge') and names the exact resources being combined (DHCP leases, LuCI host hints, Wi-Fi associations) into a single client inventory. This clearly differentiates it from sibling tools like router_dhcp_leases and router_wifi_clients, which each return individual data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied but not explicit. The description suggests the tool is for obtaining a unified client inventory, and an agent can infer it should be used instead of querying multiple individual source tools. However, it does not explicitly state when to choose this over alternatives or mention any exclusions.
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 idempotentHint=true, and the description reinforces this with 'read-only summary.' It adds useful behavioral context by specifying 'from UCI,' clarifying that the tool returns configuration data rather than live firewall state. It also states the scope as a 'summary' rather than exhaustive detail, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and resource immediately. Every word contributes value, listing the specific firewall components covered without waste. It is highly scannable and appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless, read-only tool, the description adequately covers the context by enumerating the expected content areas: defaults, zones, forwardings, redirects, and rules. There is no output schema, so a bit more detail on the response structure could be helpful, but the listed components give an agent a clear expectation of what will be returned.
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 the input schema is an empty object, so the schema fully covers parameter semantics. According to the rubric, a baseline of 4 applies when there are no parameters. The description does not need to add parameter meaning.
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 'Get' and a specific resource: 'read-only summary of firewall defaults, zones, forwardings, redirects, and rules from UCI.' It clearly identifies what the tool does and distinguishes it from siblings like router_nftables_rules or router_security_audit, which serve different firewall-related purposes.
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 its usage: when a read-only firewall configuration summary is needed. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives such as router_nftables_rules for live/nftables details. No exclusions are stated, so the context is clear but not fully explicit.
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 reinforces the annotations by stating the operation uses 'fixed read-only ip commands' and returns 'current' tables, conveying determinism and non-mutating behavior. This adds context beyond the readOnlyHint, idempotentHint, and destructiveHint annotations, though it does not describe potential edge cases like empty tables or command failures.
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 front-loads the action and resource, then adds the read-only execution detail. Every element earns its place and there is no redundant or filler 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?
For a zero-parameter, read-only, idempotent lookup tool, the description is sufficiently complete. It identifies the exact data returned and the read-only nature of the operation, though a bit more detail about the output shape or command behavior could further help, but this is not critical given the tool's simplicity and annotations.
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 the schema already documents this completely. With no parameters to explain, the description appropriately focuses on what the command fetches rather than parameter details, exceeding the baseline 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 states the specific verb 'Get', the resource ('current IPv4 ARP and IPv6 NDP neighbor tables'), and the mechanism ('two fixed read-only ip commands'). This clearly distinguishes the tool from siblings like router_routes or router_known_hosts by naming the exact neighbor-table data being fetched.
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 makes clear what the tool retrieves, so an agent can infer when to use it for neighbor table information. However, it does not explicitly mention when to prefer this tool over alternatives such as router_routes or router_known_hosts, and it provides no exclusion criteria.
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?
The description explicitly says 'read-only audit,' which aligns with the annotations readOnlyHint=true, idempotentHint=true, and destructiveHint=false. However, it adds little behavioral context beyond what the annotations already provide; it does not disclose output format, permissions, or what happens when issues are found. This is acceptable given the strong annotation coverage, but not exceptional.
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 identifies the operation ('read-only audit') and then lists the specific checks. Every word earns its place, with no redundancy or filler.
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 no-input, read-only audit tool, the description is largely complete: it names the audit areas and is backed by clear annotations. The absence of an output schema means the description might ideally mention what the returned result looks like, but the verb 'audit' strongly implies a report of findings, so this is a minor gap.
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 there is nothing for the description to explain about inputs. The schema coverage is effectively 100% and the description correctly implies that invoking this tool requires no arguments. A baseline of 4 is appropriate for a no-parameter 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 states a specific verb ('Run'), a clear resource ('router security audit'), and enumerates the concrete audit categories: unsafe WAN input, management port forwards, HTTP-only LuCI, and SSH password authentication. This clearly distinguishes it from sibling tools like router_firewall_status or router_luci_pages, which are more general or unrelated.
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 makes the intended use case clear: perform a read-only security audit of specific router security concerns. It does not explicitly name alternatives or exclusion conditions, but the audit scope and read-only nature give an agent enough context to select it over real-time stats, logs, or configuration 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?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds a meaningful behavioral safeguard: it explicitly promises not to return UCI secrets. This is valuable privacy-oriented context beyond 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.
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 purpose and adds a key safety qualifier. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description sufficiently explains what the tool returns for a zero-parameter read-only endpoint. It lacks details about the exact shape or depth of the overview, but given the absence of an output schema and the simplicity of the tool, the information provided is adequate.
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 the schema is empty, so no parameter documentation is needed. The description does not need to compensate for missing parameter information, and the baseline for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('configured wireless radios and networks'), and the scope is explicitly defined. It distinguishes itself from real-time or client-focused sibling tools by emphasizing 'configured' rather than live 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 the tool is for retrieving configuration-level wireless information, but it does not explicitly state when to prefer this over router_wifi_details, router_wifi_clients, or other wireless-related siblings. There are no explicit exclusions or alternative routing instructions.
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, idempotentHint=true, and destructiveHint=false, which fully communicate the safe read-only nature. The description agrees with these annotations and adds specificity about the data returned, but it does not provide additional behavioral details such as output format or response characteristics beyond that.
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 verb and primary resource, then efficiently enumerates the specific data categories. Every phrase contributes meaning and there is no redundant or filler content.
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, no output schema, and clear annotations, the description is complete. It enumerates all the information categories returned—local time, uptime, timezone configuration, and time service status—which is sufficient 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty with 100% coverage, so there is nothing for the description to add about parameter semantics. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on the output rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a clear resource: router local time, uptime, timezone-related configuration, and time service status. This cleanly separates it from the sibling tools, none of which focus on time information.
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 states exactly what information the tool returns, so an agent can infer when to choose it: whenever router time, uptime, timezone settings, or time service status is needed. It does not name alternatives, but no sibling tool appears to cover this same domain, so explicit exclusions are less critical.
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, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds a useful behavioral note ('without changing wireless configuration') and the iwinfo dependency, but it does not disclose potential scan latency or the shape of the returned network list.
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?
One sentence carries the action, scope, and safety guarantee with no filler. The critical information is front-loaded and every phrase earns its place.
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 tool is simple: one optional parameter, no output schema, and strong annotations. The description tells the agent exactly what the tool does, how the parameter behaves, and that it is non-mutating, which is sufficient to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the optional device parameter, and the description reinforces that the parameter selects a single interface while omission means all interfaces. This clarifies the default behavior beyond the schema's 'optional' label.
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 a specific verb and resource ('Scan nearby Wi-Fi networks') plus a clear scope ('one interface or every interface'). This distinguishes it from sibling Wi-Fi tools like router_wifi_overview and router_wifi_clients, which inspect existing state rather than discover nearby networks.
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 makes the use case clear: call when you need to discover reachable Wi-Fi networks, optionally constrained to a specific interface. It does not name alternatives or spell out when not to use it, but the scanning semantics provide enough contextual guidance for an agent to select it appropriately.
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, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond those by explicitly stating the tool cannot alter service state, which is a useful operational boundary for the agent. It does not elaborate on return format, but the safety profile is well covered.
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 two short sentences with no fluff. The core purpose is front-loaded, and the key limitation is stated immediately after. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only status tool, the description is nearly complete: it states the resource, the operation, and the key limitation. It does not describe the shape of the returned status information, but for this simple scope and with annotations covering safety, the gap is minor. The agent can safely call this tool without additional clarification.
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 schema and description are both complete by default. The description does not need to add parameter-level detail because there are none to document. The baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('procd service status'), making the tool's purpose immediately understandable. The explicit statement that it cannot start, stop, or restart services further distinguishes it from service-management tools. This is clear enough to separate from its many router_* siblings.
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 states when not to use the tool: it cannot start, stop, or restart services. This gives the agent a firm exclusion for mutation attempts, though it does not name an alternative tool for those actions. The context is otherwise clear for a status-checking tool.
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, idempotentHint=true, and destructiveHint=false, covering safety expectations. The description adds useful context beyond those annotations by indicating the result will include not just pages but also their implementation status, which helps the agent understand what the tool returns. There is no contradiction, and the behavior of a read-only list operation is simple enough that no further disclosure is required.
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 one concise sentence that front-loads the verb and resource, then adds the relevant detail about implementation status. There is no redundant wording or filler.
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 listing tool, the description is fully complete: it states what is listed and what information is provided. The empty schema and strong annotations handle the remaining calling context, and no output schema is needed for an agent to know what to expect from this 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 and the schema confirms this with empty properties. Per the calibration baseline for tools with no parameters, the description does not need to explain parameter semantics, and it does not attempt to.
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 a specific verb ('List') and identifies a clear resource (standard LuCI pages represented by this MCP server) plus what is reported about them (implementation status). It is easily distinguished from the sibling tools, which cover network statuses, diagnostics, and system information rather than a server page inventory.
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 establishes that this tool is for discovering which standard LuCI pages the server exposes and their implementation status. It does not explicitly name alternatives or exclusion conditions, but no sibling tool appears to overlap with this purpose, so the usage context is clear enough without needing to rule out alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds the valuable behavioral guarantee of 'without sending probes,' which is not captured by those annotations. It gives the agent confidence that invocation has no active network side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence front-loads the action and scope while ending with the key behavioral constraint. Every word adds value and there is no redundancy or filler.
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 zero-parameter, read-only diagnostic tool, the description is complete: it states the tool's purpose, its passive nature, and the specific network domains covered. No further information is needed for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so parameter documentation is not needed. The description compensates by enumerating what diagnostic areas are covered, which is the only relevant semantic information for invoking the 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 uses a specific verb ('perform passive diagnostics') and names the exact resources involved: WAN state, addressing, DNS, default routes, uptime, and Wi-Fi. This clearly distinguishes it from sibling tools like router_run_diagnostic by emphasizing passivity.
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 establishes a clear usage context: passive diagnostics without sending probes. It implies this is the safe, non-intrusive option versus active diagnostics, though it does not explicitly name alternatives or state when not to use the tool.
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, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful operational context by stating it uses fixed read-only ip commands and covers both IPv4 and IPv6, which clarifies the tool's deterministic, non-mutating behavior without contradicting 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, tightly worded sentence that front-loads the action and resource. Every word conveys useful information, with no filler or repetition.
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 is a simple parameterless read-only query with no output schema, the description provides sufficient context for correct invocation: it names the resource, the scope, and the non-mutating implementation. There are no missing inputs or complex behaviors that would require additional explanation.
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 there is nothing for the description to explain about inputs. The baseline of 4 for parameterless tools applies, and the description does not need to compensate for any schema gaps.
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 a specific verb ('Get') and a clear resource ('active IPv4/IPv6 routes and policy rules'), making the tool's function immediately obvious. This distinguishes it from sibling tools focused on interfaces, neighbors, WiFi, or diagnostics.
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 the tool is for retrieving route and policy rule information, giving a clear context in which it applies. It does not explicitly name alternative tools or exclusions, but the resource-specific scope is enough for an agent to select it appropriately among the sibling tools.
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:

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

Score Badge

Copy to your README.md:

[![openwrt-luci-mcp MCP server](https://glama.ai/mcp/servers/JeffersonYoung/openwrt-luci-mcp/badges/score.svg)](https://glama.ai/mcp/servers/JeffersonYoung/openwrt-luci-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/JeffersonYoung/openwrt-luci-mcp'

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