MikroTik MCP

Server Quality Checklist

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

Latest release: v0.14.10
Disambiguation3/5
With 174 tools, there is some overlap among log-related tools (e.g., get_logs, get_logs_by_severity, get_logs_by_topic, search_logs) and many legacy wireless tools are marked as unsupported, creating confusion. However, most resource families follow a clear CRUD pattern that helps distinguish them.
Naming Consistency4/5
The naming is predominantly verb_noun (e.g., list_filter_rules, update_nat_rule), which is consistent. Minor deviations exist: 'add' vs 'create' (add_ip_address vs create_dhcp_server) and a few noun_verb exceptions like backup_info and safe_mode_status.
Tool Count1/5
174 tools is far beyond a well-scoped set and includes legacy/unsupported functions that bloat the surface. The sheer number makes it difficult for an agent to find the right tool.
Completeness4/5
The toolset covers most major RouterOS subsystems (firewall, NAT, routing, DHCP, DNS, wireless, WireGuard, queues, users, logging, backups) with full CRUD and enable/disable operations. Minor gaps like PPPoE and bridge-specific management exist, but core workflows are supported.
Average 3.2/5 across 174 of 174 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 13 of 18 community issues answered or closed in the last 6 months
- 30 commits in the last 12 weeks
- Last stable release on August 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral information about what the tool does, side effects, permissions, or return behavior. Annotations include destructiveHint false but no readOnlyHint, and the description adds nothing beyond a compatibility warning. There is no contradiction with annotations, but no value added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than conciseness. The single sentence is a deprecation note and does not fulfill the tool description's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no param descriptions, no usage guidance, and only a legacy warning, the description is severely incomplete. The output schema exists but cannot compensate for the missing contextual information needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and no parameter descriptions are provided. The description does not mention interface_name, security_profile, or device, leaving the agent without any clarification on how to populate these arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states 'Legacy function - not supported in RouterOS v7.x' and does not specify what the tool actually does. It fails to identify the action (setting a wireless security profile) or the resource being acted upon. This is a deprecation notice, not a purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 or when to use an alternative. The note about v7.x implies the tool should not be used, but does not suggest what to use instead. No usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some context by noting the tool is legacy and unsupported in v7.x, which hints at potential failure or incompatibility. However, it does not disclose actual behavior, side effects, or error outcomes, leaving the agent without a clear picture of what happens when invoked. Annotations are minimal and do not cover this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
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 contains a single sentence that offers little actionable value. It is not well-structured for useful consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with two parameters and an output schema, the description is completely inadequate. It fails to explain what the tool does, what inputs mean, or what the output/behavior will be. The legacy/unsupported warning is the only context, but it is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contains no information about the parameters 'name' and 'device'. Schema description coverage is 0%, and the schema provides only basic type/required information. The description does not compensate at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description never states what the tool does. It only says 'Legacy function - not supported in RouterOS v7.x', which does not describe the action or resource involved. The name/title imply creation of a wireless security profile, but the description is vague and potentially misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool or when to choose alternatives. It mentions 'not supported' but does not explicitly say to avoid it or suggest a replacement, despite the presence of sibling tools like set_wireless_security_profile or list_wireless_security_profiles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds a vague warning that behavior differs across RouterOS versions; this is some behavioral context, but it does not explain how it differs, what to expect, or any side effects. It does not contradict the annotations, but its contribution 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.
Conciseness2/5
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 uses its one sentence to issue a vague warning instead of conveying useful purpose or usage details, so it fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description neither explains the tool's function nor mentions what it lists. Given the low complexity (1 optional parameter), the description could easily have clarified the resource being accessed, but it remains completely inadequate for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'device' is entirely undocumented in both the schema and the description. With 0% schema description coverage, the description provides no semantic meaning beyond the parameter's name, leaving the agent without guidance on accepted values or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does. It only warns that it is a 'Legacy function' and 'different in RouterOS v7.x', leaving the agent to infer the purpose from the name alone. It does not distinguish this tool from its siblings, such as list_wireless_security_profiles or get_wireless_registration_table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 or when to prefer alternatives. The 'Legacy function' label might imply less preferred, but it stops short of suggesting an alternative or specifying appropriate contexts, making the description unhelpful for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral caveat that the function is legacy and behaves differently in RouterOS v7.x, which goes beyond the annotations. However, it does not explain the nature of the differences or any side effects. Given annotations already mark destructiveHint and idempotentHint, this is some additional context but still limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but it is under-specified rather than concise. It fails to convey essential information and reads more like a placeholder warning than a useful tool description. No structure or front-loading of purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a destructive tool: it does not explain what the operation does, what the version differences are, or any prerequisites or consequences. The schema is minimal, and the description adds little to make the tool usable. The output schema exists but is not used to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (device, entry_id) with no descriptions, and schema description coverage is 0%. The description provides no parameter information, so the agent gets no help understanding the meaning or usage of these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description ('Legacy function - different in RouterOS v7.x') does not state what the tool does. It only provides a legacy/version warning, with no verb+resource. The tool name and title imply removal of a wireless access list entry, but the description itself is missing a purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives. The note about being different in RouterOS v7.x could hint at version-specific usage, but it does not explicitly say when to use or avoid this tool. The description offers no clear context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false, and the description adds no additional behavioral context. It does not explain whether updates are partial (only provided fields) or require existing group existence, nor does it disclose any side effects beyond the generic 'updates'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified and does not earn its place by adding value. It merely restates the tool name, making it more of a tautology than a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, a required name field, and an output schema, this description is severely incomplete. It fails to explain update semantics, parameter purpose, or any conditional behavior, leaving the agent with insufficient context to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about any of the 6 parameters. It does not explain the meaning of 'skin', 'policy', 'comment', or 'new_name', leaving the agent without any semantic guidance beyond field names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Updates a user group.' is essentially a direct restatement of the tool name and title, providing no additional detail on scope, fields, or behavior. It lacks any specific information that would help distinguish it from other update tools beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, prerequisites, or alternatives. The description is purely definitional and does not mention context such as the need to specify an existing group name or the availability of get_user_group/list_user_groups for verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only title and non-destructive flag, with no readOnlyHint or destructiveHint. The description adds no behavioral details such as what the function actually does, side effects, or compatibility issues beyond a vague version warning. It does not explain what 'different' means operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it under-specifies the tool. It is a single sentence that conveys a warning, not a functional explanation. Minimal length without informative content is not effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one undocumented parameter and no usage details, the description is severely inadequate. It does not explain how to invoke the tool, what the output schema contains, or how this legacy function differs in RouterOS v7.x. The presence of an output schema does not excuse the absence of input semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'device' parameter at all. The parameter's purpose, allowed values, and whether it is required remain completely unclear. The description adds zero semantic value beyond the bare schema name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Legacy function - different in RouterOS v7.x' does not state what the tool does (creating a wireless access list). It only warns about version differences, which is a vague caveat rather than a clear purpose. The tool name is the only indicator of purpose, making this nearly a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like list_wireless_access_list or create_wireless_security_profile. The description implies legacy usage but does not explain when it is appropriate or what to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds context about the tool being legacy and unsupported in v7.x, which is useful for setting expectations about compatibility. It does not describe other behaviors like return values or errors, but with annotations present, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is under-specified rather than appropriately concise. It lacks essential information about the tool's purpose and parameters, so it does not effectively earn its place. Proper conciseness should convey key facts in few words; here it omits the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and annotations, the description is extremely incomplete. It does not even state that the tool gets a wireless security profile, leaving the agent without a clear understanding of what the tool does or when to use it. The legacy note is the only contextual detail, which is insufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not mention the 'name' or 'device' parameters at all. The agent cannot determine what values to pass for these parameters from the description, making it impossible to invoke the tool correctly without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description fails to state that this tool retrieves a wireless security profile. It only provides a caveat that it is legacy and unsupported in RouterOS v7.x, which obscures the function's true purpose. The name gives some clue, but the description does not reinforce or clarify it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an exclusion by stating the tool is not supported in RouterOS v7.x, implying it should not be used on that version. However, it gives no guidance on when to use the tool or what alternative to use instead, so usage guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, idempotentHint=true) already convey safety, but the description adds nothing about behavior such as error handling, return format expectations, or defaults like active_only=true. It lacks any behavioral context beyond what annotations already state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it's under-specification rather than effective conciseness. It doesn't earn its place by adding value beyond the tool name; it's a tautological restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one sentence and no parameter explanation, the description is incomplete despite the presence of an output schema. It doesn't cover how to select a device, what 'routing table' means in this context, or how filtering parameters interact, leaving the agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any of the four parameters (device, table_name, active_only, protocol_filter). Parameter names are somewhat self-explanatory but not fully, and the description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets a specific routing table' clearly identifies the action (gets) and resource (routing table), but 'specific' is vague and it doesn't distinguish from sibling tools like get_route or list_routes. It's understandable but lacks specificity about scope or differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus get_route, list_routes, or other routing tools. No context about device selection, prerequisites, or scenarios where this tool is preferred. The description is a bare statement with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only destructiveHint=false and openWorldHint=false; the description adds no behavioral details such as whether the route replaces an existing default, requires safe mode, or checks gateway reachability. It simply restates the action with no side-effect disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is brief and front-loaded, but it is under-specified: for a tool with five parameters and no structural breakdown, this brevity does not count as effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, sibling route tools, and no parameter coverage in the description, the description is severely incomplete. It lacks usage guidance, parameter semantics, and behavioral context, even though an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions none of the five parameters (gateway, distance, check_gateway, device, comment). The agent receives no semantic explanation beyond parameter names, with no help for required gateway or check_gateway behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adds') and the target resource ('default route'), which distinguishes it from generic route tools like add_route. However, it doesn't elaborate on what constitutes a default route or explicitly mention alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance about when to use add_default_route versus add_route or add_blackhole_route, nor any prerequisites or conditions. The description only states the action, providing zero usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, which align with a check operation. However, the description adds no further behavioral context, such as how source or routing_mark affect the check, whether it validates connectivity, or what constitutes a successful path. The bar is lowered because of the annotations, but the description still contributes almost nothing beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It repeats language from the tool name ('route path', 'destination') and lacks the depth needed to be practical. This is not an example of efficient, information-dense writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, no parameter descriptions, and a sparse one-line description, the tool is not adequately described. Even though an output schema exists, the description fails to clarify what inputs are expected and what the check actually does, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only references 'destination' (the required parameter) but provides no explanation of optional parameters (device, source, routing_mark) or how they interact. This is a significant gap for a tool with four parameters, making it impossible for an agent to correctly set optional arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'checks' and specifies the resource 'route path' to a destination, which clearly conveys the core function. It does not explicitly differentiate from siblings like get_route or get_routing_table, but the operation is distinct enough. A minor deduction for lack of sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives such as get_route, list_routes, or get_routing_table. The description merely states what it does without providing context, exclusions, or recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate openWorldHint=false and destructiveHint=false, not read-only. The description discloses it is an add operation but provides no details on side effects, permissions, or behavior beyond the basic action. For a mutation 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.
Conciseness4/5
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 and easy to parse, but it is also minimal to the point of under-specification, which slightly lowers the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters and zero schema descriptions, the one-line description is grossly inadequate. It does not explain what a DNS regexp entry is, how parameters interrelate, or any operational context, leaving the agent without essential information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not mention any of the six parameters (ttl, device, regexp, address, comment, disabled). There is no compensation for the lack of schema descriptions, so parameter semantics are completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Adds') and identifies the resource ('DNS regexp entry'), clearly distinguishing it from siblings like add_dns_static. However, it lacks any additional scope or contrast that would elevate it to a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention contexts, prerequisites, or exclusions, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations (openWorldHint=false, destructiveHint=false). It does not disclose details like whether creation requires a device, whether duplicates are handled, or whether changes apply immediately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant wording. However, its extreme brevity limits usefulness for a tool with such a complex parameter schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters and no parameter descriptions, the description is grossly incomplete. It does not indicate how the various DNS record types (A, CNAME, MX, SRV, TXT) are selected or that 'name' is required. Prospective users would struggle to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 15 parameters. Fields like text, regexp, srv_*, and mx_* are ambiguous without additional detail, making correct invocation difficult.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Adds a static DNS entry,' specifying the verb and resource. It distinguishes from sibling tools like add_dns_regexp or disable_dns_static, which target different DNS operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as add_dns_regexp, update_dns_static, or list_dns_static. It lacks 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=false and openWorldHint=false, providing a basic safety profile. The description adds no further behavioral context, such as permissions required, whether the operation is reversible, or what happens if the user already exists. It simply states the action without disclosing additional traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence, which is easy to read. However, it essentially restates the tool's name and title ('Add User' vs 'add_user'), adding little information. It is not verbose but also not substantive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and exists among many user-related siblings, the description is too sparse to fully orient the agent. It does not mention return values (though an output schema exists), common use cases, or relationship to other user tools. The overall context is incomplete for effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no meaning for any of the 7 parameters. While names like 'name' and 'password' are self-explanatory, fields such as 'group', 'address', and 'disabled' rely entirely on the user's prior knowledge. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Adds a user to MikroTik device' clearly identifies the action (add) and the resource (user), making it easy to distinguish from sibling tools like update_user, remove_user, or list_users. It does not, however, specify the device context or parameters, which slightly limits precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or related tools for different user management operations. The description is purely definitional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe, non-destructive nature is captured. The description explains that the log cannot be cleared, which is the tool's behavior is to explain. However, the description does not reveal what the output is (likely an explanation string or boolean), nor does it disclose what happens if the device parameter is null. Since annotations cover the safety profile, the baseline is moderate; the description adds minimal behavioral context beyond the core explanation, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded. It states the core purpose clearly without any fluff. No unnecessary words. However, it is too short to provide the usage and parameter context that would make it more helpful, but for conciseness, it earns a 4 for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, an output schema, and annotations all available, but the description is minimal. It explains the limitation but doesn't tell the agent what to expect as output, how to specify the device, or why the tool exists (i.e., why not just call clear_logs on the router). Given the explanatory nature, the description should clarify that it's a no-op or query that returns a reason, which is missing. The output schema exists, so return format might be redundant, but the purpose context is insufficient. The tool is relatively simple, so a bit more description would make it complete; currently it's incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter 'device' with no description, and schema description coverage is 0%. The description does not mention the parameter at all. The parameter is likely a device identifier, but the tool description doesn't explain its role in the explanation. With 0% coverage and no description context, the tool fails to compensate, so the score is low. However, with only one param, the lack of detail is less harmful than multiple undocumented params, but still a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Explains why MikroTik's in-memory log cannot be cleared on demand.' It clearly identifies the resource (logs) and the limitation (cannot be cleared), but the verb 'Explains' suggests this tool provides an explanation, not an action. It is distinct from siblings like get_logs or export_logs but the purpose is not to perform an operation. The title 'Clear Logs' implies the action of clearing, which is contradicted by the description's explanatory nature. This vagueness in action leads to a score of 2 — not a tautology but not a clear action verb either.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. Sibling tools like get_logs, search_logs, and get_log_statistics exist, but the description doesn't mention them or contrast usage. The description implies it's for understanding the log-clearing limitation, but that context isn't fleshed out. No exclusions or when-not-to-use guidance is provided, so this is minimal guidance at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says it 'creates a configuration export file', implying a write/side-effect, but the annotations declare readOnlyHint=true and idempotentHint=true. This is a direct contradiction; creating a file on the device modifies filesystem state. The description fails to disclose behavioral traits beyond what annotations claim, and actively conflicts with them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It front-loads the key purpose and formats, earning its place despite being terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, 0% schema coverage, and no output description, the tool is under-specified for an agent to use correctly. The description provides minimal context about behavior, return values, or side effects, and does not compensate for the lack of parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with 8 parameters, and the description does not mention any parameters or their semantics. It only lists output formats, leaving the agent to guess what 'name', 'device', 'compact', 'verbose', 'export_type', 'file_format', and 'hide_sensitive' control.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a configuration export file with specific formats (rsc/json/xml) on the MikroTik device. It is specific about the resource and action, but does not explicitly differentiate from sibling tools like create_backup or export_section, though the format list provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as create_backup or export_section. The description only states what it does, leaving the agent to infer when it should be chosen from a large set of related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare idempotentHint=true and destructiveHint=false, so the safety profile is known, but the description adds no further behavioral context. It fails to mention effects on existing configurations, error conditions, or dependencies like requiring the queue to exist, making the description nearly a restatement of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, which is concise. However, it is under-specified and does little more than echo the tool name, so it is not a well-structured or informative description despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and output schema presence, the description should provide adequate context, but it is too sparse. It lacks any guidance on when to use the tool, what 'enabling' entails, or how it relates to other queue tools, making it insufficient for an agent to confidently select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'name' or 'device' parameters. The agent must infer that 'name' identifies the queue and 'device' is optional, with no elaboration beyond raw schema definitions. The description does not compensate for the missing parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enables a simple queue' clearly states the action (enables) and the resource (simple queue), which distinguishes it from tools enabling other resource types. However, it does not differentiate from sibling tools like enable_queue_tree or explain what 'simple queue' means, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives such as disable_simple_queue, create_simple_queue, or enable_queue_tree, nor does it mention any prerequisites or side conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false, but the description adds no additional behavioral context. It does not clarify effects like 'no-op if already enabled,' failure conditions, or that the interface must exist. Beyond the annotations, the description is silent, so the transparency burden is not met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing a single sentence with no fluff. However, its brevity borders on under-specification—it states the core action but omits any supporting details. While it is front-loaded, the sentence could have been extended with valuable context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and an output schema, the description is minimally adequate but incomplete. It does not explain parameter semantics, any state requirements, or the effect on a disabled vs. enabled interface. The presence of an output schema does not compensate for the lack of operational context needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters 'name' or 'device.' It does not clarify that 'name' likely refers to the wireless interface name or that 'device' may be needed in multi-device environments. The description completely fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Enables' and the resource 'wireless interface,' distinguishing it from similar tools like enable_interface (which is generic) and disable_wireless_interface. However, it does not explicitly contrast with these alternatives, though the resource type makes the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, situations where enabling is appropriate, or exclusions (e.g., when to use enable_interface instead). This leaves the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Gets', which aligns with the readOnlyHint annotation, but it adds no behavioral context beyond what annotations already declare. It does not disclose what statistics are included, whether the operation is safe, or any performance implications. With annotations covering the read-only and idempotent nature, the description adds minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, which is concise. However, it is under-specified and lacks necessary context, making it less effective than a description that balances brevity with clarity. It is not overlong but does not earn a higher score due to its minimalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema, the description could be relatively simple. However, it omits guidance on the device parameter and usage scenarios, leaving a significant gap. The output schema may describe return format, but the description still fails to provide sufficient context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'device' with 0% description coverage. The description does not explain what 'device' refers to (e.g., target device identifier, hostname) or how it affects the operation. Since the schema provides no meaningful details and the description fails to compensate, the agent is left without essential parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets DNS cache statistics' uses a specific verb and resource, clearly indicating it retrieves statistical data about the DNS cache. It is distinct from sibling tools like get_dns_cache (which likely returns the cache contents) and get_dns_settings, though it does not explicitly contrast itself. Overall, the purpose is clear and somewhat differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool over alternatives, any prerequisites, or specific scenarios. Sibling tools such as get_dns_cache or flush_dns_cache exist, but the description offers no comparison or contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint and idempotentHint, but the description adds no further context about the nature of removal—whether it is permanent, whether it affects active sessions, or whether special permissions are required. It merely restates the operation without enriching the behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, a single sentence with no wasted words. However, it is so terse that it borders on under-specification rather than efficient communication, missing opportunities to add essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with two parameters and no meaningful schema descriptions, the description is insufficiently complete. It does not explain the consequences of removal, what the 'device' parameter does, or whether the operation is scoped to a particular device. The annotations and schema leave too many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate. The description does not explain what 'name' refers to (username, ID, etc.) or what the optional 'device' parameter controls, leaving both parameters ambiguous and underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Removes a user' clearly states the action (remove) and the resource (user), making the tool's basic purpose unambiguous. However, it does not differentiate this from sibling tools like disable_user or disconnect_user, which also affect users in different ways.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as disable_user, disconnect_user, or even update_user. There is no mention of prerequisites, side effects, or whether removal is permanent versus reversible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral information beyond the verb 'updates.' The annotations already declare idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered, but the description adds no additional context about partial update semantics, the requirement that the user exists, or consequences of omitting optional fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-specified for a tool with 8 parameters. It essentially restates the tool name and offers no additional information, so it does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters and a sparse schema, the description is far too minimal. The presence of an output schema mitigates the need to explain return values, but the description still fails to provide any usage context, such as which fields are updatable or how the operation behaves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 8 parameters with 0% description coverage, and the tool description does not discuss any parameters. The agent must infer meaning solely from parameter names and types, which is insufficient for fields like 'device', 'address', and 'new_name'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (updates) and the resource (a user), distinguishing it from creation, retrieval, or deletion tools. However, it is terse and doesn't elaborate on what specific user properties can be modified, though the schema enumerates them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as add_user, get_user, remove_user, or update_user_group. The description is a single sentence with no context for prerequisites, exclusions, or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=false, which indicates the operation is non-destructive, but readOnlyHint is absent. The description adds no behavioral context beyond the action itself, such as potential storage impact, encryption defaults, or whether existing backups are overwritten.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, efficient and front-loaded. However, it is minimalistic and omits useful context, though this is more a completeness issue than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks any usage context or parameter guidance. With 5 parameters and security-relevant options, the description is insufficient for an agent to invoke the tool correctly, especially without sibling differentiation or behavioral notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not mention any parameters. Parameters like 'dont_encrypt' and 'include_password' could have important security implications, yet no explanation is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a system backup on the MikroTik device, which is a specific verb+resource. It is clear how 'create_backup' differs from sibling tools like 'create_export' or 'restore_backup', though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_export or backup_info. There is no mention of prerequisites, contexts, or exclusions, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate idempotentHint=true and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond the redundant phrase 'Disables a queue tree' — it does not mention effects on traffic, reversibility, or any prerequisites, leaving the agent without additional useful information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it merely restates the tool name. This is under-specification rather than effective conciseness, as it adds no new information to help the agent understand the tool's behavior or parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description is incomplete. It does not explain the role of the 'device' parameter, any prerequisites, or the expected outcome beyond disabling. While an output schema exists, the lack of usage context and parameter semantics leaves the description inadequate for an agent to fully understand the tool's invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter-level detail. It does not even state that the queue tree is identified by 'name' or that 'device' is optional. The description completely fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Disables') and the resource ('a queue tree'), making it distinct from sibling tools like enable_queue_tree and remove_queue_tree. It is a specific verb+resource combination that leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is for temporarily disabling without removing the queue tree, nor does it contrast with enable_queue_tree or remove_queue_tree.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool idempotent and non-destructive. However, the description adds no additional behavioral context, such as whether disabling terminates active sessions or requires admin privileges. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler words. It is appropriately sized but extremely minimal, offering only basic information beyond the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description omits key context: what 'disable' implies for user access, whether existing sessions are affected, and the role of the optional 'device' parameter. The output schema reduces the need to describe returns, but other context is still lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fails to explain the 'name' and 'device' parameters. It provides no compensation for the missing parameter documentation, leaving agents to guess based on parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Disables' and the resource 'a user', making the purpose evident. While it doesn't explicitly contrast sibling tools like remove_user or disconnect_user, the verb choice distinguishes it sufficiently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It lacks any mention of prerequisites, exclusions, or related tools, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, and the description adds no behavioral context beyond saying 'on the MikroTik device.' It does not disclose return format, pagination, or filter behavior, so it provides minimal extra transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise but under-specified, which prevents a perfect score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four optional filter parameters and no parameter descriptions, the description is incomplete for a list tool. It does not explain how filters work or how the response is structured (though an output schema exists). The description is too weak to fully guide an agent in selecting and using this tool among many IP pool-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any of the four parameters (device, name_filter, include_used, ranges_filter). The parameter names are somewhat self-explanatory, but the description itself adds no parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Lists IP pools' with a specific resource and device context. It is a clear, specific verb+resource statement, but it does not explicitly differentiate from sibling tools like get_ip_pool or list_ip_pool_used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, and the filter parameters (name_filter, include_used, ranges_filter) are not explained. There is no mention of exclusions or alternative tools for more specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds no additional behavioral context beyond the basic read operation. It does not disclose whether disabled interfaces are included, how many results are returned, or any filtering defaults. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words, which makes it front-loaded and easy to parse. However, its brevity omits valuable context that could help an agent make an informed decision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return-value details are covered. However, the description omits any mention of the optional filters (name_filter, running_only, disabled_only) or the device parameter, leaving an incomplete picture for the agent, especially when multiple optional parameters are available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters with 0% description coverage, and the description does not mention any of them. Parameter names like name_filter, running_only, and disabled_only are somewhat inferable, but the meaning of device=null and the relationship between running_only and disabled_only are left entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lists') and the resource ('WireGuard interfaces') on the MikroTik device, making it distinct from sibling tools like list_interfaces or get_wireguard_interface. However, it does not explicitly mention whether it lists all interfaces or if any default scoping applies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_wireguard_interface or list_interfaces. There are no exclusions, prerequisites, or typical use-case scenarios described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and idempotentHint, and the description adds no additional behavioral context. It does not mention side effects, permanence, or any special conditions, so it contributes nothing beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. It is front-loaded and easy to parse, though it could be expanded with useful details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, a required entry_id, and an optional device, the description is under-specified. It lacks information about permanent deletion, how the device parameter affects operation, and any comparison with non-destructive alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters at all. It fails to clarify what entry_id refers to or how to obtain it, nor does it discuss the optional device parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Removes') and a clear resource ('static DNS entry'), which distinguishes it from related tools like disable_dns_static or update_dns_static. It is concise and unambiguous, though it could explicitly mention permanent deletion to further clarify the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as disable_dns_static. No context is provided about prerequisites, use cases, or why one would choose removal over disabling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply restates the action without adding behavioral context beyond annotations. Annotations already mark it destructive and idempotent. The description doesn't disclose irreversibility, permissions, or effects on user access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no wasted words. It is appropriately concise for a simple action, though it could be more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation and existing annotations, the description is under-specified. It lacks context about finding key_id, whether the removal affects active sessions, or any prerequisites. The output schema exists, so return values aren't needed, but the description is still minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no property descriptions (0% coverage), and the description does not explain key_id or device. The agent must infer meaning from property names alone. The description adds no parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Removes') and resource ('SSH key'), clearly identifying the action. It aligns with the tool name and distinguishes from sibling tools like list_user_ssh_keys and set_user_ssh_keys. However, it lacks explicit scoping (whose key, from where), so not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention using list_user_ssh_keys to find key_id or that this is the removal counterpart to set_user_ssh_keys. No context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only reiterates the action in the tool name; it does not disclose whether existing SSH keys are replaced, whether the user must exist, or any side effects. Annotations are minimal (non-destructive, closed-world) but don't cover overwriting or key format requirements, so the description carries little value on behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, which is appropriately concise. However, its brevity comes at the cost of essential details, so it is not maximally useful; it is simply short rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that mutates SSH keys, the description is incomplete. It doesn't state the operation's semantics (add/overwrite), prerequisites, or relationship to related tools. The presence of an output schema helps with return values, but the set behavior is ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the tool description does not explain any of the three parameters. The meaning of 'key_file' (path vs. key content), 'device' (target device), and 'username' (scope) is not defined, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Sets') and identifies the resource ('SSH keys') and scope ('for a specific user'), which clearly distinguishes it from sibling tools like list_user_ssh_keys and remove_user_ssh_key. However, it doesn't clarify whether the operation adds a key or replaces all existing keys, limiting the precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, prerequisites, or alternatives. There is no mention of whether it should be used with list/remove operations or special conditions, so the agent receives no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare openWorldHint false and destructiveHint false, while the description adds no behavioral context beyond the verb 'Adds'. It does not mention side effects, idempotency, duplicate handling, or validation behavior, so the agent cannot anticipate what happens during configuration changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It is concise and easy to parse, though it sacrifices depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given seven parameters and zero schema descriptions, the one-line description is insufficient for confident use. It fails to cover address format, optional parameter behaviors, prerequisites (e.g., interface existence), or interaction with existing addresses, even though an output schema exists to clarify return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only clarifies that 'address' is an IP address and 'interface' is the target, which is minimal. Optional parameters like network, broadcast, and disabled receive no explanation, leaving their semantics to inference from property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Adds') and resource ('IP address') with a clear target ('to an interface on the MikroTik device'). It clearly conveys the main operation, but it does not explicitly distinguish from sibling add_ipv6_address, relying on the tool name for that differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as add_ipv6_address, nor any prerequisites or exclusions. It only states what the tool does, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=false, so the agent knows this is not destructive. However, the description adds no additional behavioral context, such as idempotency, conflicts with existing networks, or device requirements. It merely restates the creation action without deeper disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It efficiently communicates the core action but omits helpful detail, making it concise yet slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and no schema descriptions, the description is insufficient for an agent to correctly configure all options. It also doesn't clarify the relationship with related DHCP tools or mention the output schema, leaving the full context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate but only mentions 'gateway, DNS, domain' as examples. It fails to explain the remaining seven parameters (netmask, dhcp_option, ntp_servers, wins_servers, comment, device, etc.) or clarify required fields, leaving significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'creates' and identifies the resource as 'DHCP network configuration' with examples (gateway, DNS, domain), making the purpose clear. It doesn't explicitly differentiate from sibling tools like create_dhcp_server or create_dhcp_pool, but the resource type is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as create_dhcp_server or create_dhcp_pool. The description does not mention prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=false and openWorldHint=false, but the description adds no side-effect context such as what happens if an interface with the same name exists, or whether a private key is auto-generated. It only restates the basic creation behavior without additional behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, readable sentence that clearly states the core action. It is concise and front-loaded, though it omits useful context that could be included without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (7 parameters, required name, no parameter docs), the description is far from sufficient for correct invocation. It lacks any explanation of parameter meanings, preconditions, or behavioral details, making it inadequate for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero descriptions for its 7 parameters, and the description explains none of them. Meaningful semantics for parameters like listen_port, private_key, and mtu are absent, forcing the agent to infer or guess their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Creates'), the resource ('WireGuard interface'), and the scope ('on the MikroTik device'). This distinguishes it from sibling creation tools for other resources such as create_wireless_access_list or create_vlan_interface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus updating, removing, or enabling an existing WireGuard interface. The description states the function but does not provide alternatives, preconditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as destructive and idempotent. The description adds no additional behavioral context such as consequences for the user, irreversibility, or impact on the network. It does not contradict the annotations, but it also doesn't enrich them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler words; every word carries meaning. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While simple, the tool is destructive and has an ambiguous optional 'device' parameter. The description provides no information on prerequisites (e.g., only active sessions), side effects, or what device refers to, leaving the agent under-informed for a safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), and the description makes no mention of user_id or device. This leaves the agent without meaning beyond the field titles, particularly for the optional 'device' parameter, which is unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('disconnects') and identifies the resource ('active user session'). It distinguishes this tool from user management siblings like disable_user or remove_user, though the session type (e.g., hotspot, PPPoE) is not specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives; the only hint is that it applies to an 'active' session, implying a prerequisite of an active session. It does not mention how to identify the user or what alternative exists for non-active sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include idempotentHint=true and destructiveHint=false, but the description adds no additional behavioral context, such as whether the rule must exist or the effect of enabling a disabled rule. It provides no value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no waste. It is front-loaded and appropriately sized for the simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple operation, the description is minimal to the point of being bare. It lacks any context about prerequisites, effects, or usage scenarios. The annotations and schema provide some completeness, but the description itself is insufficient for an agent to distinguish when to invoke this tool and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about rule_id or device parameters. An agent must rely entirely on the schema, which only has titles and types, no semantic explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: enabling a NAT rule. It is a specific verb+resource statement that distinguishes from siblings like disable_nat_rule and update_nat_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool, prerequisites, or alternatives. It simply restates the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations declaring idempotentHint=true and destructiveHint=false, the safety profile is already covered. The description adds no additional behavioral context—no mention of side effects, failure modes, or effects on an already-enabled queue tree. It contributes nothing beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no wasted words, but it is under-specified rather than appropriately concise. It omits critical parameter and usage information, so while it is brief, it fails to convey the necessary detail for effective use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description plus annotations and output schema provide a minimal picture, but the lack of parameter meaning and usage context makes it incomplete. The agent would not be able to confidently select or invoke this tool without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain either parameter. 'Enables a queue tree' does not clarify that 'name' is the required queue tree identifier or what 'device' refers to. With no parameter semantics provided, the agent has no way to correctly invoke the tool beyond guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enables a queue tree' uses a specific verb and resource, clearly distinguishing it from siblings like 'disable_queue_tree' and 'create_queue_tree'. It states exactly what the tool does with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'disable_queue_tree' or 'update_queue_tree'. It lacks any context about prerequisites, conditions, or exclusions, leaving the agent without direction on appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds minimal behavioral context beyond the word 'current', which implies reading live state. No additional details about what the configuration includes or any device-specific behavior are provided, so the description does not significantly extend beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words or repetition. It is appropriately sized for a simple getter tool, and it is front-loaded with the action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema, so the description does not need to explain return values. However, the description is too vague about what 'DNS configuration' covers and does not clarify the role of the optional 'device' parameter, leaving the agent without enough context to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the parameter 'device' has no description. The tool description also does not mention 'device' at all, leaving its meaning and optionality completely unexplained. This is a significant gap since the description should compensate for the lack of schema-level parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets') and the resource ('current DNS configuration'), which is specific enough to convey the tool's function. It does not explicitly differentiate from sibling tools like get_dns_static or get_dns_cache, but 'configuration' suggests a broader scope, making the purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, fallback options, or exclusions, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds no additional behavioral context such as limitations (e.g., log retention, device-specific constraints), side effects (none expected), or return behavior beyond what the output schema presumably covers. It does not contradict annotations, but it adds minimal behavioral transparency beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief main sentence followed by a bullet-point-style list for filter details. It is front-loaded with the purpose and avoids excessive fluff. It could be slightly more explicit about missing parameters, but the format is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, 0% schema description coverage, and numerous sibling tools, the description is incomplete. It fails to explain three parameters (device, print_as, prefix_filter) and does not provide guidance on when to use this tool vs. alternatives. The output schema exists, so return types are likely covered, but the description still leaves significant gaps for a complex network device tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description is the sole source for parameter meaning. It explains topics (comma-separated), time_filter (RouterOS duration), message_filter (case-sensitive regex), and limit (newest N). However, it completely ignores device, print_as, and prefix_filter, leaving these ambiguous. The partial coverage is not sufficient to fully clarify all parameters, especially for a tool with seven inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Gets') and resource ('logs from the MikroTik device') and mentions optional filters (topic, time, message). It is specific enough to understand the core function, but it does not explicitly differentiate from closely related siblings like get_logs_by_topic or get_logs_by_severity, which also deal with filtered log retrieval. Since there is no explicit distinction, it earns a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling log tools (e.g., search_logs, get_logs_by_topic, get_logs_by_severity, export_logs). It does not mention scenarios where this tool is preferred or when alternatives should be used. This leaves the agent without clear decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds no further behavioral context such as error handling, permission requirements, or what 'detailed information' includes, leaving the tool's behavior under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words and immediately conveys the core action. It is appropriately sized for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and strong annotations, the description lacks necessary context about parameter usage, when to choose this tool, and what 'detailed information' entails. It is essentially a tautology that does not fill the gaps left by the 0% parameter schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention either parameter. 'name' and 'device' are left unexplained; the description does not clarify that 'name' is the queue type identifier or what role 'device' plays, so it adds no semantic value beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a specific queue type, using a direct verb and resource. It distinguishes from list or create/update sibling tools by implying a targeted read operation, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_queue_types or get_queue_tree. The description implies usage for fetching details on a single queue type, but gives no context on prerequisites, selection criteria, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only and idempotent behavior. The description adds no additional behavioral context beyond the verb 'gets', which merely restates the annotations. It does not describe what the route cache contains, whether it returns raw or processed data, or any quirks like caching behavior. The description does not contradict annotations, but it also provides no extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. It contains no filler or redundant information, and its brevity is appropriate for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (which explains return values), the description is too sparse to give a complete picture. It does not explain what the route cache is, why an agent would query it, or what the 'device' parameter means. For a tool with sibling operations like flush_route_cache and get_route_statistics, the description leaves too much implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description does not mention the 'device' parameter at all. The agent is given no explanation of what 'device' means, whether it is required (it has a default of null), or how it affects the result. With only the parameter name as a hint, this is insufficient for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets the route cache' clearly states the action (gets) and the target resource (route cache). It distinguishes itself from siblings like flush_route_cache (different action) and get_routing_table (different resource), though it doesn't explicitly call out these distinctions. The purpose is unambiguous but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as flush_route_cache or get_route_statistics. There is no context about use cases, prerequisites, or conditions that would make this the appropriate choice. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, which convey the safety profile. The description adds no additional behavioral context such as whether all rules are returned by default, whether filters are optional, or any pagination behavior. It merely restates the read-only nature already implied by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence with no filler or redundancy. It earns its place by stating the core purpose, though it is so terse that it misses opportunities to add helpful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters and no schema descriptions, a one-sentence description is grossly inadequate. The description does not mention the filtering capabilities, the fact that all parameters are optional, or how to narrow down results. It is not complete enough for an agent to effectively use this tool among many similarly named navigation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, with 10 parameters that have no descriptions in the schema. The tool description simply says 'Lists firewall filter rules' and makes no attempt to explain the purpose or combination of chain_filter, dynamic_only, action_filter, or the other parameters. The agent receives no compensation for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lists') and the resource ('firewall filter rules') on a specific device ('MikroTik device'). This distinguishes it from siblings like list_nat_rules and get_filter_rule, which operate on different resources or individual rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_filter_rule for a single rule or create_filter_rule for adding rules. It does not mention any prerequisites or exclusions, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the annotations (readOnlyHint and idempotentHint true) and does not contradict them. However, it offers no additional behavioral details—no mention of default operation, effect of optional filters, pagination, or ordering. An agent would need to infer any behavior beyond the simple list action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-phrased sentence that is front-loaded with the primary action. No redundant words or filler. It is appropriately concise for a list operation, although it sacrifices detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five optional filters and no parameter descriptions, the description is inadequate. The output schema may document return values, but the description does not indicate whether the tool returns all queue trees by default, how filters combine, or any constraints on the device parameter. This leaves significant gaps for an agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation of the five parameters. Parameter names like name_filter and parent_filter are somewhat self-explanatory, but the description does not clarify their permitted values or how invalid_only/disabled_only affect results, leaving the agent without semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action ('Lists') and a precise resource ('queue trees') on the MikroTik device. It distinguishes from siblings by using a plural form and the verb 'list', though it does not explicitly reference alternative tools. The main gap is the lack of mention that it returns multiple items or supports filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to choose this tool over get_queue_tree, list_simple_queues, or other list operations, nor does it mention the filter parameters that shape results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds no behavioral context beyond stating the obvious list operation. It does not mention filtering capabilities, response scope, or any limitations, providing no extra transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It clearly states the action and target resource, making it highly concise and well-structured for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 filter parameters and many related sibling tools, but the description provides no operational context about filtering, device targeting, or how this differs from get_routing_table. The output schema covers return values, but the description is insufficient for an agent to understand the full scope and appropriate use of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any of the 9 parameters (dst_filter, active_only, static_only, etc.), and schema description coverage is 0%. With such low coverage, the description must compensate by explaining parameter meaning, but it provides none, making the parameters no clearer than their property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Lists' and identifies the resource as 'routes in MikroTik routing table', making the core function clear. However, it does not distinguish itself from sibling tools like get_routing_table or get_route, which could also be about retrieving route information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_routing_table, get_route, or add_route. No exclusions, prerequisites, or context for the filter parameters are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, making the safety profile clear. However, the description adds no extra behavioral context like filtering options, output format, or pagination, providing minimal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is concise and to the point, though it reflects under-specification rather than deliberate brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the output schema and annotations, the description lacks critical usage context, such as when to use it versus get_active_users or get_user. The optional filters are only implied by the schema, leaving the tool under-specified for an agent to select correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has five parameters with descriptive titles and defaults, but the description gives no explanation of any of them. With schema description coverage at 0%, the description was expected to compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists users on a MikroTik device using a specific verb and resource. It does not explicitly differentiate from sibling tools like get_active_users or get_user, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_user, get_active_users, or list_user_groups. The description offers no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, non-mutating operation. The description adds only the 'on the MikroTik device' scoping, which is trivial and already implied by the tool name. It does not disclose filtering behavior, return formats, or empty-list semantics, but the existing annotations cover the most critical safety aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is appropriately sized for a simple list operation. However, it is so brief that it borderlines on under-specification, though it does not contain irrelevant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and read-only annotations, the tool has four optional parameters and numerous sibling tools. The description does not explain the filtering capabilities, when to use it over 'list_interfaces', or any edge cases. The single-sentence description is insufficient for a tool with this complexity and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the four parameters (device, name_filter, running_only, disabled_only). The parameter names and defaults are somewhat self-explanatory, but the description provides no additional meaning, leaving the agent without guidance on how to use these filters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a clear verb ('Lists') and resource ('wireless interfaces') with a scope ('on the MikroTik device'). It is specific enough to understand the tool's basic function, but it does not explicitly differentiate from the sibling 'list_interfaces' tool, which could also list wireless interfaces as part of all interfaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as 'list_interfaces' or 'get_wireless_interface'. It does not mention any exclusions or prerequisites. Given the large number of sibling tools, this absence of usage context is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action 'Sets' without disclosing whether existing DNS settings are replaced, if changes apply immediately, or if specific privileges are required. Annotations are minimal (destructiveHint false, openWorldHint false) and the description adds no additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded with the verb and object, making it easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters, sparse annotations, and no usage guidance. The one-line description is inadequate for an agent to understand important nuances like the effect on existing DNS servers, the meaning of DoH settings, or how to choose appropriate parameter combinations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 10 parameters and 0% schema description coverage, the description must compensate but does not. It provides no explanation of what each parameter does, how they interact, or which are required beyond the schema's basic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Sets' and identifies the resource as 'DNS server configuration'. It clearly distinguishes from sibling tools like get_dns_settings (read-only) and add_dns_static (static entries). However, it could be more explicit about which aspects of DNS server configuration are modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_dns_settings or flush_dns_cache. It does not mention prerequisites, exclusions, or optimal use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds no behavioral context beyond the name, but it does not contradict the annotations either. It is neutral but minimally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but it is not overly verbose. However, it is under-specified for a tool with four parameters and several sibling DNS tools. The sentence is concise but fails to earn its place by providing no usage or parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, an output schema, and siblings, the description is far too minimal. It does not explain what the DNS test does, how parameters affect the test, or when to use it. The output schema covers return values, but the description misses critical context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters (name, type, device, server). With zero coverage and no description compensation, the agent cannot understand parameter semantics beyond the raw schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Tests a DNS query.' This clearly indicates the tool performs a DNS test. However, it does not distinguish this from sibling DNS tools like get_dns_cache or flush_dns_cache, though the verb 'test' implies a probe rather than a retrieval or mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It simply states what it does without mentioning appropriate contexts, prerequisites, or exclusions. The agent is left without direction on when to choose test_dns_query over other DNS-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply repeats the update action without disclosing important behavior like whether the update merges with existing fields or replaces them. Annotations already provide idempotent and non-destructive hints, but the description adds no extra operational context, such as partial update semantics or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence with no redundant words, making it concise and front-loaded. However, it is so minimal that it borders on under-specification, though each word does earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's substantial complexity (16 parameters, multiple DNS record types), a one-sentence description is grossly insufficient. It does not explain how to construct updates, which fields apply to which record types, or how the tool behaves with missing optional fields. The output schema exists, but the agent still lacks essential operational knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 16 parameters with 0% description coverage, and the description does not compensate by explaining any of them. Fields like cname, text, device, regexp, and the SRV/MX parameters are left entirely undefined, providing no semantic help to the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Updates a static DNS entry' with a clear verb and resource, distinctly different from siblings like add, remove, enable, and disable. Though minimal, it unambiguously identifies the action and object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as add_dns_static, remove_dns_static, or enable_dns_static. There is no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the destructiveHint annotation. It doesn't disclose whether existing firewall rules are overwritten, whether safe mode is recommended, or what specific rules are applied. For a destructive operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and free of filler. It earns its place by stating the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a destructive batch operation with a single optional parameter, the description lacks critical context such as the specific security rules included, potential side effects on existing rules, and usage guidance. The output schema exists but does not compensate for missing behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the 'device' parameter, and the description does not mention or explain it. The parameter name is self-explanatory, but no behavior is described for the default null value or how the device is selected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates') and the resource ('basic firewall setup') on a MikroTik device. It is specific enough to distinguish from other firewall-related tools like create_filter_rule, though it doesn't explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting up a baseline firewall but provides no explicit guidance on when to use it versus creating individual rules, nor any prerequisites or exclusions. This is similar to the update_drive example where impled usage alone earned a 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the agent knows the operation is safe and repeatable. However, the description adds no further behavioral context beyond restating the name, such as what enabling actually changes, whether the device parameter is required, or how it affects traffic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words, making it easy to parse. It is well-structured for its brevity, though it lacks semantic depth that would make it more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and an output schema exists, the description omits essential contextual information about parameter meanings and usage scenarios. An agent cannot confidently invoke this tool correctly without additional assumptions about what 'name' and 'device' refer to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no meaning for the required 'name' parameter or the optional 'device' parameter. The agent only has schema titles 'Name' and 'Device,' which are insufficient to know what values to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enables') and the specific resource ('a WireGuard interface'), distinguishing it from sibling tools like enable_wireless_interface or enable_wireguard_peer. The verb and resource are concrete and the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_wireguard_interface, disable_wireguard_interface, or enable_interface. There is no mention of prerequisites like the interface needing to already exist or be disabled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide. While annotations indicate readOnlyHint and idempotentHint, the description doesn't mention what file format is used, where the file is saved, whether it overwrites existing files, or how the file can be retrieved. It essentially repeats the tool's name without elaborating on side effects or operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It is appropriately sized for a simple tool and front-loads the key action. However, it sacrifices too much substance for brevity, so it isn't a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this tool exports to a file and has sibling tools like download_file and export_section, the description lacks essential context about the export workflow, file handling, and relationship to other operations. The presence of an output schema mitigates the need to describe return values, but the description still fails to cover the tool's role in the broader file export/transfer process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (device and filename) with zero description coverage. The description does not mention either parameter, leaving their meaning and usage entirely ambiguous. For example, it is unclear whether 'filename' refers to the output file path or an input configuration file, and what 'device' specifies. The description fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (exports), the resource (DNS configuration), and the target (to a file). This specific verb+resource+target structure distinguishes it from sibling tools like export_section or export_user_config, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as export_section, create_export, or download_file. The description simply states what it does without any context on prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds no behavioral context beyond the verb 'removes.' It does not disclose potential effects on users assigned to the group, failure modes, or reversibility, missing an opportunity to add value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy. It is front-loaded and easy to parse, though it is sparse enough that the conciseness comes at the cost of missing operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a simple schema and output schema, the description is insufficiently complete for a destructive operation. It omits guidance on the device parameter, prerequisites, error behavior, and consequences, making the agent reliant on external knowledge or trial-and-error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for explaining parameters. It does not mention 'name' or 'device' at all, leaving the agent to guess the meaning of the optional device parameter and how name should be formatted or resolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Removes a user group,' which is a specific verb+resource combination. It clearly distinguishes this tool from siblings like remove_user and remove_user_ssh_key by naming the exact resource being acted upon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or conditions for removal. It does not mention checking for existing user groups, handling dependencies, or using get_user_group/list_user_groups first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already declare (destructiveHint, idempotentHint). It does not mention irreversibility, potential side effects on dependent configurations, or any required permissions. Since it provides no extra value beyond the annotations, the score is low.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core action. It is front-loaded and free of fluff, earning its place. However, it is perhaps too minimal, but conciseness is not heavily penalized for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with two parameters, the description is incomplete. It doesn't explain the device parameter, what happens if the interface doesn't exist, or whether the operation is reversible. The output schema exists, but the description should still provide more operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain any parameters. It fails to clarify what 'name' refers to (e.g., interface name or VLAN ID) and what the optional 'device' parameter does. With no compensation from the description, parameter semantics are almost entirely unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'removes' and the specific resource 'VLAN interface', which distinguishes it from sibling tools like create_vlan_interface or update_vlan_interface. It leaves no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when a VLAN interface should be removed or if there are prerequisites like the interface being disabled. It lacks any context about usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include destructiveHint=false and openWorldHint=false, providing minimal safety context. The description adds parameter constraints (CIDR format, distance range) but does not disclose behavioral effects such as that a blackhole route discards traffic, persists, or requires administrative privileges. This is a significant transparency gap for a network-configuring tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line plus two bullet-like notes. It is front-loaded with the purpose and each note serves a direct purpose. No filler or redundancy, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is very short and does not explain the effect of a blackhole route, when to use it, or what the output contains (output schema exists but is not shown). Given the schema coverage is 0% and context is sparse, the description is incomplete for an agent to fully understand the tool's operation and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds useful semantics for dst_address (CIDR example '10.0.0.0/8') and distance (range 1-255), but does not explain 'device' or 'comment' parameters. The notes partially aid parameter understanding but not completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Adds a blackhole route', which is a specific verb and resource. It is distinct from sibling tools like add_route and add_default_route because 'blackhole' is uniquely named, though the description does not explicitly contrast it with these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as add_route or add_default_route. It does not mention conditions, prerequisites, or context where a blackhole route is appropriate, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=false and openWorldHint=false. The description adds some behavioral details via parameter notes: check_gateway can be 'ping' or 'arp', and distance 1-255 with lower value meaning higher priority. These influence how the route behaves, but the description does not disclose other consequences like whether an existing route is overwritten.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is compact: one sentence plus three bullet notes. It is front-loaded with the action and uses a clear 'Notes:' section. Given the tool's 12 parameters, it is under-specified but still concise and free of redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks critical context for a complex 12-parameter routing operation. It covers only 3 parameters, omits usage alternatives, and does not explain the effect of parameters like pref_src, target_scope, or routing_mark. An agent would struggle to construct a correct call for non-basic routes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 12 parameters with zero descriptions, so the description is the only source. It explains dst_address CIDR format, check_gateway accepted values, and distance range/priority. However, 9 other parameters (e.g., pref_src, target_scope, scope, routing_mark, vrf_interface) receive no explanation, leaving significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Adds a route to the routing table,' clearly stating the verb and resource. However, it does not differentiate from sibling tools like add_default_route or add_blackhole_route, which are more specific add operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use add_route versus the various route-related siblings. It does not mention prerequisites (e.g., gateway required) or exclusions (e.g., for default routes use add_default_route). The only usage context is implicit in the verb 'adds'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=false and openWorldHint=false, but the description adds no additional behavioral context. It does not describe side effects, permission requirements, behavior on duplicate names, or any other operational details. The description merely restates the action without elaborating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded and free of waste. It achieves maximum conciseness, though it does so by omitting necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema and annotations, the description is insufficient. A create operation with five parameters and no explanation of key concepts like 'policy' or 'device' leaves the agent without complete context. The tool is too minimal for effective use in a complex environment with numerous sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters like 'policy' and 'device,' but it provides none. The schema only lists parameter names and types; the description adds zero semantic meaning, leaving the agent without essential information about valid policy values or how device/skin/comment are used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Adds a user group.' clearly states the verb (adds) and the resource (user group), distinguishing it from sibling tools like get_user_group, update_user_group, and remove_user_group. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of related operations such as requiring a policy or device. The description implies usage only through the verb 'adds,' but offers no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the action itself. Annotations already indicate idempotentHint=true and destructiveHint=false, so the safety profile is covered, but the description does not introduce any additional context such as side effects, state changes, or operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the essential action. There is no clutter or redundant elaboration, making it efficiently scannable by the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having annotations and an output schema, the description is too minimal to be contextually complete. It does not explain the operational context (e.g., what 'disabled' means for a queue), when the operation is appropriate, or how the parameters relate to the action, leaving gaps that could cause misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining the purpose, format, or relationship of the 'name' and 'device' parameters. The agent receives no semantic guidance beyond the raw parameter names, which is insufficient for reliable invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Disables a simple queue' clearly names the specific action (disable) and the resource (simple queue), distinguishing it from sibling tools like enable_simple_queue and remove_simple_queue. It is a precise, resource-specific statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as enable_simple_queue or remove_simple_queue. No context, prerequisites, or exclusion conditions are provided, leaving the agent without direction on appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, but the description adds no behavioral context beyond the simple action. It does not explain consequences like disconnecting clients or persistent state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple nature of the tool, the description omits parameter semantics and usage context. An output schema exists, but the description does not compensate for the missing parameter explanations or usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the 'name' or 'device' parameters. It fails to clarify which parameter identifies the interface or how 'device' might scope the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Disables' and identifies the resource 'wireless interface'. This clearly distinguishes it from sibling tools like 'enable_wireless_interface' and 'remove_wireless_interface'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or when to prefer alternatives. It only states what it does, without context such as prerequisites, side effects, or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, yet the description says it 'exports logs to a .txt file on the MikroTik device', which is a write operation that creates or modifies a file on the device. This directly contradicts the read-only annotation, making the behavior ambiguous and potentially misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 17 words, front-loading the main verb 'Exports' immediately. Every clause contributes value (action, destination, optional filters), with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and an output schema, but the description lacks critical behavioral context: default filename behavior, overwrite semantics, file location on the device, and filter syntax. It is not sufficiently complete for an agent to invoke correctly, and the annotation contradiction further undermines trust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It mentions 'optional topic and time filters', indirectly mapping to 'topics' and 'time_filter', but gives no details on the 'filename' or 'device' parameters, nor on filter formats or defaults. The description adds minimal meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (export), the resource (logs), the destination (.txt file on the MikroTik device), and optional filters (topic/time). This effectively distinguishes it from sibling log tools like get_logs or monitor_logs, which return data rather than creating a file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for exporting logs to a device file but provides no explicit guidance on when to choose this over alternatives such as get_logs or search_logs. There are no exclusions or alternative tool suggestions, leaving the selection decision to the agent without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds little beyond 'detailed information'—no mention of output structure, device handling, or any operational side effects. The description is consistent with annotations but provides no additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no wasted words. It is concise and structured well, though it sacrifices substantive detail. The terseness is acceptable for a simple read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, presence of output schema, and safe annotations, the description is minimally viable. However, it lacks usage context (e.g., when to prefer this over get_interface) and parameter explanations, so the agent must rely heavily on schema and tool name. This is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no meaning to the parameters 'name' or 'device'. It does not explain how the device parameter affects the lookup or why it may be null. With no description-level compensation, the agent gets no semantic value beyond raw schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') and resource ('detailed information about a specific wireless interface'), clearly distinguishing it from sibling list tools like list_wireless_interfaces and generic get_interface. The phrase 'specific' also indicates this is a targeted lookup, not a broad enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_interface, list_wireless_interfaces, or get_wireless_registration_table. There are no exclusions, prerequisites, or context hints beyond the bare statement of what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as destructive. The description adds minimal behavioral context—saying it 'executes' a script—but does not disclose potential side effects, need for device reboot, or that it may overwrite existing configurations. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant or unnecessary words. It clearly states the primary function in concise form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a destructive tool with four parameters and no schema descriptions, the description lacks important context about how the import executes, what the parameters mean, and what to expect. The output schema may explain return values, but the description fails to provide sufficient operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the description does not explain any of the four parameters (device, verbose, filename, run_after_reset). The only indirect hint is the file extension .rsc which corresponds to filename, but no explicit parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verbs 'Imports and executes' and identifies the resource as 'RouterOS configuration script (.rsc file)', making it clear what the tool does. It also distinguishes from sibling tools like restore_backup or upload_file since none other imports configuration scripts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as restore_backup or export_section. The description provides no context about prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, so the safety profile is covered. The description adds no extra behavioral context, such as whether exports are included by default or how filtering works, which is relevant given the include_exports parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence directly states the purpose, no fluff or unnecessary detail. The main verb is front-loaded, making it immediately clear what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential details about parameter behavior and return values (though output schema may cover returns). It is too sparse for a tool with three optional parameters that affect what is listed, making it incomplete for confident usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for the three parameters (device, name_filter, include_exports). It does not compensate for the schema gap, leaving users to guess the meaning and usage of these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Lists' and a clear resource 'backup files' with a scope 'on the MikroTik device'. It clearly distinguishes itself from siblings like create_backup, restore_backup, and backup_info by indicating it enumerates existing backup files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as backup_info or list_files. It does not mention typical use cases, prerequisites, or that it is useful for verifying backups before restore.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, but the description itself adds no additional behavioral context, such as the permanent nature of removal or any side effects. It does not contradict the annotations, but it also does not enhance the agent's understanding beyond what structured metadata already provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: "Removes a wireless interface from the MikroTik device." It is front-loaded, free of fluff, and every word contributes to its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the description is too terse. It omits parameter semantics and does not clarify the impact of removal beyond the annotation's destructive hint, even though an output schema exists. The device parameter is particularly under-explained, making it incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning of the 'name' or 'device' parameters. With two parameters and no param-level descriptions, the description fails to compensate, leaving the agent without crucial information about what identifies the wireless interface.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: "Removes a wireless interface from the MikroTik device." It uses a specific verb and resource, distinguishing it from sibling tools like enable/disable or create/update wireless interfaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as disabling an interface instead of removing it, or any prerequisites. The description simply states what it does 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, so the description need not restate that. However, it doesn't add context about file location, naming conventions, overwrite behavior, or how the export is delivered (e.g., download). The description is neutral and does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is short and directly states the action. However, it is slightly under-specified, which is a matter of completeness rather than conciseness; the phrasing is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and safe annotations (readOnly, idempotent) which relieve some burden. But with 0% parameter coverage and no discussion of file export behavior (e.g., where the file goes, format), the description is adequate for a simple export but lacks operational detail for an agent to invoke it accurately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning for 'device' or 'filename' beyond their names. With zero required parameters and nullable defaults, the agent gets no hint about valid values, formats, or required fields for a valid export.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Exports user configuration to a file' uses a specific verb ('exports') and resource ('user configuration'), and indicates the output is a file. It distinguishes from siblings like export_dns_config and export_section by focusing on user configuration, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_export, export_section, or export_dns_config. No prerequisites, target file formats, or exclusions are mentioned, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description does not need to restate safety. It adds a minor behavioral detail about flexible lookup (by ID or address value) but does not disclose other traits like response format or error behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and purpose. Every word contributes value, and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, a short description is acceptable. However, the description omits any context about the optional device parameter, which is critical for multi-device environments, and does not clarify how the address value is formatted. This leaves gaps for an agent needing to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only partially addresses the address_id parameter by noting it can be an ID or value. The device parameter is entirely unexplained, and there is no mention of formats, defaults, or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('gets detailed information') and the resource ('a specific IP address'), and specifies two lookup methods (by ID or address value). It implicitly distinguishes from sibling list tools like list_ip_addresses, though it does not explicitly mention them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_ip_addresses or get_ipv6_address. The description implies a singular lookup scenario but does not state exclusions or prerequisites, leaving the agent without explicit selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, and the description adds that the tool filters by severity, which is a meaningful behavioral detail. However, it does not disclose additional traits such as pagination behavior, filtering logic, or any side effects beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's core function without redundant words or front-loaded delay.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters and no schema property descriptions, the description is insufficient to fully understand usage. It fails to explain time_filter or device semantics, and doesn't address limitations or return behavior beyond the severity filter. The output schema helps with return values, but the input parameter semantics are incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains only the severity parameter by listing its valid values, which compensates slightly for the 0% schema description coverage. However, limit, device, and time_filter remain completely unexplained, leaving significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving logs filtered by severity, with an explicit list of severity levels. This distinguishes it from generic log tools, but it does not explicitly differentiate from sibling filters like get_logs_by_topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_logs, search_logs, or get_logs_by_topic. The description states the action but gives no contextual recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds no behavioral context beyond the literal action. It does not mention default behavior (e.g., whether it lists entries across all devices or only the specified device) or how filters affect results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the core operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema and annotations covers return values and safety, but the description leaves gaps around filtering semantics, device scoping, and the interplay of optional parameters. It is adequate for a simple list operation but lacks depth for sophisticated use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description contains no parameter information. With 6 optional parameters, the agent must rely entirely on parameter names and defaults, which is insufficient for understanding semantics like regexp_only or how filters combine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists static DNS entries' uses a specific verb ('Lists') and resource ('static DNS entries'), clearly distinguishing this bulk-list operation from singular tools like get_dns_static. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_dns_static or list_dns_cache. There are no explicit use cases, prerequisites, or exclusions, leaving the agent to infer applicability solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already declare. The readOnlyHint and idempotentHint are present, and 'Lists' is consistent with them, but no additional traits (e.g., pagination, filtering behavior) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the verb and object, achieving maximum clarity in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple list operation, especially given the presence of an output schema and read-only annotations. However, it omits any mention of filtering options (name_filter, target_filter, etc.) that the schema exposes, leaving a gap for agents that need to understand invocation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage, and the tool description does not mention any of the parameters or their semantics. The description fails to compensate for the lack of schema documentation, leaving the agent without meaningful parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists simple queues on a MikroTik device, using a specific verb and resource. It distinguishes from sibling tools like get_simple_queue (single item) and list_queue_trees (different resource type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_simple_queue, nor does it mention filtering or intended scenarios. It simply states what it does without any contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond what annotations already declare (readOnlyHint, idempotentHint). It doesn't contradict annotations, but it also doesn't disclose additional context like default parameter behavior or filtering semantics. Since the output schema exists, return format is covered, but the description 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff or repetition. It is appropriately sized for a simple list tool, though it could include useful details like filtering options without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and is backed by good annotations and an output schema, making it adequate for a simply list operation. However, it leaves parameter semantics and usage guidance unaddressed, so it is not fully complete for an agent that needs to understand filters and when to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters with zero description coverage, and the tool description does not explain any of them. The parameter names (device, disabled_only, interface_filter) give partial hints, but the description adds no semantic meaning to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists WireGuard peers on the MikroTik device, using a specific verb and resource. It distinguishes from get_wireguard_peer by being a plural list operation, though it doesn't explicitly say 'all' or mention filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives like get_wireguard_peer or other peer management tools. The name implies listing, but there is no explicit context, exclusions, or mention of related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false, which already disclose safety traits. The description adds the fact that it operates on existing queue types and focuses on discipline-specific settings, but it does not explain partial-update semantics, failure behavior, or dependencies. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb 'Updates.' It contains no filler and every word contributes to the core purpose. It is appropriately sized for the information it provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 15 parameters and an output schema, but the description is extremely terse. It does not explain how the update behaves (e.g., whether unspecified parameters are left unchanged or reset), under what conditions it fails, or how new_name interacts with other settings. Annotations cover idempotency and non-destructiveness, but the complexity of the operation demands more contextual detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides only a high-level hint ('discipline-specific settings') without explaining any of the 15 parameters. Parameter names like cake_mpu, pcq_rate, and new_name are self-descriptive to some degree, but the description does not clarify their meaning, defaults, or constraints. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Updates an existing queue type's discipline-specific settings.' The verb 'updates' and resource 'existing queue type' distinguish it from create/remove/list tools. However, the term 'discipline-specific settings' is somewhat vague, leaving some ambiguity about the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention related tools like update_queue_tree or create_queue_type, nor does it provide preconditions or exclusions. The only implied usage is that an existing queue type must be updated, but this is not stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=false and openWorldHint=false, but not readOnlyHint, so the description still needs to clarify side effects or prerequisites. It does not mention whether the tool overwrites an existing pool, fails on duplicates, or requires an existing DHCP server setup. The range-format notes are useful but do not disclose behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. The 'Notes' section adds critical formatting details for the complex 'ranges' parameter without unnecessary verbosity. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need not be explained, and the description covers the required inputs and complex range format. However, it lacks sibling differentiation and does not explain the optional 'next_pool' parameter or device targeting. These are meaningful gaps for a tool interacting with a complex MikroTik configuration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameters. It thoroughly explains the required 'ranges' parameter with hyphen-separated and comma-separated examples, which is critical. However, it provides no additional meaning for 'name', 'device', 'comment', or 'next_pool'; 'next_pool' in particular is non-obvious and left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates a DHCP address pool') and the target ('on the MikroTik device'), and it specifies the key input (IP ranges). However, it does not distinguish this tool from the sibling tool 'create_ip_pool', which likely serves a very similar purpose in the same domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as create_ip_pool, create_dhcp_server, or create_dhcp_network. The only contextual hint is the tool name itself, which is insufficient for an agent to choose among similar DHCP/pool-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral context (e.g., reversibility or effect on existing entries) but does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant information. It is appropriately concise for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and has output schema plus annotations, the description does not compensate for the lack of parameter documentation or clarify the optional device parameter. An agent may not know how to identify the correct entry_id or understand multi-device behavior, leaving notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters with 0% description coverage. The description does not explain entry_id or device, leaving the agent to guess their meaning and relationship. The schema only provides parameter names, not semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'disables' and the object 'static DNS entry' to clearly state the action. It distinguishes well from sibling tools like enable_dns_static and remove_dns_static.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives such as remove_dns_static or enable_dns_static. The description does not mention exclusions, prerequisites, or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state idempotentHint=true and destructiveHint=false, but the description adds no behavioral detail beyond the bare action. It does not explain effects such as the rule becoming inactive while remaining in the configuration, reversibility, or whether any validation occurs. The description simply restates the title without augmenting annotation-provided information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no extraneous words. It is concise and immediately conveys the tool's purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema shown, the description is minimally adequate but leaves important context unstated. It does not clarify that disabling keeps the rule in place but inactive, nor does it mention the optional device parameter or any prerequisites. The description is too sparse to fully inform an AI agent about the operation's semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention or explain the 'rule_id' or 'device' parameters. While the parameter names are somewhat self-explanatory, the description adds no guidance on how to obtain rule_id or when device is needed, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Disables a firewall filter rule' uses a specific verb and resource, clearly distinguishing it from sibling tools like enable_filter_rule, update_filter_rule, and remove_filter_rule. The action and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when to use this tool versus alternatives. It does not mention prerequisites (e.g., the rule must exist), nor does it contrast with related operations like deleting or updating a rule. No usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the obvious action. Annotations already declare idempotentHint=true and destructiveHint=false, but the description does not disclose what happens if the rule is already enabled, error conditions, or rule matching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, with no filler. It is appropriately concise for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having annotations and an output schema, the description is too minimal for a tool with an optional device parameter and a specific rule_id. It lacks prerequisites, selection criteria, and parameter semantics, so agents might misinvoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain rule_id or device. While rule_id is inferable from context, the device parameter is completely unexplained, leaving agents without guidance for a parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Enables a firewall filter rule' with a specific verb and resource, clearly distinguishing it from siblings like disable_filter_rule, update_filter_rule, and remove_filter_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance is provided. The context implies it's for enabling a disabled rule, but no alternatives or exclusions are mentioned, despite sibling tools like disable_filter_rule existing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, and the description adds no further behavioral context. There is no mention of side effects, prerequisites, or what 'enabled' means in the MikroTik context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a focused note. It is front-loaded and contains no redundant content, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description is sparse. It lacks context about the operational effect of enabling a route, prerequisites, or how it relates to list_routes and disable_route. The route_id note and presence of an output schema provide some grounding, but the description could do more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The note about route_id ('*N' or 'N' from list output e.g. '*3') adds valuable format and sourcing information beyond the schema's bare 'Route Id'. The device parameter remains unexplained, and with schema description coverage at 0%, the description only partially compensates for missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Enables a route' clearly identifies the action and target resource, distinguishing it from sibling tools like disable_route or enable_interface. However, it adds little beyond the tool name itself, so it does not earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as disable_route or update_route. The only extra note explains route_id format, which pertains to parameter handling rather than tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context beyond the action itself, so it does not contradict annotations but also adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, but it is under-specified. It lacks necessary context about parameters and usage, so it is not 'appropriately sized' despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0% parameter coverage and no usage guidance, the description is not complete enough for an agent to correctly invoke the tool. The annotations help with safety, but the description fails to explain what 'name' or 'device' refer to or what enabling entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. 'Enables a user' provides no meaning for the 'name' or 'device' fields, leaving the agent to guess what they represent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enables a user' uses a specific verb and resource, clearly indicating the action of enabling a user account. It distinguishes itself from sibling tools like disable_user, add_user, and update_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one wants to enable a user, but provides no explicit when-to-use, when-not-to-use, or alternative guidance. It does not mention the relationship to disable_user or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds only that it retrieves the 'current' cache, implying a snapshot of the present state, but does not describe any additional behavior such as pagination, response format, or the effect of the optional device parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is highly concise and 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the output schema is present, but the description lacks important context such as when to use this tool among many DNS-related siblings and what the device parameter does. The annotations and output schema cover some aspects, but the overall guidance is minimal for an agent to confidently select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'device' with no description (0% schema coverage). The tool description does not mention this parameter or clarify its meaning, default, or acceptable values. For a single optional parameter, some explanation is expected but completely absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Gets' and resource 'current DNS cache', making the purpose clear. However, it does not distinguish this from sibling tools like get_dns_cache_statistics or flush_dns_cache, which also relate to DNS cache.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or scenarios where this tool is preferred over related tools like get_dns_cache_statistics or test_dns_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the annotations (readOnlyHint=true, idempotentHint=true). However, it does not add any behavioral context beyond what annotations already provide, such as whether statistics are live or computed from cached data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence conveying the core action. There is no verbose or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema, so the description need not explain return values. However, it misses usage guidance and parameter explanation, making it minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, and the description does not mention the 'device' parameter at all. The description leaves the meaning and purpose of 'device' unexplained, which is a significant gap for a tool with a single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets routing table statistics' uses a specific verb and resource, clearly stating what the tool does. However, it does not explicitly distinguish itself from sibling tools like get_routing_table or get_route_cache, though 'statistics' implies aggregate data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_routing_table or get_route. The description does not mention any prerequisites, exclusions, or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior, and the description aligns with that. However, it adds no new behavioral context such as what 'detailed information' includes, any error conditions, or the effect on the system. With annotations present, the description fails to go beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is appropriately sized for a simple read tool and quickly conveys the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While there is an output schema to cover return values, the 0% schema description coverage and the unexplained optional 'device' parameter make the description inadequate for a complete understanding. The description gives no guidance on how to select the interface or what differentiates a successful call from an error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter ('name' or 'device'). The schema itself provides no descriptions beyond types and defaults, so the description must compensate but does not. This leaves the purpose of the 'device' parameter completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Gets' with a clearly identified resource 'a specific WireGuard interface', which effectively distinguishes it from sibling tools like list_wireguard_interfaces that list all interfaces. It unambiguously states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving details of one interface, but it does not explicitly state when to use this tool versus list_wireguard_interfaces or get_wireguard_peer. No exclusions or alternative recommendations are provided, making the guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe read nature is known. However, the description adds no further behavioral context—such as return format, whether disabled servers are included, or any side effects—so it contributes nothing beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that immediately states the tool's purpose with no unnecessary words or repetition. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no schema descriptions, the tool definition is incomplete for an agent to understand how to effectively use filters. The output schema exists but is not visible here, and the description does not mention return values or usage scenarios, making the description insufficient for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on any of the 5 parameters (device, name_filter, invalid_only, disabled_only, interface_filter). While parameter names hint at their purpose, the description fails to clarify semantics or provide examples, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists DHCP servers on the MikroTik device' clearly identifies the action (list) and the resource (DHCP servers), distinguishing it from related tools like get_dhcp_server (singular) or create_dhcp_server. This is a specific verb+resource pairing with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_dhcp_server or create_dhcp_server. It does not mention filtering, context for use, or exclusions, leaving the agent without comparison information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe read operation without side effects. The description adds the context that it operates on a MikroTik device, but provides no additional behavioral details such as return format, pagination, or whether it includes dynamic/disabled addresses by default. This is consistent with annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It is appropriately concise for the purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 optional parameters and no schema descriptions, the description remains minimal. It doesn't explain filter usage, whether the list includes dynamic/disabled entries, or how the output is structured (though an output schema exists). The tool appears simple, but the description leaves too many gaps for an agent to know how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden of explaining the six parameters (device, dynamic_only, disabled_only, address_filter, network_filter, interface_filter). The description mentions none of them, leaving the agent to infer from parameter titles alone. It does not clarify filter semantics (e.g., exact match vs substring) or how device selection works.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (lists), the resource (IP addresses), and the scope (MikroTik device). It distinguishes from sibling tools like get_ip_address (which retrieves a single address) and list_ipv6_addresses (different address family), so an agent can select this tool appropriately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool compared to alternatives, such as get_ip_address for a specific address or list_ipv6_addresses for IPv6. It doesn't mention any exclusions or prerequisites. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with annotations (readOnlyHint: true, idempotentHint: true) and states the basic read-only behavior. It adds little beyond the annotations, but the annotations already cover the main safety profile, and there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. Every word is necessary, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nine parameters and an output schema, but the description only says 'Lists NAT rules' without mentioning filtering options, device selection, or what the result represents. This is insufficient for correct invocation in varied scenarios, though the output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions none of the nine parameters. Even though parameter names like chain_filter and action_filter are self-descriptive in the schema, the description adds no semantics beyond the schema and fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lists') and a clear resource ('NAT rules on the MikroTik device'). It distinguishes itself from sibling tools like get_nat_rule (single rule) and create_nat_rule (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no mention of filters or prerequisites. The only implied usage is 'when you need a list of NAT rules', which is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior, so the description does not need to restate these. However, it adds no further behavioral context such as output scope, filtering capabilities, or edge cases, but it is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and directly states the function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and omits the optional filters entirely. While the output schema covers return format, the tool's capabilities (filtering by kind/name) are undocumented, making it incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the parameters (device, kind_filter, name_filter) have no descriptions. The tool description also fails to explain these parameters or the filtering behavior, leaving the agent with no semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists queue types on a MikroTik device, using a specific verb and resource. It is distinct from sibling tools like get_queue_type or list_queue_trees by naming 'queue types'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_queue_type, nor any mention of the optional filters or exclusions. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotent and non-destructive. The description adds no behavioral details, such as what happens to unspecified fields or permission requirements. Given 8 optional parameters, this lack of context is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of 12 words, immediately communicates the core purpose with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters and many sibling wireless/interface tools, but the description does not explain parameter usage or selection criteria. An output schema exists so return values needn't be described, but overall completeness is low for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only mentions 'settings' generically and lists no parameter meanings, leaving the agent to rely solely on field names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Updates' and the resource 'WireGuard interface's settings' on the MikroTik device. It effectively distinguishes from create/remove/enable/disable sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing' implies the tool is for modifying already-created interfaces, but it doesn't explicitly mention alternatives (e.g., create_wireguard_interface) or conditions 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=false and openWorldHint=false, but the description adds little behavioral context beyond the action. It does not disclose prerequisites (e.g., interface must exist), duplicate handling, reversibility, or permission requirements. The notes clarify parameter formats, not side effects or operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is stated in one concise sentence, and the notes are formatted as a compact bulleted list with relevant examples. There is no redundant filler, and the structure is easy to scan and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with 10 parameters and no schema descriptions, the description covers the basic purpose and a few parameter formats but lacks usage context, prerequisites, and error/duplicate behavior. It leaves the agent uncertain about preconditions (e.g., existing interface) and how this tool interacts with sibling tools like update_wireguard_peer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds concrete format examples for allowed_address (CIDR, comma-separated), endpoint_address (hostname/IP), and persistent_keepalive (seconds as string), which the schema does not provide. However, it omits clarifications for other important parameters like public_key (base64 format) and preshared_key, and with 10 parameters and 0% schema description coverage, this is only partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adds a WireGuard peer') with specific attributes (public key and allowed addresses) and target (interface on the MikroTik device). This distinguishes it from sibling tools like update, remove, list, get, enable, and disable by using the 'add' verb and specifying the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that update_wireguard_peer should be used for existing peers, nor does it state prerequisites such as requiring an existing WireGuard interface. The verb 'adds' implies creation, but there are no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint false, so the agent already knows this is not destructive. The description adds minimal behavioral context by explaining place_before as 'rule number or ID (*N) to insert before,' which hints at insertion ordering, but it does not disclose other behavioral traits like rule ordering defaults, effect on existing rules, or whether the rule is applied immediately. With annotations present, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with one lead sentence and three bullet-point notes. Every sentence serves a purpose, though the structure could be tighter by aligning notes with the actual parameter names. No unnecessary fluff is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 17 parameters, no schema descriptions, and only three parameters covered, the description is incomplete. It omits semantics for required fields like chain and action, does not explain valid action values, and provides no context about the NAT rule lifecycle relative to sibling tools. The presence of an output schema reduces the need to describe return values, but the overall guidance is still insufficient for complex use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides format examples for only three of seventeen parameters (to_addresses, to_ports, place_before), leaving critical parameters like action, protocol, and log_prefix unexplained. This is insufficient for an agent to correctly populate many fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Creates' and identifies the resource as 'a NAT rule (srcnat or dstnat) on the MikroTik device,' which clearly distinguishes it from sibling tools like create_filter_rule. It conveys the exact scope of the operation without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as update_nat_rule, remove_nat_rule, or move_nat_rule. It also omits any prerequisites or context that would help an agent decide between creating a NAT rule and other firewall operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral context, such as the impact on traffic or whether configuration is preserved, leaving the agent without additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple operation and clearly readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a basic disable operation, the description is minimal but lacks any usage context or parameter detail. Given that an output schema exists, return values need no explanation, but the tool still lacks guidance for an agent deciding when to invoke it, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the meaning of the 'name' or 'device' parameters; schema description coverage is 0%, so the agent must rely solely on parameter names. While 'name' is fairly intuitive, 'device' is ambiguous and lacks clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Disables' and identifies the resource as 'WireGuard interface', clearly distinguishing it from sibling tools like enable_wireguard_interface or remove_wireguard_interface. It is unambiguous and directly states the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, such as when disabling is preferred over removing, or prerequisites like the interface existing. The description offers no context on selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds no behavioral detail beyond that. It does not explain the operational impact (e.g., clearing cached routes may disrupt active sessions), whether it requires confirmation, or what happens on failure. The description contributes no additional transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that immediately states the action. It is economical and well-structured with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one optional parameter and an output schema. The minimal description is sufficient for basic invocation, and annotations cover destructive behavior. However, it lacks context about when to flush the cache, prerequisites, or potential side effects, making it incomplete for a full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'device' with 0% description coverage. The description does not mention this parameter at all, so it adds no meaning beyond what the schema already provides (device name, default null). For a low-coverage case, the description should have explained the parameter usage but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is clear and specific: 'Flushes the route cache.' It uses a strong action verb and a precise target resource, distinguishing it from sibling tools like get_route_cache (read) and flush_dns_cache (DNS vs route).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool, when not to use it, or alternatives. It merely states the action without any context about route cache invalidation, device targeting, or relationship to other route tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds context about event categories (login, reboot, config-change) but does not disclose additional behavioral traits such as result ordering, pagination, or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It efficiently delivers the core purpose, though it could expand slightly without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 4 optional parameters and an output schema, and annotations cover read-only behavior. However, the description fails to differentiate from many sibling log tools and does not explain parameter semantics, leaving some context gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, so the description must compensate. It only hints at event_type values through examples, but does not explain limit, device, time_filter, or format constraints. Parameter names are self-explanatory but semantics are left undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves system-related log events with concrete examples (login, reboot, config-change). It distinguishes from generic log tools like get_logs by focusing on system events, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for system-related log events but offers no explicit guidance on when to choose this over sibling tools like get_logs_by_topic or get_security_logs. No exclusions or alternatives are mentioned; usage must be inferred from the examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=true, so the safety profile is covered. However, the description adds no additional behavioral context such as whether removal is permanent, whether associated peers are also removed, or what happens if the interface does not exist. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and includes no redundant information. It is appropriately sized for a simple removal operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward remove operation, the description is minimally adequate, but it lacks critical context about dependencies (e.g., whether peers must be removed first), the role of the 'device' parameter, and any side effects beyond the obvious removal. Presence of an output schema helps, but the description alone leaves gaps for an agent to act correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'name' or 'device' parameters. The parameter titles are somewhat self-explanatory (likely interface name and target device), but no format, constraints, or purpose details are given. Description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Removes' and clearly identifies the resource 'WireGuard interface' on the MikroTik device. This clearly distinguishes it from sibling tools such as create, update, get, enable, disable, and other remove tools (e.g., remove_wireless_interface).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as disabling the interface instead of removing it, or the need to remove associated peers first. There is no explicit 'when not to use' or reference to related sibling tools like remove_wireguard_peer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=false and openWorldHint=false, setting a low bar. The description adds a useful note about lease_time duration format, which is extra context. However, it does not disclose potential side effects, validation requirements, or behavior on conflicting configurations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, with the main action upfront and a single structured note. No filler or redundant content; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, only 2 required, and no parameter descriptions, the tool is underspecified. The output schema exists, so return values are covered, but the description lacks context about dependencies (e.g., interface must exist), typical usage flow, or implications of settings like authoritative. The lease_time note is helpful but not enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains lease_time, leaving other parameters (name, interface, address_pool, authoritative, etc.) with no additional meaning beyond bare names and types. This is insufficient for a 9-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Creates a DHCP server') and the target resource ('bound to the specified interface on the MikroTik device'). It is specific and distinguishable from sibling tools like list_dhcp_servers or create_dhcp_network.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as create_dhcp_network or create_dhcp_pool. It does not mention prerequisites (e.g., existing interface, address pool) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only openWorldHint and destructiveHint; the description adds no behavioral side-effect information such as write access requirements, idempotency, or persistence of the queue type on the router. The only added context is parameter format examples, which are not behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single main sentence followed by a short, focused note block. All listed examples add value, and the front-loaded structure makes the core purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 28 parameters and no schema descriptions, the description is too sparse to fully specify which options apply to each qdisc kind and what format/units are expected. It also doesn't mention the response/return value, though an output schema exists. The tool is moderately complex, so a more complete mapping would be needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 28 parameters and zero schema description coverage, the description carries the burden; it only explains a few parameters (pcq_rate, pcq_classifier, cake_rtt, fq_codel_target/interval) with example formats. Most parameters (e.g., cake_mpu, red_burst, fq_codel_quantum) remain unexplained, and the mapping between kind and applicable per-discipline params is not provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Creates' and a resource 'queue type (qdisc)', which clearly differentiates it from siblings like create_queue_tree and create_simple_queue. It also specifies the domain (MikroTik) and that kind selects the discipline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that kind selects the discipline and remaining params are per-discipline options, which helps when choosing parameters. However, it does not explicitly state when to use this tool instead of related queue tools such as create_queue_tree or create_simple_queue, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states that the tool creates a VLAN interface, without disclosing side effects such as whether it fails on duplicate entries, whether it modifies live configuration, or any permission requirements. Annotations provide only destructiveHint=false, which is minimal, leaving the description to carry the burden for a state-changing device configuration tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence of about 15 words. It front-loads the verb and key objects, contains no filler, and is easy to parse, earning every word its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, MikroTik-specific networking semantics) and sparse annotations, a one-sentence description is inadequate. It lacks prerequisites, default behaviors, and guidance on interactions with existing interfaces or the device configuration. The output schema may document return values, but it does not compensate for missing usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 10 parameters, the description clarifies only 'VLAN ID' and 'parent interface' for vlan_id and interface, but it ignores other parameters like arp, mtu, device, comment, disabled, arp_timeout, and use_service_tag. The agent is left to infer meanings from schema titles alone, which is insufficient for parameters like use_service_tag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Creates' and identifies the resource 'VLAN interface' with context 'on the MikroTik device' and key parameters 'VLAN ID and parent interface'. This clearly distinguishes it from sibling tools such as list_vlan_interfaces, get_vlan_interface, update_vlan_interface, and remove_vlan_interface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context (creating a new VLAN interface) and mentions the required VLAN ID and parent interface, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites like requiring the parent interface to exist. No reference is made to update_vlan_interface for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context beyond the operation itself, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: one clear purpose sentence plus a compact, useful parameter note. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple toggle operation, annotations, and output schema, the description is mostly adequate. It lacks explanation of the 'device' parameter and does not clarify scope relative to disable_wireless_interface, making it minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The note for 'name' adds useful meaning by specifying exact interface name with examples, which the schema lacks. However, the optional 'device' parameter is entirely undocumented, leaving a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Disables an interface on the MikroTik device,' giving a clear verb and resource. It does not explicitly differentiate from sibling disable_wireless_interface, though the note examples (ether1, bridge, pppoe-out1) imply general non-wireless interfaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus enable_interface or disable_wireless_interface. There are no prerequisites, exclusions, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context such as effect on traffic, requirement for admin privileges, or error behavior. It merely restates the action without disclosing traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The supplementary note about the 'name' parameter is directly relevant and formatted as a separate note, keeping the main description clean. No unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple enable operation with annotations and an output schema present, the description covers the essential purpose and the required parameter. However, it omits guidance on the optional 'device' parameter and does not clarify the scope of 'interface' relative to sibling tools for wireless/wireguard, leaving some ambiguity for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It does explain the 'name' parameter with exact-match guidance and concrete examples ('ether1', 'bridge', 'pppoe-out1'), which adds value. However, it provides no explanation for the 'device' parameter, leaving its meaning and usage unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource construction ('Enables an interface on the MikroTik device'), making the tool's function immediately clear. It also distinguishes itself from sibling tools like enable_wireless_interface and enable_wireguard_interface by referring to a generic interface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for general interfaces while other tools exist for wireless/wireguard, nor does it state prerequisites such as the interface needing to exist or be disabled. No exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds minimal behavioral context beyond naming the resource; it does not mention any behavior such as filtering, error conditions, or effects of the optional parameters. Since annotations cover the main safety aspects, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded with the action and resource, and the parenthetical clarification adds value without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with an output schema present, the description is mostly sufficient. However, it does not mention the role of the parameters or any usage nuances, which is a minor gap. Given the simplicity and the existence of an output schema, the description is reasonably complete but could benefit from a note about the optional interface filter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters (device and interface) at all. The parameter names are self-explanatory to some extent, but the description fails to compensate for the lack of schema descriptions, leaving the agent without guidance on how to use these optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Gets the wireless registration table (connected clients) from the MikroTik device.' It uses a specific verb ('gets') and a specific resource (wireless registration table), and the parenthetical 'connected clients' clarifies the data returned. This distinguishes it from sibling tools like get_wireless_security_profile or scan_wireless_networks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. While the phrase 'connected clients' implies a use case, there is no explicit context about when to choose this tool over other wireless-related getters or scans, which is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, which cover the safety profile. The description adds no additional behavioral context (e.g., what happens if the queue type is in use). It neither contradicts nor enriches the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the action and resource, making it immediately scannable and appropriately sized for a simple CRUD operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameter descriptions, no usage guidance, and minimal behavioral disclosure beyond the annotations, the description leaves important gaps. While the output schema and annotations provide some context, the description fails to address dependencies, side effects, or selection criteria.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain either the 'name' or 'device' parameters. The agent must infer meaning from parameter names alone, which is insufficient for a destructive operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'removes' and clearly identifies the resource as 'queue type' on the MikroTik device. This directly distinguishes it from sibling tools like create_queue_type, get_queue_type, and update_queue_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the action ('removes a queue type'), but no explicit when-to-use or when-not-to-use guidance is given, nor are alternatives mentioned. It doesn't state prerequisites or consequences of removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds a key behavioral trait: the function is legacy and unsupported in RouterOS v7.x, meaning attempts to use it there are likely to fail. This is valuable beyond the annotations and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that immediately delivers the critical deprecation warning. There is no redundant or filler content, and the message is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a deprecated tool with a simple schema: it alerts the agent to the unsupported status in v7.x. However, it omits any explanation of what the tool does, the meaning of parameters, or suggested alternatives. Given the simple nature and presence of an output schema, the missing pieces are notable but not severely detrimental.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the 'name' or 'device' parameters. The agent is left to guess that 'name' refers to the wireless security profile name and 'device' likely targets a specific RouterOS device. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Legacy function - not supported in RouterOS v7.x' does not explicitly state that the tool removes a wireless security profile. The purpose is left to be inferred from the tool name and annotation title, making it clear but vague in the description itself. It does not differentiate from sibling tools beyond implying deprecation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly signals when NOT to use the tool: on RouterOS v7.x, since it is not supported. This is a clear exclusion and provides important context for tool selection. However, it does not mention alternative tools or when it should be used, so it falls short of full 'when/when-not/alternatives' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only openWorldHint=false and destructiveHint=false, and the description adds no behavioral context beyond the obvious creation action. It does not disclose side effects, failure modes, permissions, or prerequisites. The parameter format notes are semantic rather than behavioral, leaving the agent uninformed about operational impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: one clear purpose sentence followed by a compact bullet list of parameter notes. Every sentence adds value, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, this is a 14-parameter creation tool with minimal annotations. The description omits guidance on half the parameters, gives no usage alternatives, and does not mention prerequisites or potential issues. It covers only core bandwidth/duration semantics, leaving substantial gaps for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's notes add significant meaning for several parameters: bandwidth formats for max_limit/limit_at/burst_limit/burst_threshold, duration for burst_time, interface/queue examples for parent, and a 1-8 range for priority. However, roughly half the parameters (e.g., name, queue, device, comment, disabled, bucket_size, packet_mark) remain unexplained, so it does not fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific action: 'Creates a hierarchical queue tree entry attached to a parent interface or queue.' This distinguishes it from sibling tools like create_simple_queue and the other queue tree management operations, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no direction on when to use this tool versus alternatives (e.g., create_simple_queue) and does not mention prerequisites like parent existence or exclusions. The only implicit hint is the phrase 'attached to a parent interface or queue,' but there is no explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, covering the main behavioral concerns. The description adds no extra context beyond the purpose, but it does not contradict the annotations. Given the presence of annotations, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the action and target. It is front-loaded, contains no filler, and every word contributes to the meaning. This is an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple operation with two parameters and an output schema, the description provides the core purpose but lacks usage guidance and parameter semantics. The annotations and schema fill some gaps, but the description alone is not fully self-sufficient for a new agent. It is adequate for a straightforward tool, but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter details. It does not mention either parameter. While 'entry_id' is somewhat self-explanatory, 'device' is ambiguous, and the description offers no clarification about what device means or how it relates to the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Enables') with a clear resource ('a static DNS entry'), distinguishing it from sibling tools like add_dns_static, remove_dns_static, and especially disable_dns_static. The purpose is unambiguous and directly states the action performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., that the entry must already exist), nor does it contrast with disable_dns_static or other DNS static entry operations. There is no usage context beyond the bare action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds no extra behavioral context such as side effects, scope, or device targeting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence with no filler. The verb and resource are front-loaded, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The operation is simple, but the description omits any mention of the optional device parameter and its effect. An output schema exists, but the description does not reference what is returned. It feels minimally adequate but lacks detail for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional 'device' parameter with no description, and schema coverage is 0%. The description does not explain the meaning, possible values, or default behavior of the device parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool flushes the DNS cache. The specific verb 'flushes' and resource 'DNS cache' make it distinct from sibling tools like get_dns_cache or set_dns_servers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to flush the cache, when not to, or alternative tools. The description simply states the action without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds the 'active/logged-in' filter, which clarifies scope but does not disclose additional behavioral traits such as how 'active' is determined, real-time nature, or any limitations. It offers modest value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that directly states the tool's purpose with no filler. It is front-loaded and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, read-only, and has an output schema, so return values are covered by the schema. However, the description is incomplete regarding the device parameter and usage context. It does not explain whether the parameter is optional or how to target a specific device, which is a notable gap given the 0% schema parameter coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'device' with no description (schema coverage 0%). The description does not mention this parameter at all, so it fails to compensate for the low schema coverage. The agent is left to infer the parameter's meaning solely from its name, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') and a clearly scoped resource ('currently active/logged-in users'), which precisely distinguishes it from sibling tools like list_users (all users) and get_user (a single user). The qualifier 'active/logged-in' adds concrete scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or when not to use it. There is no mention of prerequisites, such as requiring a specific device parameter, or comparison with list_users. The usage context is only implied by the tool name, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds only that it returns 'detailed information' but does not disclose behavior such as error handling, permissions, or the exact content of the output. This is a baseline score given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that directly states the tool's purpose with no redundancy, fluff, or irrelevant details. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With read-only annotations and an output schema present, the description provides a functional baseline. However, it leaves the 'device' parameter unexplained and offers no usage context alongside many sibling tools. It is adequate but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate meaningfully. It implies the 'name' parameter by saying 'specific DHCP server,' but the 'device' parameter is left entirely unexplained, leaving ambiguity about its role and whether it is required for selecting the server.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Gets') and resource ('detailed information about a specific DHCP server'), which distinguishes it from sibling tools like list_dhcp_servers or create_dhcp_server. It is specific and unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, such as list_dhcp_servers for enumerating all servers or get_dhcp_pool for pool details. There are no prerequisites, exclusions, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. However, the description adds minimal behavioral context beyond the annotations—it merely restates the operation without disclosing pagination, filtering behavior, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short, front-loaded sentence with no redundant words. Every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with an output schema and readOnly/idempotent annotations, the description is minimally adequate but incomplete. It fails to explain the filter parameters or how this differs from get_user_group, which is a common source of confusion. The existence of an output schema compensates for lack of return-value detail, but parameter semantics remain a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no details about the device, name_filter, or policy_filter parameters. The description must compensate for the schema's lack of explanatory text, but it does not even mention the parameters, leaving agents without guidance on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('lists') and resource ('user groups') with a clear context ('on MikroTik device'). It distinguishes itself from sibling tools like get_user_group (which retrieves a single group) and add/update/remove_user_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as the generic listing operation, but it does not explicitly mention when to use it over alternatives such as get_user_group. It lacks explicit exclusions or alternative tool references, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds only a note about rule_id sourcing, which is parameter semantics, not behavioral transparency. No additional behavior (e.g., permanence, side effects) is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a concise note. It is front-loaded with the purpose and ends with a practical tip. Every word earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive delete operation, the description is adequate. It explains the critical rule_id input and relies on annotations for destruction warnings. Output schema exists, so return values are documented externally. A minor gap is the lack of any caution about permanence, but the annotations already cover destructive behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does clarify rule_id format ('use the ID from list output e.g. *1 or 0'), which adds meaning beyond the schema. However, the optional device parameter is not explained at all, leaving an incomplete picture.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Removes a NAT rule from the MikroTik device' with a specific verb and resource. It distinguishes from sibling tools like create_nat_rule, update_nat_rule, and list_nat_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like disable_nat_rule or update_nat_rule. The only note explains rule_id format, which is parameter guidance, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds no further behavioral context beyond stating the removal action, which aligns with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, front-loaded with the action, no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool with 2 params and annotations covering safety, the description is minimally adequate but lacks any usage guidance or parameter clarification, making it incomplete relative to the available schema and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not explain the 'name' or 'device' parameters beyond their literal names. It gives no detail on format, constraints, or how device selection works.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Removes' with the resource 'queue tree' and location 'from the MikroTik device', clearly distinguishing it from sibling tools like create_queue_tree or enable_queue_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, no prerequisites or exclusions, and no reference to sibling tools like remove_simple_queue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Annotations already provide destructiveHint=true and idempotentHint=true, so the agent knows the operation is destructive and idempotent. No additional detail on effects, error conditions, or irreversibility is provided, but annotations cover the core safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and resource, and contains no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool, the description is adequately scoped but leaves gaps: parameter meanings (especially 'device') are not explained, and no usage guidance or error behavior is mentioned. The output schema and annotations cover some context, but the description itself is minimal relative to the available structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain what 'name' or 'device' refer to. Since schema descriptions are absent, the description must compensate but fails to do so, leaving parameter semantics mostly inferred from the tool name and schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Removes' and the resource 'simple queue' on the MikroTik device. This distinguishes it from sibling tools like create_simple_queue, get_simple_queue, update_simple_queue, and enable/disable_simple_queue, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites such as the queue existing or needing to be disabled first. It also does not mention that this is the delete operation for simple queues among related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it updates 'existing' interfaces, but does not disclose behavior regarding null values, partial updates, or whether renaming might affect references. This is minimal additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and resource. Every word is useful, and the 'etc.' avoids unnecessary enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering idempotency/non-destructiveness, the description is adequate but not complete. It fails to address key behavioral nuances like whether optional fields are updated only when non-null, and it doesn't clarify the distinction between 'name' and 'new_name'. The gap in parameter semantics and usage guidance leaves room for misinterpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'name, SSID, enabled state, etc.' but omits device, comment, and new_name, and uses 'name' ambiguously—likely the identifier, not the new_name parameter. It adds no clarification about parameter roles beyond what schema titles already imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Updates' and the resource 'existing wireless interface's settings', with specific examples (name, SSID, enabled state). This distinguishes it from sibling tools like create_wireless_interface, enable_wireless_interface, and remove_wireless_interface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. Sibling tools enable_wireless_interface and disable_wireless_interface exist, but the description does not mention them or clarify that this tool is for broader setting modifications. The usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint: false, but the description does not disclose behavioral details such as whether the upload overwrites existing files, where the file is stored, or any prerequisites. The 'for restore operations' context is purpose, not behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant information, clearly front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but the description lacks context on prerequisites, integration with restore_backup, and error handling. However, given the low complexity, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains the base64 encoding of content_base64. It does not clarify the 'device' parameter or the expected format of 'filename'. Parameter meaning is left to name inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads a base64-encoded file to the MikroTik device and specifically mentions its use in restore operations, distinguishing it from sibling tools like download_file and restore_backup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context ('for restore operations') but does not explicitly state when to use this tool versus alternatives like restore_backup or import_configuration. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is clear. The description adds little beyond confirming it retrieves information; it does not discuss error cases or behavior with nonexistent files, but this is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with output schema and clear annotations, the description is adequately complete. It defines the tool's scope but doesn't describe return value details or failure modes, though the output schema likely covers the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the two parameters, and the description does not explain 'filename' or 'device' beyond the implicit 'backup file' context. Since the description does not compensate for the missing parameter documentation, the agent must infer from the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') and identifies the resource ('detailed information about a backup file') on the MikroTik device. This clearly distinguishes it from sibling tools like list_backups (which lists backups) and create_backup (which creates them).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like list_backups or restore_backup. No exclusions or context is given, leaving the agent to infer usage from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the fact that it creates a queue. Annotations only indicate destructiveHint: false and openWorldHint: false, but the description adds no context about side effects, prerequisites, or what happens on error. For a creation tool with many parameters, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a one-line summary followed by a short bullet list of parameter notes. It is front-loaded with the main purpose and provides useful examples without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 16-parameter complexity and no schema descriptions, the description leaves significant gaps. It covers the most critical parameters but does not explain many others or any preconditions/behavior on creation. The existence of an output schema mitigates missing return-value details, but the description is not fully complete for a complex device configuration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears the burden of explaining parameters. It does provide valuable format details for target, max_limit/limit_at/burst_limit/burst_threshold, burst_time, and priority, with examples. However, it omits 9 other parameters (e.g., dst, device, parent, bucket_size, packet_marks), so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates'), the resource ('simple queue'), and the purpose ('rate-limit a target address or interface'). This distinguishes it from sibling tools like update_simple_queue or get_simple_queue, and the mention of 'simple queue' separates it from queue types and trees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Creates' implies this is for new queues, but there is no explicit guidance on when to use this versus updating or removing existing queues. No alternatives are mentioned, so usage is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the read-only nature is covered. The description adds minimal behavioral context beyond that (e.g., that it returns used address count) but does not disclose potential errors, required permissions, or any other side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It clearly states the action and a key detail, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (a getter with two parameters), the description is mostly complete when combined with strong annotations and an output schema. However, it does not address the optional 'device' parameter or provide guidance on parameter usage, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the 'name' or 'device' parameters at all. The only hint is 'specific IP pool', but the agent gets no explanation of what each parameter means or how to use them, leaving the schema to stand alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') and resource ('specific IP pool'), and adds a distinguishing detail ('including used address count') that differentiates it from list_ip_pools (which lists all pools) and get_ip_address (different resource). This makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for a specific named pool, but does not explicitly state when to use it over alternatives like list_ip_pools or list_ip_pool_used. There are no exclusions or references to sibling tools, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the 'currently used (allocated)' qualifier, which is useful context, but does not disclose details like filtering behavior or default scope. No contradiction found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the five filter parameters and the existence of an output schema, the description is too brief. It does not explain the purpose of the filters or how the results are scoped, leaving gaps in the operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it provides no explanation for the five parameters (device, pool_name, mac_filter, info_filter, address_filter), leaving the agent to guess their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'lists' and a specific resource 'IP pools' with a clear scope: 'currently used (allocated) addresses'. This distinguishes it from sibling tools like 'list_ip_pools' which list pools themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to see allocated addresses from IP pools) but does not explicitly state alternatives or exclusions. It lacks guidance on choosing between this and related list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds genuine value by explaining that search_term is treated literally (regex escaped) and that case-sensitivity emulation uses character classes. This clarifies non-obvious behavior beyond annotations. However, it doesn't mention return format, limit semantics, or how the device parameter scopes the search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single clear sentence plus a two-bullet note list. Every word adds value, and the formatting makes the key caveats easily scannable. Perfectly sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with an output schema and annotations, the description covers the core behavior well. However, it omits how the device parameter works (is it required? what if null?), the expected format of time_filter, and how limit behaves. Given the wide range of sibling log tools, more detail on when this fits would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the burden falls on the description. It sheds light on two parameters (search_term and case_sensitive) with concrete behavioral notes, but leaves limit, device, and time_filter unexplained. This partially compensates for the lack of schema descriptions but still leaves room for ambiguity, especially for time_filter format and device scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Searches log messages for a literal term' clearly states the action, resource (log messages), and the key qualifier 'literal' which distinguishes it from regex-based search siblings. However, it doesn't explicitly differentiate from closely related siblings like get_logs or get_logs_by_severity, and the scope (single device vs all) is left to the device parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives like get_logs, get_logs_by_topic, monitor_logs, or export_logs. The notes about case sensitivity are behavioral rather than decision-oriented, and no explicit when/when-not scenarios are described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds the 'existing' constraint but does not disclose what happens if the interface is not found, how optional parameters are treated, or other behavioral nuances. It adds some value beyond annotations but not substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (12 words) that directly states the tool's purpose. It is front-loaded and free of unnecessary detail, earning a high score for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and annotations, this is a complex mutation tool with 11 parameters and zero schema descriptions. The description provides no context about parameter behavior, edge cases, or usage patterns, making it insufficiently complete for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter details at all. It merely says 'settings' without explaining any of the 11 parameters (name, new_name, vlan_id, interface, etc.), leaving the agent without guidance on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Updates') with a clear object ('existing VLAN interface's settings') and device ('MikroTik'). This distinguishes it from sibling tools like create_vlan_interface, get_vlan_interface, and remove_vlan_interface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'existing' clearly implies this tool is for modifying already-created VLAN interfaces, not for creating new ones. However, it does not explicitly mention alternatives or exclusions, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate non-destructive behavior and closed-world semantics. The description adds the behavioral trait that it 'auto-detects RouterOS v6/v7 syntax', which is useful context. However, it does not disclose other aspects like idempotency, error behavior, or prerequisites. With annotations covering the safety profile, this is a reasonable contribution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the purpose, and the added detail about auto-detection is valuable. No waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations providing safety information, the description does not need to explain return values or side effects. The purpose is clear, and the auto-detection note adds context. However, given the high number of parameters and zero parameter coverage, the description feels incomplete for guiding invocation without relying entirely on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the description provides no parameter information. There are 11 parameters, and the description does not mention even the required 'name' or any optional ones. The schema itself has titles and enums but no descriptions, so the agent gets no additional meaning from the description beyond what the raw schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Creates a wireless interface on the MikroTik device'. It specifies the verb (creates), the resource (wireless interface), and the scope (MikroTik device). It also adds a distinguishing detail about auto-detecting RouterOS v6/v7 syntax, which sets it apart from siblings like create_wireless_security_profile or create_vlan_interface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: the tool is for creating wireless interfaces on MikroTik. This makes it obvious when to use it, but it does not explicitly mention alternatives or exclusions (e.g., when to use update_wireless_interface instead). Thus it has clear context but no exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description provides no additional behavioral context beyond the basic action, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant wording. It is front-loaded with the action and subject, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values are covered. However, the lack of usage guidelines and parameter semantics leaves gaps in understanding when and how to invoke the tool correctly, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description offers no explanation of rule_id or device. While rule_id is somewhat self-evident, the optional device parameter's purpose and behavior are completely unaddressed, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Disables' and clearly identifies the resource 'NAT rule'. This distinguishes it from sibling tools like enable_nat_rule and remove_nat_rule, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the name and description: you use this when you want to disable a NAT rule. However, there is no explicit guidance on when to prefer this over alternatives, nor any mention of reversibility or relationship to enable_nat_rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Annotations already indicate idempotentHint=true and destructiveHint=false, but the description does not explain the effect of disabling, whether it is reversible, or what happens if the peer is already disabled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the core action in the first sentence and parameter notes cleanly separated. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple disable operation, the description covers the essential purpose and the tricky peer_id format. The presence of an output schema and annotations reduces the need for further detail, though usage alternatives are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines peer_id as a string with no formatting details. The description's note explains the accepted formats ('*N' or 'N' from list output), which adds meaningful semantic value. However, the optional 'device' parameter is left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Disables') and a clear resource ('WireGuard peer'), making the tool's purpose unambiguous. It also distinguishes itself from sibling tools like enable_wireguard_peer and remove_wireguard_peer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to disable vs. remove a peer). The description only states what it does, with no mention of prerequisites or contextual use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering safety. The description adds valuable behavioral context by specifying that the file is returned as base64-encoded content and that it handles both backup and export files, which the annotations do not convey. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the primary action and object. It omits unnecessary detail and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the return format is presumably documented. However, the description does not cover parameter semantics or any edge cases (e.g., file not found, permission issues). For a simple download tool, it is minimally adequate but leaves gaps in parameter understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'filename' or 'device' parameters. It only hints at 'backup or export' which maps to the 'file_type' enum, but does not explicitly describe how to use the parameters. The description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Downloads') and the resource ('backup or export file') from the MikroTik device, with an important output detail ('base64-encoded content'). This is specific and distinguishes it from sibling tools like create_backup, upload_file, or list_backups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The intended use is implied—download a file—but there is no guidance about when to prefer this over related operations like create_backup or list_backups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, providing the safety profile. The description adds the peer_id format detail but does not disclose additional behavioral traits such as side effects or prerequisites beyond that. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear one-sentence purpose and a brief, relevant note about the peer_id format. There is zero fluff and the important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and annotated as safe and idempotent, and an output schema exists. The description covers the core action and the required parameter format, but the device parameter is unexplained, and there is no mention of what happens when enabling an already-enabled peer or error cases. Moderate completeness for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful guidance for peer_id, explaining the '*N' format and that it comes from list output. However, the device parameter is not described at all, and with schema description coverage at 0%, the description fails to compensate for the missing semantics of half the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Enables a WireGuard peer' with a specific verb and resource. It distinguishes the tool from siblings like disable_wireguard_peer and create_wireguard_peer, and the note about peer_id format further clarifies the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for enabling WireGuard peers via the tool name and the note that peer_id comes from list output, suggesting a prerequisite to list peers first. However, it does not explicitly state when to use this tool versus alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior, and the description adds useful context: output is an export script, secrets can be hidden, and setting hide_sensitive to false appends show-sensitive. This goes beyond the obvious read-only behavior and clarifies a safety-relevant flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the main behavior, and uses a scannable notes list for parameters. Every sentence adds useful information without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core required parameter$ {section} is illustrated with realistic examples and leading slash guidance is given. An output schema and annotations cover return values and safety. Compact and device are underdocumented but not required for a basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides strong meaning for section with examples and for hide_sensitive with its effect, which is valuable given 0% schema description coverage. However, compact and device are not explained, so the agent must rely on their names, defaults, and context to invoke them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a RouterOS configuration section as an export script, with a specific resource and output format. It does not explicitly distinguish itself from related siblings like create_export or export_dns_config, but the 'section' scope makes the core purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives such as create_export for a full export or export_dns_config for a specific section. The notes explain parameter semantics but do not help an agent choose this tool over its many export-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only nature is covered. The description adds minimal context beyond 'specific' group, without detailing output format, error conditions, or any special behavior. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It effectively conveys the core purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with output schema and annotations, the description is minimally adequate, but it lacks guidance on the optional 'device' parameter and how this tool differs from list_user_groups. It does not explain when to use this vs. listing all groups, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions (0% coverage), and the description does not explain the 'name' parameter or the optional 'device' parameter. It only hints at group identification via 'specific user group,' leaving the agent to infer parameter semantics from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') and resource ('detailed information about a specific user group'), clearly indicating it retrieves details for a single group. This distinguishes it from sibling tools like list_user_groups (which lists all groups) and add/update/remove operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used when a specific user group's details are needed, but it does not explicitly mention alternatives or when not to use it. The presence of list_user_groups suggests a contrast, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds the 'specific user' scope, which is useful but not extensive; it does not mention return format, pagination, or how the device parameter affects the operation. This meets the baseline but adds limited behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word contributes to understanding the tool's core purpose, and it is appropriately sized for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity and has an output schema, so return values don't need explanation. However, the description omits any mention of the device parameter, which is part of the input schema and may be essential in multi-device environments. The required username is implied by 'specific user' but not explicitly mapped. Given these gaps, the description is minimally complete but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. The phrase 'specific user' hints at the required 'username' parameter, but it never names it and completely ignores the 'device' parameter. Without additional detail, the agent cannot determine how to supply parameters correctly, especially the optional device field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Lists') and resource ('SSH keys') with a target ('for a specific user'), making it clearly distinct from sibling tools like remove_user_ssh_key and set_user_ssh_keys. It aligns with the title and annotations, leaving no ambiguity about the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (call when you need to view SSH keys for a user) but provides no explicit guidance on when to use this versus related tools (e.g., get_user, list_users, set_user_ssh_keys). No exclusions or alternatives are mentioned, so the agent gets minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds the 'on the MikroTik device' context but discloses no additional behavioral traits such as pagination, ordering, or filter semantics. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. It contains no unnecessary words or repetition, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 optional parameters and an output schema, but the description only states the basic listing action. It omits mention of filter capabilities (name, VLAN ID, interface, disabled state) which are essential for effective use. The output schema covers return values, but parameter semantics are underspecified, leaving the description incomplete for a moderately complex list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the 5 parameters (device, name_filter, disabled_only, vlan_id_filter, interface_filter), so the description must compensate. It does not explain the meaning or usage of any parameter. Parameter names are somewhat self-explanatory, but the description adds no value beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lists') and the resource ('VLAN interfaces') with context ('on the MikroTik device'). It distinguishes from sibling tools like get_vlan_interface (singular lookup) and create/update/remove VLAN interface operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this tool to list VLAN interfaces. However, it provides no explicit guidance on when to use this versus alternatives (e.g., list_interfaces for all interfaces or get_vlan_interface for a single VLAN), and it does not mention the available filters. The usage context is clear but minimally elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, and the description's 'Removes' is consistent with these. The description adds only a minor detail about the device scope, but does not disclose additional behavioral aspects such as side effects on dependent configurations or whether deletion is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. It contains no redundant information and is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description plus annotations provide the core information. However, the description does not explain parameter semantics or any prerequisites (e.g., whether the server must exist). An output schema exists, so return values are covered separately. Overall, adequate but with clear gaps in parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain the 'name' parameter (the identifier of the DHCP server) or the optional 'device' parameter. The parameter names and titles are minimally self-explanatory, but the description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Removes' with the clear resource 'DHCP server' and scopes it to 'the MikroTik device'. It clearly distinguishes from sibling tools like create_dhcp_server, list_dhcp_servers, and get_dhcp_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you want to delete an existing DHCP server. However, it provides no explicit guidance about when to use this tool versus alternatives (e.g., disabling a server) or any prerequisites/exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, and the description adds context about the target location ('MikroTik device filesystem'). It does not detail irreversibility, wildcard handling, or permission requirements, but the annotation covers the destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is perfectly concise and front-loaded with the core action and resource. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter tool with an output schema and a destructive annotation. The description provides the essential purpose but omits useful context like whether the file is permanently deleted or if the filename must be exact. Overall, adequate but with some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters. The schema titles 'Filename' and 'Device' are somewhat intuitive, but the description adds no additional meaning, so it fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Removes a file') and its target resource ('MikroTik device filesystem'). This is specific and distinguishes it from sibling tools like upload_file or download_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for deleting a file from the device, which is self-evident. However, it provides no explicit guidance on when to choose this over alternatives or any prerequisites/exclusions, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds no further behavioral details such as duration effects, interface requirements, or output characteristics. It is consistent with annotations, so no contradiction, but no extra transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It immediately states the action and key resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and good annotations, so return values and safety are covered. However, parameter semantics are incomplete given 0% schema coverage, and the description does not mention the duration/frequency or any operational context. It is adequate for a simple scan but leaves gaps for the optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter explanations. It only clarifies 'interface' via context but leaves 'device' and 'duration' unexplained. 'Duration' has a default but its purpose is not stated, and 'device' is ambiguous. The description does not sufficiently cover the parameter space.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Scans for nearby wireless networks') and specifies the resource ('using the specified interface'). It distinguishes itself from siblings like get_wireless_registration_table (which reports current registrations) and check_wireless_support (which verifies support).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to scan for networks on a given interface) but provides no explicit guidance on when to choose this tool over alternatives, nor any prerequisites or exclusions. It doesn't mention when not to use it or mention related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations providing idempotentHint and destructiveHint, the description adds no additional behavioral context. It merely restates that it updates an existing entry, which is already obvious from the name. It does not clarify whether unspecified fields are preserved or reset, nor does it mention any side effects beyond the update itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one sentence states the purpose, followed by a notes section with three concise lines for parameter formats. Every sentence earns its place, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (15 parameters, no schema descriptions) and the presence of an output schema, the description is incomplete. It does not explain the meaning of several parameters (e.g., bucket_size, packet_mark, queue, device), does not clarify the role of the required 'name' parameter for identifying the entry, and fails to address whether null values mean 'do not change' or 'clear the field'. The brief notes cover only a fraction of the input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides useful format examples for a subset of parameters: bandwidth units (10M, 512k) for max_limit/limit_at/burst_limit/burst_threshold, duration format (8s) for burst_time, and priority range (1-8). However, this covers only 6 of 15 parameters, and with schema description coverage at 0%, the description does not fully compensate for the lack of schema descriptions for the remaining parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Updates an existing queue tree entry' with a specific verb and resource, and mentions the key modifiable fields (bandwidth limits, parent, priority). This distinguishes it from sibling tools like create_queue_tree, get_queue_tree, and remove_queue_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing queue tree entry, and the word 'existing' indicates it is not for creation. Although it does not explicitly name alternatives like 'create_queue_tree', the context is clear from the sibling set and the verb 'updates'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (only destructiveHint false), so the description carries some burden. It states the core behavior (creates a rule) and adds format notes for certain parameters, but omits behavioral details like default rule placement (e.g., appended to end if place_before is not given) or any validation behavior. This is a partial but incomplete disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single purpose sentence followed by a focused bullet list of four parameter notes. There is no filler or redundant repetition; every sentence serves a distinct clarifying purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 21 parameters and an output schema, the description covers only four parameter clarifications and does not mention important usage context such as default rule positioning or chain semantics. It is enough for basic invocation but not fully complete for a complex tool, especially considering the large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the less obvious RouterOS-specific formats for connection_state, limit, tcp_flags, and place_before, which adds value. However, it leaves 17 of 21 parameters unexplained, some of which like connection_nat_state or device are not fully self-evident, so the compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately states the tool 'Creates a firewall filter rule in the specified chain on the MikroTik device.' This specifies the verb (creates), resource (firewall filter rule), and scope (chain/MikroTik), clearly distinguishing it from siblings like update_filter_rule, remove_filter_rule, and create_nat_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating new filter rules via the verb 'Creates', but it does not explicitly state when to use this tool versus alternatives such as update_filter_rule or remove_filter_rule. There are no exclusions or mention of create_basic_firewall_setup for common setups, so guidance is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description is consistent and adds no extra behavioral context such as side effects or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, read-only annotations, and presence of an output schema, the description is adequate, though it leaves the optional device parameter unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not elaborate on entry_id or device parameters; it only says 'specific' which loosely signals entry_id as the identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Gets details') and the resource ('specific static DNS entry'). This distinguishes it from sibling tools like list_dns_static, add_dns_static, and remove_dns_static.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for retrieving a single entry, but does not explicitly mention when to use it over list_dns_static or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description need not re-state safety. It adds topic examples but no further behavioral details such as pagination, time filtering behavior, or return format. This 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, immediately front-loaded with the action and resource, and contains no filler words. It is appropriately concise for a tool of this simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description does not cover the optional input parameters (limit, device, time_filter) that are part of the input schema. This leaves the agent without enough information to use the tool effectively beyond the required topic, so the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters with 0% description coverage. The description conceptually references 'topic' but fails to explain the meanings or formats of limit, device, and time_filter, which are critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets logs') and identifies the resource as a topic/facility, listing concrete examples (system, dhcp, interface, firewall). This clearly distinguishes it from sibling tools like get_logs_by_severity and search_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a specific topic/facility' provides clear context for when to use this tool: when logs need to be filtered by topic. However, it does not explicitly mention alternatives or when-not-to-use conditions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds 'detailed information' but doesn't disclose error behavior, missing-queue handling, or permission requirements. It is consistent with annotations but adds minimal behavioral context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the verb and object. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only getter with an output schema, so the description need not explain return values. The required 'name' parameter and annotations provide sufficient structural information. It could mention the need for an existing queue tree name, but the schema already communicates this requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate by explaining parameter meanings. It fails to mention that 'name' is the queue tree identifier or clarify the role of 'device'. The description adds no value beyond what the schema's types and required flag already show.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Gets' and resource 'queue tree', clearly distinguishing it from listing, creating, updating, or deleting queue trees. It also emphasizes 'a specific' queue tree, which aligns with the retrieval semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for fetching details about one queue tree, but it doesn't explicitly state when to use it over list_queue_trees or other alternatives. No exclusions or sibling comparisons are mentioned, leaving the usage guidance merely implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, establishing a safe read operation. The description adds no additional behavioral context beyond saying it returns details, so it meets the baseline but does not exceed annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that earns its place. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite minimal description, the tool is simple, with only two string parameters and one required. The annotations confirm read-only and idempotent behavior, and an output schema exists. The description, while terse, is sufficient for an agent to select this tool over its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention the required 'name' parameter or the optional 'device' parameter, leaving the agent without guidance on parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Gets' and the resource 'detailed information about a specific simple queue.' This differentiates it from sibling tools like list_simple_queues by emphasizing a specific queue rather than listing all queues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when you need details about one known simple queue, in contrast to list_simple_queues for enumeration. It provides clear context but does not explicitly state when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds no extra behavioral context such as authentication requirements, rate limits, or side effects. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource, with no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and annotations for read-only behavior. The description plus structured data cover most context. The only gap is the unexplained 'device' parameter, but overall completeness is good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for parameter meaning. It only hints that 'name' identifies the specific user but provides no elaboration on the 'device' parameter. This is insufficient for two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') and resource ('detailed information about a specific user'), clearly distinguishing it from list_users (all users) and get_user_group. It is unambiguous and aligned with the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing details for a specific user (via the term 'specific user'), but provides no explicit when-to-use, exclusions, or alternative tools. Context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint=true and idempotentHint=true, establishing a safe read operation. The description adds only that it returns 'detailed information,' which is minimal extra context. It does not disclose behavior on missing resources or permissions, but given the annotations and output schema, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. There is no redundant wording or unnecessary detail, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read-only getter with an output schema and safety annotations, the description is largely sufficient. It lacks explicit usage guidance and parameter explanation, but these are minor gaps given the tool's simplicity and the rich structured data present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain any parameters. While 'specific VLAN interface' implies the 'name' parameter identifies the interface, it fails to mention the optional 'device' parameter or provide any format/selection details. The description offers only slightly more insight than the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Gets detailed information' on a 'specific VLAN interface.' The verb 'Gets' is a read operation, and referring to a 'specific' interface distinguishes it from sibling tools like list_vlan_interfaces. It unambiguously identifies the resource and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific VLAN interface' implies this tool is for retrieving details on one interface, as opposed to listing all (list_vlan_interfaces) or creating/modifying. However, it provides no explicit guidance on when to prefer this over other 'get' tools (e.g., get_interface) and no alternative names or exclusions. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering safety and idempotence. The description adds minimal behavioral detail beyond that; the peer_id format note is more about parameter syntax than runtime behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single purpose statement plus one compact note. Every word earns its place, with no redundancy or filler. The structure front-loads the main action and then addresses an important input nuance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with an output schema and clear annotations, the description covers the most critical aspect (peer_id format) and the overall purpose. The main gap is the undocumented device parameter, but since it is optional with a default, this is a minor omission. Overall, the description is nearly sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter documentation. It clarifies peer_id format ('*N' or 'N' from list output, e.g., '*2'), which is helpful, but it completely omits the device parameter, leaving one parameter undocumented. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Gets detailed information about a specific WireGuard peer by ID.' The verb 'Gets' and resource 'specific WireGuard peer' distinguish it from sibling tools like list_wireguard_peers, which lists peers. The note about peer_id format further reinforces the specific target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by noting that peer_id comes from list output, suggesting a typical workflow of listing first. However, it does not explicitly mention alternatives or when to use this tool over others, leaving usage guidance largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds some context by explaining the meaning of global and link-local addresses, but does not describe return format, pagination, or other behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single purpose sentence followed by three concise bullet notes. It is front-loaded, free of filler, and every line adds useful information. The structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 optional parameters and an output schema present, the description covers some filtering specifics but leaves several parameters (dynamic_only, disabled_only, interface_filter, device) unexplained. It is adequate for basic usage but not fully complete for all filtering capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains address_filter, global_only, and link_local_only, but omits device, dynamic_only, disabled_only, and interface_filter. While titles give some hints, several parameters remain underdocumented, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Lists IPv6 addresses on the MikroTik device.' The verb 'lists' and resource 'IPv6 addresses' are specific, and the tool is distinguished from siblings like get_ipv6_address (single address) and list_ip_addresses (likely IPv4).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides filtering context (address_filter, global_only, link_local_only) but does not explicitly state when to use this tool versus alternatives like get_ipv6_address or list_ip_addresses, nor does it give exclusions. The usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond annotations by stating that this is a legacy function unsupported in RouterOS v7.x, which is not derivable from the readOnlyHint/idempotentHint annotations. This helps agents avoid calling it on incompatible devices.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that immediately conveys the critical compatibility issue. Every word is purposeful and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description gives the essential legacy/unsupported warning, but it lacks any explanation of what the tool does (relying on the name) and provides no parameter details. Given the output schema exists, return values are covered, but the description is still thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'device' parameter has no schema description and the tool description does not explain its format, allowed values, or whether it is required. With 0% schema coverage, the description provides no compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name clearly indicates a list operation for wireless security profiles, but the description only states it's a legacy function unsupported in RouterOS v7.x, without explicitly describing the action or differentiating from sibling get_wireless_security_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that it is not supported in RouterOS v7.x, providing a clear when-not-to-use condition, though it does not name alternative tools for legacy environments or provide guidance on when it should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe read operation. The description adds minimal context beyond specifying that it returns the Safe Mode active state. It does not disclose any additional behavior (e.g., what happens if device is null), but the annotations carry the burden, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that gets straight to the point. No wasted words or redundancy. It is perfectly concise and front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only status check with annotations covering safety and an output schema available, the description is largely sufficient. The main gaps are the undocumented device parameter and lack of explicit usage guidance, but these are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional 'device' parameter with no description, and schema description coverage is 0%. The description does not mention or explain the device parameter at all. Since the description must compensate for low schema coverage and fails to do so, the parameter semantics are unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and identifies the exact resource ('whether MikroTik Safe Mode is currently active'). This clearly distinguishes it from sibling tools like enable_safe_mode, commit_safe_mode, and rollback_safe_mode, which perform different actions on Safe Mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking Safe Mode status, but it does not explicitly state when to use this tool versus alternatives. Given siblings like enable_safe_mode/commit_safe_mode/rollback_safe_mode, it would benefit from guidance such as 'Use this to check Safe Mode state before committing or rolling back.' The context is clear but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false, and the description adds useful behavior such as passing an empty string to clear optional fields, disclosing the behavior for unspecified fields. This goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and uses bullet notes for key parameter formats. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and annotations, the description is incomplete for a tool with 21 parameters. It fails to explain the majority of parameters and lacks usage context, leaving the agent to guess meaning for fields like log_prefix or connection_nat_state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only explains 4 of 21 parameters (rule_id, connection_state, limit, tcp_flags). Most parameters like chain, src_address, dst_address, and connection_nat_state have no added meaning beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Updates an existing firewall filter rule') that precisely identifies the tool's function. It clearly distinguishes from sibling tools like create_filter_rule, remove_filter_rule, and update_nat_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for existing rules ('Updates an existing firewall filter rule') but does not explicitly state when to use it over alternatives or mention any exclusions. No alternative tools are referenced, so the guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations by explaining route_id format, dst_address CIDR, check_gateway allowed values, distance range, and that passing "" clears specific fields. Annotations already mark it as idempotent and non-destructive, and the description does not contradict them. It doesn't disclose side effects, but the added parameter behaviors are useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single opening sentence followed by bulleted parameter notes. Every line earns its place, and the structured format makes it easy to scan. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the required parameter and several key update fields, and the output schema plus annotations provide additional context. However, for a tool with 13 parameters, several remain undocumented, so the agent may not know how to set target_scope, comment, or other options. This is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining route_id, dst_address, check_gateway, distance, and three clearable fields (routing_mark, vrf_interface, pref_src). However, it leaves scope, device, comment, gateway, disabled, and target_scope unexplained, covering roughly half of the 13 parameters. This partial coverage is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Updates a route' with a specific verb and resource, and the name 'update_route' distinguishes it from siblings like add_route, remove_route, and get_route. It doesn't explicitly enumerate all updatable fields, but the notes provide additional context, making the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for modifying an existing route but provides no explicit when-to-use guidance or alternatives. It doesn't mention that add_route should be used for creation or remove_route for deletion, leaving the agent to infer usage from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that changes are committed to persistent storage and Safe Mode is exited, but it does not disclose the important behavioral consequence that committed changes become permanent and cannot be rolled back. The annotations (destructiveHint=false) don't cover this inherent risk, so the description leaves a transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the main action and its outcome. No filler or repetitive content; every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description adequately states what it does. However, it omits prerequisites (e.g., being in Safe Mode) and consequences (irreversible commit), which are relevant for safe invocation. Given the sibling 'rollback_safe_mode', a brief note on when to choose which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'device' has no schema description (0% coverage), and the description provides zero information about it. Since schema coverage is low, the description must compensate, but it doesn't. The agent has to guess what 'device' refers to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'commits' with a clear resource ('all pending Safe Mode changes') and states the exit behavior. It clearly distinguishes from sibling 'rollback_safe_mode', which would discard changes instead of persisting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: when there are pending Safe Mode changes that should be made permanent. It doesn't explicitly name 'rollback_safe_mode' as the alternative, but the context makes the usage obvious. A more direct comparison would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate destructiveHint=false and openWorldHint=false, providing a baseline safety profile. The description adds the input format for 'ranges' (hyphen-separated, comma-separated), which is behaviorally relevant, but does not disclose potential side effects like existing pool conflicts or auth requirements. Given annotations cover the basic safety traits, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and includes a compact note on the 'ranges' format. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple create operation, and an output schema is present, so return values need not be described. The description covers the main input nuance (ranges format), but leaves the 'next_pool' parameter undefined and doesn't mention any prerequisites or device context. It is adequate for a straightforward tool but has noticeable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'ranges' parameter format in detail, but offers no semantics for the required 'name' or optional 'device', 'comment', and 'next_pool'. Since half the parameters remain unexplained, the description only partially fulfills the compensation role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Creates an IP pool') and the target resource ('on the MikroTik device'). It is specific and distinguishes the tool from sibling tools like 'list_ip_pools', 'update_ip_pool', and 'remove_ip_pool'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly defines when to use the tool (when needing to create an IP pool). It provides no explicit exclusions or alternatives, but the context is clear enough for an agent to select it over read/update/delete siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the description need not restate these. The description adds the route_id format note, which is useful but more about parameter semantics than behavioral traits. No additional behavioral context (e.g., reversibility, state requirements) 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single clear action sentence and a brief parameter note. Every word earns its place, and it is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with an output schema and adequate annotations, the description covers the core action and the critical route_id format. It does not explain the device parameter or provide usage alternatives, but the overall completeness is sufficient for a straightforward disable operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameters. It does explain route_id format ('*N' or 'N' from list output), which is helpful for the required parameter. However, the optional device parameter is left ambiguous, and the description only partially compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Disables a route' uses a specific verb and resource, clearly distinguishing it from siblings like enable_route, remove_route, and update_route. It also adds a note about route_id format, reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you want to disable a route) but does not explicitly mention alternatives or exclusions. There is no guidance on when to prefer this over enable_route or remove_route, leaving usage to be inferred from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint and idempotentHint, so the read-only nature is covered. The description adds the requirement of an exact name but provides no additional behavioral context like error handling or return behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two lines: a clear main sentence and a focused note about name format. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with an output schema, the description is largely sufficient: it states purpose, product scope (interface), and name format. It omits device param explanation and alternative-tool guidance, but overall is complete enough for common use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does explain the name parameter with exact format examples ('ether1', 'bridge', etc.) but fails to clarify the optional device parameter. This is partial compensation for one of two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Gets detailed information about a specific interface by name' — a specific verb and resource. It distinguishes itself from sibling list/get tools by focusing on a single named interface, though it doesn't explicitly differentiate from type-specific getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need details for a known interface name, as shown by examples. It doesn't provide explicit guidance on when to use this instead of get_vlan_interface or get_wireless_interface, or mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, indicating a safe read operation. The description adds value by explaining the rule_id format with examples ('*1' or '0'), which is critical for correct invocation and not present in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—one sentence plus a focused note about rule_id format. Every sentence provides useful information, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with an output schema and read annotations, the description covers the key behavioral nuance (rule_id format). The only gap is the undocumented device parameter, but the tool is otherwise adequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies the rule_id parameter with format examples, but the optional 'device' parameter is not explained. This partial compensation warrants a moderate score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Gets detailed information about a specific NAT rule', identifying the verb, resource, and scope. It distinguishes from sibling 'list_nat_rules' by emphasizing 'specific', but doesn't explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note 'use the ID from list output' implies a prerequisite that the agent must first list NAT rules to obtain a valid ID, providing implied usage context. However, it doesn't explicitly state when to prefer this over list or other NAT rule tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description does not need to repeat that. It adds the route_id format clarification, but does not disclose other behavior like error cases or whether the route must exist. It neither confirms nor contradicts annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear main sentence and a separate note that is directly useful. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and read-only/idempotent annotations, the description is largely complete for a simple get operation. It provides the required parameter format, but could benefit from a brief mention of device usage or distinguishing from get_routing_table.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the route_id parameter format ('*N' or 'N' from list output) which compensates for the 0% schema coverage for that parameter. However, the device parameter is completely unexplained in both schema and description, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Gets') and resource ('detailed information about a specific route'), distinguishing it from list-oriented siblings like list_routes and get_routing_table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note about route_id coming 'from list output' provides context that the user should first list routes, but it does not explicitly contrast with alternatives such as get_routing_table or list_routes. There is no when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate those. It adds useful context about the specific log types covered (logins, failures, blocked connections), enhancing clarity beyond the annotations. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no unnecessary words. It is front-loaded with the core purpose and examples, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need not be described. However, parameter behavior is entirely unexplained, and with three optional parameters and many sibling log tools, the description is incomplete for proper invocation. It does not mention how parameters affect results or clarify filtering behavior, so it is minimally acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for the parameters. However, it does not mention any of the three parameters (limit, device, time_filter) or their roles. The description provides no added value for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves security-related log entries and gives specific examples (logins, failures, blocked connections). It uses a specific verb-resource pair and is easily distinguished from generic log tools like get_logs or search_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for security logs but does not explicitly state when to use it over alternatives like get_logs_by_topic or search_logs. No when-to-use or when-not-to-use guidance is provided, which could be ambiguous given many log retrieval siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as destructive and idempotent, which aligns with the description's 'Removes'. However, the description adds no further context about behavior, such as what happens if the address is not found, whether the operation succeeds silently, or whether device context is required. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, an output schema exists, and annotations cover safety, the description provides an adequate overview. It lacks only minor details like the meaning of 'address value' and the role of 'device', but overall the description is sufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds the valuable hint that the lookup can be by 'ID or address value', clarifying the role of address_id. However, it leaves the optional 'device' parameter unexplained, and there is potential ambiguity between 'address_id' and 'address value'. The description partially compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('Removes'), the resource ('IP address from the MikroTik device'), and the selection method ('by ID or address value'). It is distinct from sibling tools like add_ip_address and list_ip_addresses, and the existence of a separate remove_ipv6_address underscores that this tool is for IPv4 addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case (removing an IP address) but provides no explicit guidance on when to choose this tool over alternatives, nor does it mention any preconditions or side effects. There is no exclusion or mention of related tools such as remove_ipv6_address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, which tell the agent the operation is destructive and retry-safe. The description adds only the peer_id format note, which is more about parameters than behavior. It does not disclose side effects like disconnecting the peer or irreversibility, but the annotations carry that burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and includes a concise, relevant note about the required parameter. Every word earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool with strong annotations (destructive, idempotent) and an output schema, the description covers the essential action and the critical peer_id format. It lacks explanation of device param and error/edge cases, but these are not severe gaps given the tool's simplicity and structured annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add value for peer_id by explaining its format ('*N' or 'N' from list output, e.g., '*2'), which is essential for correct use. However, the optional 'device' parameter is not mentioned at all, leaving that gap unfilled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Removes') and resource ('a WireGuard peer from the MikroTik device'), clearly distinguishing this from sibling tools like add_wireguard_peer, get_wireguard_peer, update_wireguard_peer, and enable/disable_wireguard_peer. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you want to permanently delete a WireGuard peer. However, it does not explicitly state when to prefer removal over disabling (disable_wireguard_peer exists as a sibling), nor any preconditions like 'peer must exist' or 'this will terminate active sessions'. Usage is clear but not actively guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the non-obvious behavioral detail that the operation 'triggers a reboot,' which goes beyond the annotation's destructiveHint. It does not mention that current configuration is overwritten, but the concept of 'restore' combined with reboot provides useful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the primary action and a critical side effect. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is destructive and triggers a reboot, but the description doesn't explain that the current configuration will be replaced or that network access may be temporarily lost. Mentioning the reboot is good, but a bit more context about the impact of restoring would improve completeness. Since an output schema exists, return values are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. It gives no hints about 'filename', 'device', or 'password', which are all undocumented. The description fails to compensate for the lack of parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Restores a system backup on the MikroTik device' and adds the notable consequence 'triggers a reboot.' This effectively distinguishes it from sibling backup tools like create_backup, list_backups, and backup_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for restoring an existing backup. It does not explicitly mention alternatives or when not to use it, but the verb 'restores' and the specific resource (system backup) make the usage context obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds parameter format details (e.g., '10M/10M', '8s', priority range) but does not disclose additional behavioral traits like immediate effect or permission requirements. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured: a single sentence stating the core purpose followed by bulleted notes for key parameter formats. No redundant words; every line provides useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 17 parameters, but the description only addresses a handful of them. Important fields like dst, queue, parent, and packet_marks are not explained, nor is the required 'name' parameter highlighted. While the output schema and annotations cover some context, the description leaves significant gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains formats for target, bandwidth fields, burst_time, and priority, which is genuinely helpful. However, it leaves many other parameters (dst, queue, parent, bucket_size, packet_marks, etc.) unexplained, providing only partial compensation for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing simple queue's rate limits, target, or scheduling settings. The verb 'updates' plus the resource 'existing simple queue' makes the purpose immediate and distinguishes it from sibling tools like create_simple_queue or remove_simple_queue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing simple queue' implies this tool is for modifying already-created queues, not for creating new ones. It doesn't explicitly name alternatives, but the context is clear enough for an agent to decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only and idempotent. The description adds specific context about what the tool reports (RouterOS version and interface type), which is valuable beyond the annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. Every word adds value, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only check with annotations and an output schema, the description adequately covers purpose and output. It could mention the device parameter's default behavior, but this is a minor gap for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional 'device' parameter, but schema description coverage is 0%. The description does not explain the parameter's meaning, format, or default behavior. The parameter name is self-explanatory but lacks necessary details for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking wireless support and reporting RouterOS version and wireless interface type. This distinguishes it from sibling tools like get_wireless_interface which manage existing interfaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The intended use case (pre-configuration support check) is implied by the name and description, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds useful scope by specifying the aggregation by topic and severity, but it does not disclose additional behavioral details like time ranges or numeric limits. This aligns with the calibration example where annotations cover safety and the description adds mild context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the core function without any extraneous information. It is well-structured and front-loaded, earning full marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema, so the description need not explain return values. It covers the essential purpose and differentiates from siblings, though it omits potential details like whether counts are time-bounded. Given the low complexity, the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional 'device' parameter with no description (0% schema coverage), and the description only vaguely references 'the MikroTik device' without explaining the parameter's meaning, default behavior (null), or accepted values. The description fails to adequately compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Gets log entry counts by topic and severity from the MikroTik device,' which specifies a concrete verb and resource and distinguishes it from sibling tools like get_logs, get_logs_by_severity, and get_logs_by_topic by emphasizing aggregated counts rather than raw log entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for log statistics rather than raw logs, providing clear context for when it should be used. However, it does not explicitly name alternatives or state when not to use them, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already mark the operation as destructive and idempotent, the description adds meaningful behavioral context by noting the failure condition when the pool is in use. It also clarifies the target environment (MikroTik device). This goes beyond the structured annotations and provides an important edge case for the agent to consider.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core action and a key constraint. It is front-loaded with the verb and resource, contains no filler, and is easy to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite its brevity, the description covers the essential behavior (removing an IP pool) and the most important caveat (fails if in use). The existence of an output schema likely covers return values, and the two parameters are simple enough that their roles are somewhat inferable. However, the lack of guidance on the 'device' parameter and when to use the tool relative to alternatives leaves a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meanings, but it does not. It does not explain that 'name' identifies the IP pool or clarify the role of the optional 'device' parameter. The description only says 'an IP pool' generically, leaving the agent to infer the mapping between arguments and their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Removes an IP pool') and the target resource ('from the MikroTik device'), making it obvious that this tool deletes IP pools. It is distinct from sibling tools like remove_ip_address or remove_dhcp_server, and the name aligns perfectly with the described behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'fails if pool is in use' implies a precondition for use, suggesting that users should not attempt removal when the pool is active. However, it does not explicitly state when to use the tool or mention alternatives like checking usage via list_ip_pool_used or updating the pool instead. The usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds key behavioral context beyond annotations: it explains the mechanism (closing the SSH session) and the consequence (all pending changes are discarded). This is valuable because the annotations (openWorldHint=false, destructiveHint=false) do not specify these details. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and mechanism. Every word earns its place, and it avoids redundancy or padding. Ideal size for a simple one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and an output schema, the description covers the core effect and side effect (SSH session close). It explains the operation sufficiently, though it could have briefly noted the device parameter's purpose or when safe mode must be active. Overall, it is complete enough given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'device' with 0% schema description coverage. The description does not mention this parameter at all, leaving the agent to infer its meaning from the parameter name alone. With such low coverage, the description should have compensated but did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Discards all pending Safe Mode changes' with a specific mechanism. The verb 'discards' and resource 'pending Safe Mode changes' distinctly define the operation, and it differentiates from siblings like commit_safe_mode and safe_mode_status by focusing on rollback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you want to discard pending Safe Mode changes rather than commit them. However, it does not explicitly state when not to use this tool or mention alternatives like commit_safe_mode. The context of Safe Mode is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the description only needs to add extra context. It does so by specifying the exact format for ranges and how to clear next_pool by passing an empty string. These details are useful and go beyond what annotations provide, though it doesn't explicitly state that omitted fields are left unchanged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with a clear purpose line. The notes are compact and contain only essential formatting details. No redundant or filler content exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with an output schema, the description covers only a subset of parameters (ranges and next_pool) and omits clarification on new_name vs name, comment, and device. It does not explain the update semantics for omitted fields or how to reference the pool by name. The presence of an output schema reduces the need to describe return values, but the parameter coverage remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate. It explains two tricky parameters: ranges (with hyphen and comma-separated examples) and next_pool (clearing semantics). However, it does not explain new_name, comment, device, or the required name parameter, leaving significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Updates an existing IP pool's name, ranges, or next-pool reference,' using a specific verb and resource. It distinguishes this from sibling tools like create_ip_pool, remove_ip_pool, and get_ip_pool by explicitly targeting updates to existing pools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this tool is for modifying an existing IP pool. However, it does not explicitly state when to choose this over create_ip_pool or remove_ip_pool, nor does it mention any prerequisites or exclusions. The notes focus on parameter formatting rather than usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true and destructiveHint=false, so the agent knows it's a safe, non-destructive operation. The description adds that it 'appends' ranges, and the notes clarify the exact format for ranges. It doesn't mention validation or failure modes but largely complements the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear main sentence and a useful note section. The examples are valuable and not overly verbose. Slight redundancy in the notes (the first line is repeated in bullet format) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need not be described. The tool is simple with 3 params, and the description covers the key nuance of range formatting. Missing info on the 'device' parameter's optionality, but the schema handles that. The sibling list shows related IP pool tools, but the description doesn't explicitly compare to them; still adequate for a low-to-medium complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden. The description explains 'additional_ranges' with concrete hyphen-separated and comma-separated examples, which is essential. However, 'name' and 'device' are not described at all; the context implies name is pool identifier, but no explicit semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool expands an existing IP pool by appending additional address ranges, with an explicit verb ('expands') and resource ('IP pool'). It distinguishes itself from create_ip_pool/remove_ip_pool by focusing on expansion, though it doesn't explicitly name siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need to add ranges to an existing pool, not create a new one. However, it does not explicitly say when not to use it or provide alternatives. The note about format gives practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; description adds that it does not communicate with the router, a useful offline-behavior trait beyond the safety hints. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, immediate statement of action, no fluff. The offline note is valuable and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return format is covered. However, the 9-param tool has no parameter-level explanation; the description gives high-level behavior but not enough for an agent to confidently fill in all params. Given the simplicity of the operation, this is a minimal viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and description only references 'keys and server endpoint', leaving five of nine params (including client_address, dns, device, allowed_ips, server_port, persistent_keepalive) unexplained. The description does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'generates' plus specific resource 'wg0.conf client config string' and inputs 'keys and server endpoint'. Distinguishes from router-communication tools by explicitly noting it does not communicate with the router.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this is an offline generation tool vs. router-modifying tools. Does not explicitly name alternatives or conditions, but the 'does not communicate' line implies a boundary and makes the use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. The description adds useful context around rule_id interpretation, but it does not disclose additional behavioral details such as error handling, authorization, or potential side effects—though none are expected for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and every sentence carries meaning. The main purpose is stated first, and the only supplementary note is directly about the required parameter. There is no redundant or meandering text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, safe read operation with an output schema available, this description is largely complete. It covers the required parameter and points toward list output. The only notable gap is the lack of explicit guidance about how to select or use the optional device parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well for the required rule_id parameter by explaining positional numbers versus internal IDs with examples. The optional device parameter remains only partially documented in the schema, which keeps this from a full score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'Gets detailed information about a specific firewall filter rule.' The verb–resource pair is clear, and 'specific firewall filter rule' distinguishes it from list_filter_rules and from the get_nat_rule sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for retrieving a single filter rule by rule_id, and the note about 'list output' hints that list_filter_rules should be consulted first. However, it does not explicitly name alternatives or provide exclusion cases, so the guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only nature is covered. The description adds useful context by clarifying that it returns all interface types and by explaining the filter behavior. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by a compact, well-formatted notes section. Every sentence/note adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with an output schema and safe annotations, the description covers the main purpose and two key filter parameters. Minor gaps (running_only/disabled_only) are mitigated by schema defaults/titles, and no side effects need disclosure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema-description coverage is 0%, but the description's Notes section adds meaning for type_filter and name_filter with examples and partial-match semantics. However, it does not explain device, running_only, or disabled_only, leaving some parameters without descriptive guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Lists all interfaces on the MikroTik device' and enumerates many interface types, ending with 'any other type'. This clearly differentiates it from sibling type-specific list tools like list_wireless_interfaces or list_vlan_interfaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies general-purpose use through 'all interfaces' and 'any other type', but it does not explicitly state when to use this tool instead of a type-specific sibling or mention exclusions. The filter notes provide some usage context but not alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by specifying the exact command run ('/interface ethernet poe print') and clarifying the scope ('PoE-capable ethernet interfaces'), along with the partial match behavior of interface_filter. This supplements the safety profile without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose statement, the underlying command for technical reference, and a focused note on the key parameter. No wasted words; important details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple list operation with only two optional parameters, an output schema, and strong annotations (read-only, idempotent), the description is mostly complete. It covers the purpose, the command, and the main parameter nuance. The only minor gap is the unexplained 'device' parameter, but it is common across sibling tools and not central to the PoE-specific functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to compensate. It does a good job for interface_filter, explaining partial match behavior with an example ('ether' matches ether1, ether2 …). However, the 'device' parameter is left undocumented, leaving a gap in parameter understanding for users.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Lists the Power-over-Ethernet (PoE) configuration of PoE-capable ethernet interfaces', naming the specific resource (PoE config) and fields (PoE-out mode, priority). This distinguishes it from sibling tools like get_poe_monitor and get_poe_settings, which are about monitoring and settings rather than configuration listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving PoE configuration information, but it does not explicitly state when to use it versus alternatives or provide exclusions. The note about interface_filter gives usage context for that parameter, but there is no direct comparison with related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, covering the basic safety profile. The description adds practical guidance about rule_id format but does not disclose additional behavioral traits such as error handling, effects of invalid positions, or whether the operation is reversible. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences plus bullet-like notes for parameter semantics. It is front-loaded with the primary action and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple move operation with an output schema present, the description covers the essential parameter semantics and provides clear operational guidance. It omits edge-case behavior and does not describe the device parameter, but the overall completeness is strong for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It meaningfully explains rule_id (use ID from list output, e.g., '*1' or '0') and destination (0-based index), far beyond the raw schema. Device is not mentioned, but it is optional and appears to be a common parameter across sibling tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Moves a NAT rule to a different position in the chain' with a specific verb and resource. This distinguishes it from sibling tools like move_filter_rule, getting NAT rules, or updating NAT rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for reordering NAT rules, but it does not explicitly state when to prefer this tool over alternatives or mention exclusions. It provides no comparative guidance relative to the many sibling tools, so usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is established. The description adds minimal behavioral context beyond that—it notes that rule_id should be from list output, which implies the rule must exist. It does not contradict annotations, but it also does not elaborate on irreversibility or error behavior, which annotations already partially cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one action sentence plus a focused note. The note is structured as a bullet point for readability and front-loads the key information about rule_id. No wasted words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple removal operation with only one required parameter, the description covers the essential task, the parameter source, and the device context. An output schema exists, so return value details are unnecessary. It lacks explicit mention of prerequisites (rule must exist) or post-removal effects, but annotations and the note about list output provide enough context for a capable agent. Slight gap in not explaining what happens for a nonexistent rule, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does exactly that for the required parameter rule_id, specifying the format (e.g., '*1' or '0') and its source ('use the ID from list output'). The optional device parameter remains undocumented, but it is a standard optional parameter across sibling tools and less critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Removes a firewall filter rule from the MikroTik device.' This clearly distinguishes it from sibling tools like enable_filter_rule, disable_filter_rule, update_filter_rule, and move_filter_rule, which operate on the same resource but perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys when to use the tool: when you need to remove a firewall filter rule. It provides a useful note on sourcing rule_id from list output, but it does not explicitly mention alternatives or when NOT to use this tool (e.g., consider disable_filter_rule for temporary deactivation). No direct comparison with sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the destructive nature is known. The description adds context about the flexible address_id format (internal id or address value) and implies the operation is a removal, but it does not disclose additional behavioral traits such as configurability, dependencies, or what happens to the address if it is in use. This is acceptable given the simple operation and annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It starts with a clear one-sentence purpose statement, then provides a focused note on the address_id parameter. Every sentence carries useful information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of a removal tool with a single required parameter, the description adequately covers the essentials: what it does and how to specify the target. The output schema exists, so return values are covered by structured data, and annotations address safety. It doesn't mention error scenarios or side effects, but for a straightforward destructive operation, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds valuable meaning for the address_id parameter by explaining it can be either a RouterOS internal id (e.g., '*1') or an address value (e.g., '2001:db8::1/64'). However, it does not explain the optional device parameter, and with schema description coverage at 0%, it only partially compensates for the lack of property descriptions. The address_id clarification is helpful but the device parameter remains semantically undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Removes an IPv6 address from the MikroTik device by ID or address value.' This specifies the verb, resource (IPv6 address), and scope (MikroTik device), and distinguishes it from the sibling tool remove_ip_address (which targets IPv4) by explicitly mentioning IPv6.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it removes an IPv6 address and explains how to identify the target (by ID or address value). It does not explicitly mention when not to use this tool or provide alternatives, but the purpose is unambiguous enough that the usage scenario is clear without further guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the agent is aware of the destructive nature. The description adds a route_id format note but does not disclose other behavioral details such as reversibility or impact on related resources. It aligns with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two brief sentences with a focused note. It is front-loaded with the purpose and includes essential parameter guidance without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and a simple two-parameter tool, the description covers the critical route_id semantics and the action. It could be more complete by explaining the device parameter or explicitly stating that list_routes should be used to obtain valid IDs, but overall it is fairly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no property descriptions (0% coverage), and the description compensates with a substantial note on route_id format ('*N' or 'N' from list output). However, the optional 'device' parameter is not described, so the compensation is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes a route using a specific verb and resource. It distinguishes from sibling remove tools by naming the resource type directly (route), and the note about route_id format adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note 'from list output' implies the route_id should come from list_routes, providing contextual usage guidance. However, it does not explicitly state when to use this tool over alternatives like update_route or enable_route, nor does it mention prerequisites beyond obtaining the route_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-destructive and not open-world, but the description adds crucial behavioral details: changes are held in memory, auto-reverted on disconnect, and remain pending until committed. This goes beyond the structured data and gives the agent a clear understanding of the tool's stateful implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main action ('Activates') and packs essential details (memory, auto-revert, commit) without any wasted words. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple activation tool, the description covers the core purpose and the primary safety behavior. However, it omits guidance on the 'device' parameter and does not explicitly connect to sibling tools like commit_safe_mode or rollback_safe_mode, leaving slight gaps for an agent invoking the tool in a broader workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema shows a single optional 'device' parameter with zero description coverage, and the tool description does not mention this parameter at all. The agent is left without any guidance on what the parameter represents or how to populate it, so the description fails to compensate for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with the specific verb 'Activates' and names the exact resource ('MikroTik Safe Mode'), making the tool's purpose clear. It also distinguishes itself from sibling tools like commit_safe_mode and rollback_safe_mode by explicitly stating it activates the mode, while the 'until committed' clause hints at the associated workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: before making changes, with the safety net of auto-revert on disconnect. It does not explicitly name alternatives (e.g., commit_safe_mode or rollback_safe_mode) or provide exclusions, but the context is sufficiently clear for an agent to understand the intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, and the description adds the 60-second duration cap and limited duration behavior. This is consistent with annotations and adds useful context, though it doesn't disclose further details like timeout behavior or output format (which is covered by output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and includes a concise note for the duration parameter. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and annotations, so the description need not explain returns. However, it does not clarify the function of device and topics parameters, which are likely relevant for filtering logs. For a monitoring tool, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate for parameters. It explains only 'duration' with a cap, but leaves 'device' and 'topics' unexplained. This adds some value but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool watches for new log entries for a duration, which is a specific verb+resource+scope. It clearly distinguishes from sibling log tools like get_logs and search_logs by focusing on new/realtime entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for monitoring new logs, with a clear duration cap. It does not explicitly mention alternatives or when not to use, but the purpose is clear enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds valuable behavioral context by explaining how to clear optional fields with an empty string (""), which implies that omitted fields retain their current values. This goes beyond the structured annotations and clarifies partial-update semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: a one-sentence purpose followed by concise bullet-point notes for key parameters. Every sentence adds value, with no irrelevant information or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (17 parameters) and minimal schema descriptions, the description could be more complete. It does not explicitly state that only provided fields are updated, nor does it mention error behavior for nonexistent rule IDs. The clearing instruction is helpful but a brief note on partial-update semantics would make it more robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema description coverage, the description compensates by explaining the format for rule_id, to_addresses, and to_ports (e.g., single IP or range). However, it covers only 3 of 17 parameters, leaving many optional fields (like chain, action, protocol) unexplained. The general rule about clearing fields with "" adds some value, but overall parameter guidance is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Updates an existing NAT rule on the MikroTik device.' The verb 'Updates' paired with 'existing' distinguishes it from related sibling tools like create_nat_rule, remove_nat_rule, enable_nat_rule, and disable_nat_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by emphasizing 'existing NAT rule' and instructing to use the 'ID from list output' for rule_id. This gives clear context for updating existing rules, though it does not explicitly name alternatives or state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotent and non-destructive behavior, so the description adds value with details on clearing fields and peer_id format. However, it does not disclose whether updates are partial (only provided fields) or full replacements, nor does it mention all updatable fields like comment and endpoint_port.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: a single clear purpose statement followed by focused parameter notes. Every sentence adds value, no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter mutation tool with no schema descriptions, the description is only partially complete. It explains key parameters well but omits endpoint_port, comment, device, and the semantics of partial updates. This leaves room for incorrect invocation without further research.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well for several parameters: peer_id ('*N' format), allowed_address (CIDR examples), persistent_keepalive (seconds as string), and clearing endpoint_address/preshared_key. It misses format guidance for endpoint_port and mapping for disabled, but the essential tricky parameters are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Updates'), the resource ('existing WireGuard peer'), and the specific attributes that can be modified (allowed addresses, endpoint, keepalive, enabled state). This clearly distinguishes it from sibling tools like create/remove/list peers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for modifying existing peers, not creating new ones, and provides practical formatting guidance for several parameters. However, it does not explicitly compare with sibling tools like enable_wireguard_peer or disable_wireguard_peer, which could also alter the enabled state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds behavioral value by explaining that address_id can be either an internal RouterOS ID or the address value, which is beyond what the schema provides. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: a one-sentence summary followed by a clearly formatted note. Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with an output schema and strong annotations, the description is nearly complete. It covers the main lookup method and parameter semantics, with only a minor gap around the device parameter. The existence of an output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain the key parameter address_id with examples, which is valuable. However, the optional device parameter is not described at all, leaving a gap for one of the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Gets' with the resource 'detailed information about a specific IPv6 address', and states the lookup by 'ID or address value'. This clearly distinguishes it from sibling tools like list_ipv6_addresses (listing) and get_ip_address (IPv4).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear that this tool is for retrieving a single IPv6 address's details, implying it should be used when you need specific info rather than a list. It also gives concrete guidance on how to specify address_id (RouterOS ID or address value). It does not explicitly mention alternatives or anti-conditions, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, so the description is not required to repeat that. It adds valuable context by revealing the underlying command ('/interface ethernet poe monitor ... once'), which clarifies that 'monitor' is a one-shot read rather than a continuous stream. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It leads with a clear purpose, then provides the command, and finally a note on parameter formatting. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and annotations cover safety and idempotency, the description covers the essential context for using the tool: what it does, the command it runs, and interface formatting. The only gap is the undocumented 'device' parameter, but this is a minor omission given the overall clarity and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It does explain the 'interfaces' parameter with format and examples, which is helpful. However, it completely omits the optional 'device' parameter, leaving it undocumented. Thus the description only partially covers the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Reads'), the resource ('Power-over-Ethernet monitor data'), and the target ('ethernet interfaces'). It also lists the specific data points (PoE-out status, voltage, current, power), making it easy to distinguish from sibling tools like get_poe_settings and list_poe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to read real-time PoE monitor data for specified interfaces. It even notes the one-shot execution ('once'). However, it does not explicitly mention alternatives or when not to use it, so it lacks the explicit exclusions needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safe read nature is covered. The description adds the exact CLI command executed and notes the name must be exact, which is useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, command, and parameter note. Each sentence contributes essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be described. The tool has only two parameters, and the main required one is well explained. The optional 'device' parameter is not addressed, but this is a minor gap given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It clarifies the required 'name' parameter with an example ('ether1') and exact-match requirement, but the optional 'device' parameter is not explained. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed PoE-out settings for a specific ethernet interface, listing example fields (mode, priority, voltage, thresholds). It uses a specific verb-resource pairing and distinguishes itself from siblings like get_poe_monitor and list_poe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for a specific interface and provides the underlying command, implying it should be used when detailed settings of one interface are needed. However, it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by explaining parameter-specific behaviors: address format when using from_pool, default for advertise, and the meanings of eui_64 and no_dad. Annotations already declare non-destructiveness, and no contradiction is present. It does not discuss broader side effects, but the added parameter behavior is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and uses structured notes for parameter details. Every sentence provides useful information without redundancy, making it easy for an agent to parse and apply.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, the description provides essential details for the non-obvious parameters while the output schema likely covers return values. It lacks explanation for some generic parameters like disabled and comment, but the guidance is sufficient for successful invocation in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the schema has 0% description coverage, the description compensates by explaining the format and semantics for key parameters (address, advertise, eui_64, from_pool, no_dad). It leaves device, comment, disabled, and interface undocumented, but the covered parameters are the most critical for correct use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Adds') and a clear resource ('IPv6 address to an interface on the MikroTik device'), making its function explicit. It also distinguishes itself from sibling tools like list_ipv6_addresses, get_ipv6_address, and remove_ipv6_address by clearly indicating the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the tool's function, so when to use it is obvious. However, it does not explicitly mention alternatives or exclusion conditions, such as 'use add_ip_address for IPv4.' The context is clear but lacks explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds parameter-specific notes about rule_id format ('*1' or '0') and destination being 0-based, which complements the annotations (idempotentHint=true, destructiveHint=false). It does not contradict annotations. It does not go deeper into side effects, but with annotations present, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences plus a compact bullet-like Notes section. Every line adds value; no filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the operation and its two required parameters. Since an output schema exists, return value descriptions are unnecessary. It even tells the user where to obtain rule_id ('from list output'). For a simple move operation with good annotations, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% in the description text, but the description's Notes section provides concrete examples and semantics for both required params: rule_id uses list output IDs like '*1' or '0', destination is a 0-based index. This goes well beyond the schema's minimal titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Moves' and identifies the resource 'firewall filter rule' and action 'to a different position in the chain'. This clearly distinguishes it from sibling tools like update_filter_rule (edits properties) or remove_filter_rule (deletes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit alternatives or when-not-to-use are mentioned. The description implies usage via the verb 'Moves' and parameter notes, but it does not contrast with move_nat_rule or explain when to use this versus update_filter_rule. Context is understandable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable context: it explicitly states 'Credentials are never returned,' which is a meaningful behavioral disclosure beyond the annotations. It also indicates the returned data is device titles, providing more transparency about output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded with the primary purpose. The second sentence elaborates usage, and the third delivers an important safety note. Every sentence earns its place without redundancy or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple discovery tool, this description is complete: it states what is listed (devices and titles), how the output is used by other tools (as `device` arguments), and the visibility of credentials. The presence of an output schema covers return-value details, so the description fills the semantic gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100% and baseline is 4. The description adds context about the `device` argument used by other tools and mirrors the device-title concept, which indirectly informs the parameter semantics for the overall API even though this specific tool has zero params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Lists the MikroTik devices this server manages.' It clarifies the purpose and adds that it reveals device titles, which distinguishes it from the numerous sibling tools that operate on specific devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Every other tool takes an optional `device` argument that must be one of the titles returned here.' It explains when to use this tool (discovery) and how it relates to all other tools, including the automatic device selection when only one is configured.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![mikrotik-mcp MCP server](https://glama.ai/mcp/servers/jeff-nasseri/mikrotik-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jeff-nasseri/mikrotik-mcp)

Score Badge

Copy to your README.md:

[![mikrotik-mcp MCP server](https://glama.ai/mcp/servers/jeff-nasseri/mikrotik-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jeff-nasseri/mikrotik-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jeff-nasseri/mikrotik-mcp'

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