Provides tools for monitoring and managing AsusWRT and AsusWRT-Merlin routers via SSH, including network diagnostics, client management, wireless settings, and security features.
Allows enabling or disabling the OpenVPN server on the router.
Supports monitoring and managing WireGuard VPN settings on the router.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AsusWRT MCP Server list connected clients"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mcp-name: io.github.teefloo/asuswrt-mcp
Model Context Protocol (MCP) server for secure, controlled administration of AsusWRT and AsusWRT-Merlin routers via SSH.
This MCP server provides AI assistants (like Claude, Cursor, etc.) with a safe interface to monitor and manage AsusWRT routers. It operates exclusively over SSH using allowlisted operations—no arbitrary command execution, no firmware modifications, and no factory resets.
Related MCP server: OpenWRT SSH MCP Server
Category | Tools |
Identity & Health | Router model, firmware version, uptime, load, memory |
Network | LAN/WAN details, DNS config, IPv6 status, routing table |
Clients | Connected clients, DHCP leases, ARP neighbors |
Wireless | Radio status, SSIDs, guest networks, client counts per band |
Services | Running processes, open ports, cron jobs |
Storage | USB devices, mounts, partitions, filesystem usage |
Security | UPnP, DDNS, Samba status, conntrack usage |
VPN | OpenVPN server, WireGuard, VPN client profiles |
Administration | Web admin ports, SSH/telnet access settings |
Diagnostics | SSH TCP/banner/auth diagnostics, config snapshot |
All mutation tools require:
confirm: true parameter
ASUSWRT_ALLOW_MUTATIONS=true environment variable
Support for dry_run: true to preview changes
Tool | Description |
| Restart allowlisted services (httpd, firewall, wireless, dnsmasq, etc.) |
| Enable/disable DHCP server |
| Enable/disable UPnP |
| Enable/disable Wi-Fi radio bands |
| Enable/disable guest Wi-Fi |
| Toggle LAN access for guest Wi-Fi |
| List, add, remove, enable/disable port forwarding rules |
| Enable/disable OpenVPN server |
| List, block, unblock, remove parental control rules |
| Toggle block-all mode |
| List, add, remove DHCP static reservations |
No arbitrary SSH: Only allowlisted commands are executed via NVRAM and service calls
No firmware operations: No flash, reset, or bootloader access
Secret redaction: Passwords and sensitive data are never exposed in tool responses
Dry-run support: Every mutation can be previewed before applying
Confirmation required: Mutations require explicit confirm=True
SSH-only transport: No exposure of the router's web API
Python 3.11+
An AsusWRT or AsusWRT-Merlin router with SSH access enabled
Network connectivity from the MCP client to the router
git clone https://github.com/Teeflo/asuswrt-mcp.git
cd asuswrt-mcp
# Create virtual environment
python -m venv .venv
# Activate (Linux/macOS)
source .venv/bin/activate
# Activate (Windows)
.venv\Scripts\activate
# Install dependencies
pip install -e .# Copy example configuration
cp .env.example .env
# Edit with your router credentials
# Use your favorite editor:
notepad .env # Windows
nano .env # Linux/macOS.env# Required: Router connection
ASUSWRT_HOST=192.168.1.1
ASUSWRT_SSH_USERNAME=admin
ASUSWRT_SSH_PASSWORD=your_password
# Optional: SSH key authentication
# ASUSWRT_SSH_KEY_FILE=~/.ssh/id_rsa
# Optional: Enable mutations (disabled by default)
# ASUSWRT_ALLOW_MUTATIONS=true
# Optional: Connection settings
# ASUSWRT_SSH_PORT=22
# ASUSWRT_TIMEOUT_SECONDS=10# Standard stdio mode
python -m asuswrt_mcp.server
# Or use the entry point
asuswrt-mcpAdd to your claude_desktop_config.json:
{
"mcpServers": {
"asuswrt-mcp": {
"command": "C:\\path\\to\\asuswrt-mcp\\.venv\\Scripts\\python.exe",
"args": ["-m", "asuswrt_mcp.server"],
"env": {
"ASUSWRT_HOST": "192.168.1.1",
"ASUSWRT_SSH_USERNAME": "admin",
"ASUSWRT_SSH_PASSWORD": "your_password"
}
}
}
}npx @modelcontextprotocol/inspector python -m asuswrt_mcp.serverpip install -e ".[dev]"
pytestASUSWRT_TEST_ROUTER=1 pytestasuswrt-mcp/
├── src/asuswrt_mcp/
│ ├── server.py # FastMCP entrypoint & tool definitions
│ ├── service.py # Business logic & router operations
│ ├── config.py # Settings management
│ ├── clients/
│ │ └── ssh.py # SSH client wrapper
│ ├── nvram.py # NVRAM parsing utilities
│ ├── ssh_parsers.py # Output parsers for SSH commands
│ ├── security.py # Mutation guards & redaction
│ ├── validators.py # Input validation
│ ├── responses.py # Tool response formatting
│ ├── errors.py # Custom exceptions
│ └── serialization.py # Safe serialization
├── tests/ # Test suite (69 tests)
├── .env.example # Example configuration
├── pyproject.toml # Project metadata
└── README.md # This fileMIT License - see LICENSE for details.
asusrouter for the underlying Python library
MCP for the protocol specification
AsusWRT-Merlin for the firmware
Inspect web, SSH, and telnet administrative access settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'inspect' correctly indicates a read-only operation, but no further behavioral traits are mentioned (e.g., authentication requirements, side effects, or what happens if settings are unavailable). The description is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 9 words with no superfluous content. It is front-loaded with the verb and effectively conveys the tool's purpose. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of parameters and output schema, the description sufficiently explains what the tool does (inspect settings). It is complete for a simple read-only inspection tool. The agent can infer that the output will be the current settings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100%, so there is no need for the description to elaborate on parameters. Baseline for no parameters is 4, and the description does not add param information, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'inspect' and clearly identifies the resource ('web, SSH, and telnet administrative access settings'). This distinguishes it from sibling tools like asuswrt_web_admin (which focuses on web admin) or asuswrt_ssh_diagnostics (SSH diagnostics). It is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. While the scope is implied, there is no explicit mention of context, prerequisites, or when not to use it. For example, it does not clarify if this should be used before modifying access settings or if it overlaps with other inspection tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List ARP/IP neighbor entries known by the router.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool lists entries but does not disclose if it might be slow, require authentication, or if entries are cached. However, the behavior is simple and self-evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and contains no superfluous words. It fully describes the tool's purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a simple purpose, the description is sufficient. It clearly states what the tool does, and there are no missing details that would hinder correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description does not need to explain them. Baseline is 4, and the description adds no parameter info, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List ARP/IP neighbor entries known by the router' uses a specific verb ('list') and resource ('ARP/IP neighbor entries'), clearly distinguishing it from sibling tools like asuswrt_clients or asuswrt_route_table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to see neighbor entries) but provides no explicit guidance on when not to use it or alternatives. Since the tool is parameterless and straightforward, the lack of exclusions is acceptable but not proactive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return server capabilities, guardrails, and safe settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. While 'Return' implies a read-only operation, there is no disclosure of potential side effects, required permissions, or performance implications, which is insufficient for a tool with no annotation backing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but it is not particularly informative and could be more specific. It is not wasteful, but it sacrifices clarity for brevity, earning a 4 rather than a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and no annotations, the description is the sole source of context. It specifies three outputs (capabilities, guardrails, safe settings), but does not elaborate on format, granularity, or how these relate to other tools. It is minimally complete but lacking depth for complex decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially covered at 100%. The description does not need to add parameter information, and the baseline of 4 is appropriate given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'server capabilities, guardrails, and safe settings,' which indicates a read operation providing an overview. However, the terms are vague and do not distinguish it from sibling tools like asuswrt_health or asuswrt_system_stats, which may also return status information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternative sibling tools. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List connected clients reported by the router.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'list', implying a read operation, but fails to disclose whether it requires admin privileges, how clients are determined (ARP table, active connections), or any side effects. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no wasted words. It is appropriately sized for a simple, parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is minimal. It conveys the core function but could be more complete by specifying the type of clients (wired/wireless, active vs. all) or the source data (e.g., ARP table). As it stands, it is adequate but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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%. The description does not need to explain parameters. According to guidelines, a baseline of 4 is appropriate when there are no parameters, and no additional param information is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list') and the resource ('connected clients reported by the router'). It distinguishes itself from sibling tools like asuswrt_dhcp_leases, which focus on DHCP leases rather than currently connected clients.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 other listing tools (e.g., asuswrt_dhcp_leases, asuswrt_network_overview). The description lacks context for the agent to decide between alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a redacted read-only configuration snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description indicates 'read-only' and 'redacted' for safety, but does not disclose other traits like response size, permissions required, or potential delays.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, front-loaded with the verb and key characteristics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately covers the tool's purpose and safety. It could mention what the snapshot includes, but is complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Baseline for zero parameters is 4, and the description adds no parameter info, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource 'configuration snapshot', and adds 'redacted read-only' to distinguish from sibling tools that fetch specific parts of the configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like specific config fetchers (e.g., asuswrt_dns_config). Usage is implied as a general overview, but lacks explicit when-not-to-use or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect conntrack table usage and limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. 'Inspect' implies a read-only operation, but the description does not explicitly confirm it is non-destructive or clarify side effects. It is minimally adequate for a simple status check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise and front-loaded. However, it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description identifies the tool's purpose but does not explain the output format or what specific 'usage and limits' data is returned. Given no output schema, the description should provide more context. For a simple status tool, it is bordering on sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is trivially 100%. The description adds no parameter information because none is needed. Baseline 4 for parameterless tools is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect') and clearly identifies the resource ('conntrack table usage and limits'). It distinguishes the tool from sibling tools like asuswrt_dhcp_leases or asuswrt_arp_neighbors by focusing on a unique subsystem.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives, or any prerequisites. The description is a simple statement of functionality without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect scheduled cron jobs reported by cru.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, authentication requirements, or read-only nature. The word 'Inspect' implies read-only but is not explicit, leaving uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description minimally explains its function. However, it does not hint at the return format or any additional context like the nature of 'cru', which could help an agent understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema coverage is 100%. The description adds no parameter information, but none is needed. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Inspect' and the resource 'scheduled cron jobs reported by cru', which precisely defines the tool's purpose. It is distinct from sibling tools that deal with other aspects of ASUS router administration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of prerequisites, context, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect Dynamic DNS enablement and current provider settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. 'Inspect' implies read-only behavior, which is appropriate, but it does not explicitly disclose that the tool makes no changes or any other behavioral traits. It is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless inspection tool, the description covers the key aspects. However, since no output schema exists, a brief hint about what the output contains would enhance completeness. Still, it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100% by default. The description adds meaning by specifying that the tool inspects 'enablement and current provider settings,' clarifying the scope beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it inspects Dynamic DNS enablement and provider settings, using a specific verb and resource. It is distinct from sibling tools like asuswrt_dns_config, which deals with general DNS settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 or when not to use it. The description only states the purpose, offering no selection advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect DHCP server pool settings and static reservations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states 'Inspect', implying read-only, without disclosing any additional behaviors, side effects, or expected output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no extraneous information. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is adequate but could be more complete by explicitly noting it is a read-only operation and providing more detail on what the output contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description adds value by explaining what the tool returns (pool settings and reservations). Schema coverage is 100%, so a baseline of 3 applies, but the description goes beyond by specifying the content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Inspect' and resource 'DHCP server pool settings and static reservations', clearly distinguishing it from siblings like asuswrt_dhcp_leases and asuswrt_dhcp_reservation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the description but lacks explicit guidelines on when to use this tool versus alternatives or when not to use it, especially given the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active DHCP leases from dnsmasq.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description is minimal. Does not disclose any behavioral traits such as data staleness, permission requirements, or limitations beyond the basic listing action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Efficient but could include additional context without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with no parameters or output schema; description provides basic purpose. However, lacks differentiation from many similar sibling tools, reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Baseline score of 4 applies as description does not need to augment parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List', resource 'active DHCP leases', and source 'dnsmasq'. It distinguishes from sibling tools like asuswrt_clients and asuswrt_dhcp_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like asuswrt_clients or asuswrt_dhcp_config. Lacks any context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List, add, or remove DHCP static reservations via SSH NVRAM.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| mac | No | ||
| ip | No | ||
| name | No | ||
| confirm | No | ||
| dry_run | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions multiple actions including mutation (add, remove) but does not disclose behavioral traits beyond what the name implies. No annotations exist, so the description should cover safety, confirmation requirements, or persistence of changes, but it does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it lacks structure (e.g., no bullet points for actions or parameter relationships). It is concise but fails to provide essential detail, earning a mid-range score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with multiple actions, 6 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain return values, error cases, or how to properly invoke each action, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning to the parameters. Of the 6 parameters (action, mac, ip, name, confirm, dry_run), only 'action' is implied. The agent receives no help understanding required constraints (e.g., which fields are needed for add vs remove).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb (List, add, or remove), resource (DHCP static reservations), and method (via SSH NVRAM). It effectively distinguishes this tool from the many sibling tools covering other ASUSWRT functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., asuswrt_dhcp_leases, asuswrt_dhcp_config). There are no prerequisites or warnings about side effects, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or disable the DHCP server.
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | Yes | ||
| confirm | No | ||
| dry_run | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states 'enable or disable' which implies state mutation, but does not describe side effects (e.g., whether existing DHCP leases are affected), required permissions, or the meaning of confirm and dry_run parameters. This is insufficient for an agent to understand the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, conciseness should not come at the expense of completeness; key information about parameters and behavior is omitted. It is appropriately sized for a simple toggle but lacks structure (e.g., no bullet points or parameter guidance).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no output schema, and no annotations, the description is severely lacking. It does not explain return values, side effects, or the interaction between parameters. For example, what happens if dry_run is true? What does confirm do? The description is far from complete for an agent to invoke the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain any of the three parameters (enabled, confirm, dry_run). The schema provides only types and defaults, so an agent has no semantic understanding of how these parameters affect the DHCP server operation. The description should have clarified the role of confirm and dry_run, especially given they are not self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (enable or disable) on a specific resource (DHCP server). It is a direct verb+resource pairing, but does not explicitly differentiate from sibling tools like asuswrt_dhcp_config which might also modify DHCP settings. The name itself provides context, so clarity is high but differentiation is lacking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For example, there is no mention that asuswrt_dhcp_config exists for more detailed configuration, or what prerequisites (e.g., router access) are needed. The description implies a simple toggle but gives no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect WAN and LAN DNS settings reported by NVRAM.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'inspect', implying a read-only operation, but lacks details on side effects, authentication requirements, rate limits, or output characteristics. Behavioral transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential information without extraneous wording. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description is reasonably complete for a simple inspection tool. However, it could be slightly more detailed about what specific DNS settings are reported (e.g., server IPs, search domains), but this does not significantly hinder understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the tool has zero parameters and schema coverage is 100%, there is no need to explain parameters. Baseline according to instructions is 4, and the description suffices without adding param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'inspect' and the resource 'WAN and LAN DNS settings reported by NVRAM', making the tool's purpose very specific. It distinguishes itself from sibling tools that focus on other aspects like DHCP, WAN details, or connectivity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 other DNS-related tools or any alternatives. There is no mention of prerequisites, typical use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Toggle LAN access for a guest Wi-Fi slot.
| Name | Required | Description | Default |
|---|---|---|---|
| band | Yes | ||
| slot | Yes | ||
| allow_lan | Yes | ||
| confirm | No | ||
| dry_run | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It mentions 'Toggle', but the actual behavior sets allow_lan to a boolean, not a toggle. There is no disclosure of side effects, the role of confirm and dry_run parameters, or whether changes are reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but insufficient for a tool with 5 parameters. It lacks structure; no separation of purpose, parameters, or usage notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, 3 required, enums, boolean flags, no output schema), the description is severely incomplete. It fails to explain how to use the tool, what the parameters do, or what the outcome looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no explanation for the 5 parameters. It does not define band, slot, allow_lan, confirm, or dry_run, nor their meanings or typical values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Toggle' and the resource 'LAN access for a guest Wi-Fi slot'. It distinguishes this tool from siblings like asuswrt_guest_wifi or asuswrt_guest_networks by specifying a specific action on a specific slot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of prerequisites, when to choose this over similar tools, or scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List guest Wi-Fi networks and LAN-access state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it is a read operation ('List'), but no annotations are provided. It does not disclose additional behavioral traits such as side effects, permissions, or rate limits. Since it is a simple list, the description minimally meets expectations but adds no extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the main action. It could be slightly more informative but is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is adequate but not fully complete. It does not clarify how this tool relates to similar sibling tools or what the output contains, leaving some ambiguity for the AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters defined, so baseline is 4. The description adds no parameter information, which is acceptable as the schema covers 100% of the empty parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List guest Wi-Fi networks and LAN-access state', specifying the verb and resource. However, it does not differentiate from sibling tools like asuswrt_guest_wifi and asuswrt_guest_lan_access, which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of when to use it or when not to, and it does not reference sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or disable a guest Wi-Fi slot.
| Name | Required | Description | Default |
|---|---|---|---|
| band | Yes | ||
| slot | Yes | ||
| enabled | Yes | ||
| confirm | No | ||
| dry_run | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'enable or disable' but provides no details on consequences, reversibility, or side effects. The presence of 'confirm' and 'dry_run' parameters hints at cautious behavior, but the description does not explain their meaning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It lacks critical detail and does not earn its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (3 required), no output schema, and no annotations, the description is severely incomplete. It fails to explain required fields, enum values, or the purpose of auxiliary parameters like 'confirm' and 'dry_run'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameters are explained in the description. The description does not mention 'band', 'slot', 'enabled', 'confirm', or 'dry_run', leaving their semantics entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly uses 'enable or disable' as the verb and 'guest Wi-Fi slot' as the resource, making the core action clear. However, it does not distinguish from sibling tools like asuswrt_guest_lan_access or asuswrt_guest_networks, which also deal with guest Wi-Fi aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor are there any prerequisites, side effects, or conditions mentioned. The agent has no context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch router identity and basic health data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only implies a non-destructive read via 'fetch', but does not disclose auth needs, performance, or what 'health data' encompasses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with verb and object front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description adequately covers purpose but lacks detail on return format; given no output schema and many similar siblings, more specificity would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% (empty), and description adds no parameter info, which is acceptable since no parameters are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Fetch' and resources 'router identity and basic health data', distinguishing it from sibling tools like asuswrt_identity and asuswrt_system_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; many siblings offer more specific identity or health data, but description does not clarify when asuswrt_health is the better choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch router model and firmware identity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as whether the operation is read-only, requires authentication, or triggers any side effects. The agent has no information beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, which is appropriate for a simple retrieval tool with no parameters. However, it could include a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description lacks essential details such as return format, read-only nature, and authentication requirements. For a simple tool, more completeness is needed to guide an agent reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%, so the description's additional context ('router model and firmware identity') adds meaning about the expected output, compensating for the lack of parameter details. Baseline for no params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the specific resources 'router model and firmware identity', making the tool's purpose unambiguous. Among a large set of sibling tools focusing on various router functions, this uniquely identifies what the tool retrieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'asuswrt_system_stats' or 'asuswrt_capabilities'. There are no prerequisites or context that would help an agent decide to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect per-interface RX/TX counters from /proc/net/dev.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it reads from /proc/net/dev, indicating a read-only, low-impact operation. No annotations exist, so the description adequately covers the non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence conveying all necessary information with zero waste. Front-loaded with key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a parameterless tool with no output schema. Could be improved by hinting at output format (e.g., 'returns per-interface RX/TX byte counters'), but current description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100% trivially. The description adds no further parameter meaning, but baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect') and resource ('per-interface RX/TX counters from /proc/net/dev'), clearly distinguishing it from sibling tools like asuswrt_system_stats or asuswrt_network_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Usage is implied by the resource name, but no exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect IPv6 service, prefix, and router address details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Inspect', implying a read operation, but does not disclose any side effects, required permissions, or return behavior. For an inspection tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's function with no extraneous words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple no-parameter tool, but it lacks details about what the output contains (e.g., whether it returns a JSON object with the mentioned fields). Given no output schema, more context about return value would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. Baseline for no parameters is 4. The description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Inspect' and explicitly lists the resources: 'IPv6 service, prefix, and router address details'. This clearly distinguishes it from other asuswrt_* tools that focus on different aspects like health or WAN details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention related tools or conditions under which this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect loaded kernel modules reported by lsmod.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool inspects loaded kernel modules via lsmod, implying a read-only operation. No detailed behavior like permissions or side effects is mentioned, but for a simple inspection tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters, no output schema), the description provides sufficient context about what the tool does and the source (lsmod). It could optionally mention the return format or that it's read-only, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100%. According to guidelines, baseline is 3. The description adds no parameter information beyond the schema, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Inspect' and the specific resource 'loaded kernel modules reported by lsmod', distinguishing it from sibling tools like asuswrt_system_stats or asuswrt_service_processes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. However, due to the simple nature of the tool (no parameters, inspection only), the lack of explicit guidance is less critical. Still, it could mention that it is for diagnostic purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect LAN interface, addressing, and DHCP presence.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. 'Inspect' indicates a read-only operation. However, it does not mention potential side effects, permissions, or limitations. The description is minimal but not misleading for a simple inspection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. Every word contributes meaning, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is adequate but vague. It specifies 'addressing' and 'DHCP presence' but could more clearly indicate what data is returned (e.g., IP, subnet mask, DHCP status).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100% trivially. The baseline for 0 params is 4, and the description does not need to add parameter-specific information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Inspect LAN interface, addressing, and DHCP presence.' It uses a specific verb ('Inspect') and identifies the resources (LAN interface, addressing, DHCP presence). This distinguishes it from sibling tools like asuswrt_wan_details (WAN) and asuswrt_dhcp_config (configuration).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting LAN details but lacks explicit guidance on when to use this tool vs alternatives. No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect mounted filesystems and mount options.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only says 'inspect' without confirming it is read-only, disclosing permissions, or describing any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 5 words, with no filler or redundant information. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple inspection tool with no parameters or output schema, the description adequately conveys purpose but does not elaborate on the returned information or typical use cases, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema coverage is 100%. The description does not add parameter information, but none is needed. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'inspect' and the resource 'mounted filesystems and mount options', making the tool's purpose specific and distinct from sibling tools like networking or DHCP tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. While the purpose is clear, there is no explicit direction on context or exclusion of other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch LAN, WAN, and routing overview details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description is minimal. It implies a read operation but lacks details on authorization, side effects, or output structure. For a simple fetch tool, this is adequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that effectively communicates the tool's function without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a reasonable high-level overview of what is fetched. While more detail could be added, the simplicity of the tool (no parameters) makes this adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters (0 params) and full schema coverage (empty schema), the description adds value by specifying the scope (LAN, WAN, routing). Baseline for 0 params is 4, and the description meets it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it fetches LAN, WAN, and routing overview details, making the tool's purpose clear and distinguishing it from sibling tools like asuswrt_lan_details or asuswrt_wan_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 more specific alternatives. The description does not include any context about use cases or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect listening TCP/UDP sockets reported by netstat.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only inspection operation but provides no additional behavioral context beyond the basic purpose. With no annotations, the description should offer more details like permissions or side effects, though the tool is simple.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 8 words, starting with the verb, no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description sufficiently explains the tool's purpose. However, it could hint at the output format (e.g., list of port/state) to better aid an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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%. The description adds no param-specific meaning but is not required to. Following the baseline rule for 0 parameters, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'inspect' and identifies a clear resource 'listening TCP/UDP sockets reported by netstat', distinguishing it from sibling tools that deal with other network aspects like DHCP, ARP, or firewall. No tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like asuswrt_network_overview or asuswrt_port_forwarding. No context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or manage AsusWRT parental access rules.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| mac | No | ||
| name | No | ||
| confirm | No | ||
| dry_run | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'list or manage,' omitting crucial details such as whether changes are immediate, require confirmation, or are reversible. Destructive actions like 'remove' lack warnings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified. While concise, it omits essential information, making it less valuable than a balanced, informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with no descriptions, no output schema, and no annotations, the description fails to provide a complete picture. It does not explain parameter usage, action behaviors, or return values, severely lacking completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to parameters like 'mac', 'name', 'confirm', or 'dry_run'. Even with intuitive names, the lack of explanation for 'confirm' and 'dry_run' harms usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List or manage AsusWRT parental access rules,' providing a specific verb and resource. It distinguishes from the sibling 'asuswrt_parental_block_all' by implying management of individual rules, but does not explicitly contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'asuswrt_parental_block_all' or other management tools. The description solely states the action without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Toggle parental-control block-all mode.
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | Yes | ||
| confirm | No | ||
| dry_run | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. 'Toggle' implies enabling or disabling, but it doesn't explain whether the mode is activated/deactivated permanently or temporarily, what the impact is (e.g., blocking all internet access), or the role of the `confirm` parameter as a safety mechanism. The description lacks critical context for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but at the expense of necessary detail. It is front-loaded but fails to earn its place by omitting essential information about parameters and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain parameters, return value, side effects, or any prerequisites. The agent cannot invoke this tool correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 provides no explanation for any of the three parameters (`enabled`, `confirm`, `dry_run`). The agent has no guidance on what values to pass or their effects, leading to potential misuse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Toggle') and the target resource ('parental-control block-all mode'), making it easy to understand the tool's function. However, it does not explicitly differentiate from the sibling tool `asuswrt_parental_access`, which might handle per-device controls, but the name itself distinguishes enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of preconditions, when not to use it, or comparison with related tools like `asuswrt_parental_access`. The agent has no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect block-device partitions reported by the router kernel.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only inspection ('inspect') but does not explicitly state that it has no side effects. With no annotations, the description carries the burden, and it is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is nearly complete. It could hint at the return format (e.g., list of partitions) but is otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to add meaning. A baseline of 4 is appropriate as the schema fully covers the input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('inspect'), the resource ('block-device partitions'), and the source ('reported by the router kernel'). It is specific and distinguishes this tool from sibling tools that deal with storage at a different level (e.g., mounts, usage).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives like asuswrt_mounts or asuswrt_storage_usage. The description does not provide context for when partition inspection is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect policy-routing rules reported by ip rule.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It states 'Inspect' implying read-only, but does not disclose any permissions, output format, or potential side effects, even though the tool has no parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that conveys the essential purpose without any extraneous words. Perfectly sized for a parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a simple inspect function, the description is minimally complete. However, it does not explain what 'ip rule' is or differentiate from related tools, leaving some context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (0 parameters), so baseline is 3. The description adds no parameter information, but none is needed as the tool accepts no arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Inspect' and identifies the resource as 'policy-routing rules reported by ip rule', making the purpose clear and distinct from siblings like asuswrt_route_table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives among the many sibling tools. The description implies a read operation but does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List, enable/disable, add, or remove port forwarding rules.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| name | No | ||
| ip | No | ||
| port | No | ||
| protocol | No | TCP | |
| port_external | No | ||
| ip_external | No | ||
| confirm | No | ||
| dry_run | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists actions but does not disclose behavioral traits like immediacy of changes, need for confirmation, or side effects. With no annotations, the description fails to provide adequate transparency for a tool with multiple mutating actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence is concise but not optimally structured; it lists actions without prioritizing the most common use case. The lack of detail makes it less useful despite brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no descriptions for parameters or return values, the tool is severely under-documented. The agent cannot know what fields are required for each action or what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; the description does not explain any of the 9 parameters. Even the enum values for action are listed in the schema but not elaborated in the description, leaving the meaning of fields like name, ip, port, etc., completely unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (list, enable/disable, add, remove) and resource (port forwarding rules). It is specific and distinguishes from sibling tools like asuswrt_open_ports or asuswrt_upnp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or when not to use it, leaving the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or disable a main Wi-Fi radio band.
| Name | Required | Description | Default |
|---|---|---|---|
| band | Yes | ||
| enabled | Yes | ||
| confirm | No | ||
| dry_run | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'enable or disable' without explaining side effects (e.g., whether it disconnects clients, requires admin access, or causes a restart). The confirm and dry_run parameters hint at caution but are not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks necessary detail. It could include parameter explanations without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters with no descriptions, the description is highly incomplete. The agent lacks information about return values, side effects, and parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. The four parameters (band, enabled, confirm, dry_run) are not explained; the agent cannot infer what confirm or dry_run do.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enables or disables a main Wi-Fi radio band, which is a specific verb and resource. It distinguishes from sibling tools that handle guest networks, overviews, or other configurations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like asuswrt_wireless_overview or asuswrt_guest_wifi. No context on prerequisites or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart an allowlisted AsusWRT service.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | ||
| confirm | No | ||
| dry_run | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only says 'restart' but does not disclose side effects, permission requirements, or what happens during the restart. The term 'allowlisted' is ambiguous without further context. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 5 words, achieving brevity. However, it sacrifices substance. It could be more informative without becoming verbose, so it scores average on conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that restarts a service (a potentially disruptive action), the description is extremely lacking. No output schema exists, no explanation of behavior on success/failure, and no elaboration on parameter usage. The description is not complete enough given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning to the three parameters. It does not explain what valid 'service' values are, nor the roles of 'confirm' and 'dry_run'. The description fails entirely to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'restart' and resource 'AsusWRT service'. It includes the qualifier 'allowlisted', which distinguishes it from generic service operations. However, it does not explicitly differentiate from siblings like 'asuswrt_service_processes' which might list services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No explanation of what 'allowlisted' means or under what conditions restarting is appropriate. The description lacks any when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect the router IPv4 route table.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description indicates read-only inspection but lacks details on output format or potential side effects (none expected).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise, and front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and simple inspection task, the description is fully adequate without needing output schema or additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Description adds no parameter info but none is needed. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Inspect the router IPv4 route table' with a specific verb and resource, distinguishing from sibling tools like ARP or health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives; usage is implied by the description but no exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect Samba/SMB status and related processes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only says 'Inspect' implying a non-destructive read, but fails to detail output format, side effects, or behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, no unnecessary words, front-loads key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status tool with no parameters and no output schema, the description is functional but could benefit from mentioning output characteristics or related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and schema coverage 100%, the description adds value by specifying the target resource (Samba/SMB status), which the schema does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Inspect) and the resource (Samba/SMB status and related processes), distinguishing it from sibling tools like asuswrt_ddns_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternative status tools or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List key allowlisted router processes and services.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only says 'List...' without disclosing any behavioral traits such as read-only nature, side effects, permissions, or rate limits. The tool likely only reads data, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the action and resource. There is no unnecessary information, and it is front-loaded with the verb 'List'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is mostly complete. However, the term 'key allowlisted' could be ambiguous, and more context about what qualifies as 'key' would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description does not need to add parameter meaning. The baseline score of 4 is appropriate as the description covers the tool's purpose without needing to explain inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'key allowlisted router processes and services,' which is a specific verb and resource. It distinguishes itself from sibling tools that list other entities like clients, capabilities, or ports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 or what context it is appropriate for. The description simply states what it does without any situational advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diagnose SSH TCP reachability, banner exchange, and authentication.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the three diagnostic aspects (TCP reachability, banner exchange, authentication) but does not elaborate on behavioral traits such as side effects, safety, or failure modes. Since there are no annotations, the description partially fulfills the transparency burden, but more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. Every word contributes to clarity, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description sufficiently covers the three diagnostic areas. It lacks return value details, but for a diagnostics tool with no input, the context is adequate to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is trivially 100%. The description adds value by explaining the purpose of the tool beyond the empty schema, confirming what the tool will test. For a parameterless tool, baseline is 4, and the description meets it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool diagnoses SSH TCP reachability, banner exchange, and authentication. It uses a specific verb ('diagnose') and resource ('SSH'), and it distinguishes itself from sibling tools that cover different aspects of ASUSWRT diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention prerequisites, typical scenarios, or exclusions. The agent must infer usage solely from the generic verb 'diagnose'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect storage/filesystem usage reported by the router.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It only says 'Inspect,' implying a read-only operation, but does not disclose whether authentication is needed, rate limits, or any side effects. The description is insufficient for an agent to understand the tool's behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and to the point. It is appropriately front-loaded. However, it could be slightly expanded to include basic return value context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should provide information about the return value (e.g., what data is reported, format). It does not, leaving the agent uncertain about the tool's output. The description is too minimal for a tool with no other structural cues.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty). As per scoring guidelines, no parameters gives a baseline of 4. The description adds no parameter information because there is none to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Inspect storage/filesystem usage reported by the router' clearly states the verb and resource. It is distinct from sibling tools like asuswrt_mounts or asuswrt_partitions, though it could be more specific about what aspect of usage (e.g., capacity, inodes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There are no context signals, examples, or mention of prerequisites. The agent must infer usage solely from the brief description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch router uptime, load, and memory statistics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only states what data is fetched, but fails to disclose any behavioral traits such as read-only nature, potential side effects, or prerequisites. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose without any unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool, the description is fairly complete. It covers the main purpose, though it could mention the output format or that it is a read-only operation. Given low complexity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%. The description is clear about what it does, and since there are no parameters, no additional explanation is needed. Baseline 3, but the clarity earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and specifies the resource as 'router uptime, load, and memory statistics.' It distinguishes this tool from many sibling tools that focus on specific subsystems (e.g., DHCP, DNS, WAN).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool over alternatives, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect timezone and NTP synchronization settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'inspect' implies a read-only, non-destructive operation, which is a behavioral trait. However, since no annotations are present, the description could more explicitly state that no modifications occur, and it fails to disclose any potential side effects or requirements (e.g., admin privileges).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of 8 words. It is front-loaded with the verb 'Inspect' and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema, read-only tool, the description adequately conveys the purpose. It could be enhanced by mentioning the expected return format or specific fields, but it is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters in the input schema, so the description cannot add parameter-level meaning. According to the scoring guidelines, a baseline of 4 is appropriate for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'inspect' and clearly identifies the resource as 'timezone and NTP synchronization settings'. It effectively distinguishes this tool from its many siblings, which focus on other router functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention any prerequisites, exclusions, or comparative scenarios among the numerous sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or disable UPnP.
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | Yes | ||
| confirm | No | ||
| dry_run | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions the basic toggle function. It does not disclose behavioral traits like dry_run simulation, confirm safeguards, or side effects of enabling/disabling UPnP (e.g., automatic port forwarding).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence) and front-loaded, which is good for quick scanning. However, it is too minimal to be genuinely helpful, sacrificing essential detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema, annotations, and parameter descriptions, the tool definition is incomplete. The description does not explain the behavior of confirm and dry_run, nor does it set expectations about return values or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description adds no meaning for any parameter. The 'enabled' role is vaguely implied by the description, but 'confirm' and 'dry_run' are completely unexplained, leaving the agent uncertain about their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enable or disable UPnP' clearly states the specific action (toggle) and resource (UPnP). It unambiguously indicates the tool's purpose and distinguishes it from sibling tools like asuswrt_upnp_status which merely query the status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as asuswrt_upnp_status for viewing state or asuswrt_port_forwarding for managing specific rules. It lacks context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect UPnP enablement and housekeeping settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description uses 'Inspect,' suggesting a read-only operation, but does not explicitly state behavioral traits such as side effects, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the key action and resource. Every word is meaningful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description is minimal. It covers the basic purpose but lacks details on what 'housekeeping settings' entail or what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema description coverage is 100%. The description does not add parameter semantics, but none are needed. Baseline applied as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Inspect UPnP enablement and housekeeping settings,' specifying the action (inspect) and the resource (UPnP settings). It distinguishes from siblings like asuswrt_upnp, which likely handles configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for inspection but does not explicitly state when to use this tool versus alternatives like asuswrt_upnp. No exclusions or context for when not to use it are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect USB/storage-related partitions, mounts, and filesystems.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description implies a read-only operation ('Inspect') but does not disclose any behavioral traits such as side effects, authentication requirements, or rate limits. The information is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose without any extraneous words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple inspection tool with no parameters and no output schema, the description is adequate. It covers the scope (USB/storage partitions, mounts, filesystems) without needing to elaborate further. However, it does not mention whether the output is aggregated or detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the input schema is fully documented (100% coverage). The description does not need to add parameter information; the baseline for 0-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'inspect' and specifies the resource as 'USB/storage-related partitions, mounts, and filesystems'. This clearly distinguishes it from sibling tools like 'asuswrt_mounts', 'asuswrt_partitions', and 'asuswrt_storage_usage', which focus on individual aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus its siblings ('asuswrt_mounts', 'asuswrt_partitions', etc.). There is no indication of when an overview is preferred over specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect configured VPN modes and related processes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. The verb 'inspect' implies a read operation, but no explicit statement of non-destructiveness, permissions, or side effects is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the key verb 'Inspect,' but could benefit from slightly more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify what the tool returns. It mentions 'VPN modes and related processes' but does not describe the format or content of the output, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description does not need to explain parameter semantics. The baseline score of 4 applies as the schema coverage is 100% with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates that the tool inspects VPN configurations and processes, but it does not differentiate from sibling tools like asuswrt_vpn_server, which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives; no lists of prerequisites or exclusions are provided, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or disable the OpenVPN server toggle.
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | Yes | ||
| confirm | No | ||
| dry_run | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must bear the full burden of transparency. It only states that the tool enables/disables the toggle, but fails to disclose side effects, required permissions, or what happens to the server state. Basic mutation behavior is implied, but no depth is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it very concise. However, it lacks any structure such as parameter explanations or usage notes. While it is front-loaded, it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no output schema or annotations, the description is severely incomplete. It does not explain the optional parameters (confirm, dry_run), nor does it describe expected outcomes or error conditions. This is insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description adds no meaning to the parameters. It does not explain what 'confirm' or 'dry_run' do, nor the implications of 'enabled' beyond the boolean toggle. The description adds no value over the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to enable or disable the OpenVPN server toggle. It specifies the exact action (enable/disable) and the resource (OpenVPN server toggle), distinguishing it from sibling tools like asuswrt_vpn_overview which provides status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus alternatives. The description does not mention any prerequisites, conditions, or when not to use it. Siblings like asuswrt_vpn_overview exist, but no differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect WAN protocol, IP, gateway, DNS, and interface details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description clearly indicates a read-only inspection operation ('Inspect'), implying no side effects. However, it could further specify that no state is modified, which is already clear from the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the action and key details. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and many sibling tools, the description is sufficiently complete for a simple inspection tool. It could briefly mention return value format, but the lack of output schema reduces burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description inherently satisfies parameter semantics; baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Inspect' and resource 'WAN details', listing concrete properties (protocol, IP, gateway, DNS, interface). This clearly distinguishes it from sibling tools like asuswrt_lan_details or asuswrt_network_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when WAN details are needed, but does not provide explicit guidance on when to use this tool over alternatives, nor does it mention any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect web admin ports and related web processes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. 'Inspect' implies read-only, but no details are given about potential side effects, permissions, or response behavior. This is insufficient for a tool with no structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of seven words, which is concise and front-loaded. It communicates the core purpose without verbosity, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description provides the basic purpose. However, it omits details about the output format or structure, which the agent might need to interpret results. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is complete. The description mentions the subject of inspection (ports and processes), which is consistent. Baseline score of 4 applies as per guidelines for no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Inspect web admin ports and related web processes,' which clearly identifies the verb and resource. However, it does not differentiate from the sibling tool 'asuswrt_admin_access,' which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'asuswrt_admin_access' or other inspection tools. The description lacks context on prerequisites or suitability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect wireless radios, SSIDs, and connected band counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation with 'inspect', but provides no further behavioral details. Since no annotations exist, the description carries the full burden, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise and front-loaded. However, it might be too brief, lacking detail for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description is minimal. It covers the tool's purpose but not return format, scope, or limitations. For a no-parameter tool, it is partially complete but lacks detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, baseline is 4. The description adds no parameter meaning, but the schema already covers all parameters trivially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects wireless radios, SSIDs, and connected band counts, using a specific verb and resource. It distinguishes itself from siblings like asuswrt_radio by focusing on an overview of multiple aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as asuswrt_radio or asuswrt_guest_wifi. There is no mention of context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0asuswrt_admin_accessasuswrt_arp_neighborsasuswrt_capabilitiesasuswrt_clientsasuswrt_config_snapshotasuswrt_conntrack_statusasuswrt_cron_jobsasuswrt_ddns_statusasuswrt_dhcp_configasuswrt_dhcp_leasesasuswrt_dhcp_reservationasuswrt_dhcp_serverasuswrt_dns_configasuswrt_guest_lan_accessasuswrt_guest_networksasuswrt_guest_wifiasuswrt_healthasuswrt_identityasuswrt_interface_statsasuswrt_ipv6_statusasuswrt_kernel_modulesasuswrt_lan_detailsasuswrt_mountsasuswrt_network_overviewasuswrt_open_portsasuswrt_parental_accessasuswrt_parental_block_allasuswrt_partitionsasuswrt_policy_routingasuswrt_port_forwardingasuswrt_radioasuswrt_restart_serviceasuswrt_route_tableasuswrt_samba_statusasuswrt_service_processesasuswrt_ssh_diagnosticsasuswrt_storage_usageasuswrt_system_statsasuswrt_time_syncasuswrt_upnpasuswrt_upnp_statusasuswrt_usb_overviewasuswrt_vpn_overviewasuswrt_vpn_serverasuswrt_wan_detailsasuswrt_web_adminasuswrt_wireless_overviewAll 47 tools have distinct names and clearly separated purposes, from inspecting specific subsystems (ARP, DNS, DHCP) to controlling actions (enable/disable, toggle). Even closely related tools like guest_networks, guest_wifi, and guest_lan_access target different aspects of guest Wi-Fi management.
Every tool follows the consistent pattern 'asuswrt_<noun_or_noun_verb>' with snake_case. The prefix unifies the set, and the suffixes are descriptive and predictable (e.g., _status, _config, _details, _enable, _disable).
47 tools is excessive for a single MCP server. While the domain of router management is broad, many tools are highly granular (separate tools for DHCP config, leases, reservations, and server), leading to bloat. The server would benefit from consolidation or splitting into sub-servers.
The tool set covers an extensive range of router features: network configuration, wireless, guest networks, VPN, port forwarding, parental controls, system health, and more. Minor gaps exist (e.g., no firmware update or QoS control), but the surface is comprehensive for routine monitoring and administration.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Gives AI agents a public IPv6 identity, hostname, port forwarding, web fetch, team mesh. Free tier.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/teefloo/asuswrt-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
