Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description clearly states that reading the configuration changes nothing on the router, reinforcing the readOnlyHint annotation. It also adds the side effect of writing to a local file, clarifying the tool's non-destructive impact on the router. Goes beyond annotations by explaining the purpose of the backup.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, each adding unique value: purpose, usage timing, and behavioral assurance. Front-loaded with the core action, then usage guidance, then safety note. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description fully covers purpose, when to use, and behavioral side effects. Nothing critical missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (path parameter clearly described as 'Absolute path of the local file to write'). The description adds no extra parameter context, but baseline 3 is appropriate when schema already documents the single parameter. No ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description states specific verb ('saves'), resource ('router startup configuration'), and destination ('local file'), clearing distinguishing it from all sibling getter/list tools. 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance: 'Take one before any sequence of changes so there is a known-good state to return to.' This clearly indicates when to use the tool, though it doesn't explicitly mention alternatives or when not to use it. Since no sibling performs backup, this is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: it discloses that the result is verified against the router-computed iseg block, that any failure rolls the entire thing back atomically, and that nothing is persisted until save_config. These are non-obvious transactional semantics an agent must know before invoking a destructiveHint=true tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then layers mechanics and the persistence caveat. The first sentence is long and dense but each clause carries distinct information, and no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-resource, destructive, non-persisting creation tool with no output schema, the description covers atomic rollback, verification, and the commit step. It is nearly complete; it stops short of describing what identifiers come back on success, which would matter given no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; each parameter is already documented. The description adds only that free identifiers (the subnet third octet) are chosen automatically and that Wi-Fi/policy pieces are optional, which corroborates but does not extend the schema meaningfully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource and enumerates exactly what gets built: VLAN subinterface, bridge, address, NAT, DHCP pool, optional Wi-Fi and routing policy. It also distinguishes itself from the persistence step by naming save_config, so an agent can separate creation from commit without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells the agent the workflow: this only stages the change, and save_config must be called once the user confirms. It does not name when-not to use it versus siblings like update_device or list_segments, but the commit boundary is clear enough to route correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, but the description goes well beyond that: it enumerates exactly what is destroyed (Wi-Fi networks, policy, DHCP pool, NAT, bridge, VLAN trunking on every switch port), warns about a confusing partial outcome ('removing the bridge alone leaves the VLAN trunked'), states the user-visible impact (devices lose connection), and documents a refusal case.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, zero filler, with the destructive scope front-loaded ahead of the caveat and the refusal condition. Each sentence supplies decision-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, non-hierarchical destructive tool with no output schema, the description supplies everything needed: the cascade of side effects, the safety exclusion, and the user-facing consequence. Nothing an agent needs before invoking it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a single 'bridge' parameter already documented with an example ('Bridge2'), so the schema carries parameter meaning. The description adds no further semantics about the parameter's naming or format. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Removes a segment') and immediately scopes it with the full cascade of dependent objects it takes with it. An agent can distinguish this from create_segment, list_segments, or update_device without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear precondition/exclusion ('Refuses the home segment') and enough consequence detail to judge whether deletion is the right action. It does not name an alternative tool or describe the update/rename path as a less destructive option, so it stops short of full when/when-not routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description adds meaningful behavioral detail: unsaved changes are lost on reboot, and unsavedChanges being null means 'unknown', not 'saved'. This is valuable context that an agent needs to interpret results correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each earning its place. The core question is front-loaded, and the special null-case clarification is placed last without padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only state tool, the description covers what is returned, a critical edge case, and a consequence of unsaved changes. It would benefit from mentioning the fail-safe timer state more explicitly or noting the response structure, but overall it is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and the schema is already complete. With zero parameters, the description need not compensate for schema gaps, so the baseline of 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (running configuration state) and the specific information returned: unsaved changes, last changer/time, and fail-safe timer status. It distinguishes this from sibling tools like get_system_info or get_connection_status, though it lacks an explicit verb like 'returns' or 'gets'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (when wanting configuration state details) but provides no explicit guidance about alternatives or when not to use it. There is clear context about the info it provides, but no exclusions or sibling differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark it as read-only, and the description adds that it is a full-record fetch with no filtering or projection. It does not mention not-found behavior or the exact response envelope, but for a simple read operation the added detail 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The most important facts—what is returned and how to identify the device—are front-loaded, and the field enumeration is concrete but compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only lookup with full schema coverage, the description is nearly complete: it specifies the resource, the identifier options, and the content of the result. The main remaining omission is the response shape or error handling, which is minor for this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers all three parameter descriptions, so the baseline is 3. The description adds the key semantic that MAC, IP, and name are alternate identifiers, which helps an agent know that supplying any one is the intended invocation pattern.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states exactly what the tool does: returns the router's full record for a single device, enumerated by field categories. It also names the lookup key (MAC, IP, or name), which separates it from list_devices and similar siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It is clear this is the tool to call when a single device's complete record is needed rather than a list. It lacks an explicit contrast such as 'use list_devices for multiple devices,' but the single-device framing and identifier requirements provide enough context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already indicates this is a safe read operation)Skip, and the description adds that it returns protocol-specific detail, which is useful but not extensive. It doesn't elaborate on response size or additional side effects, but since the annotation covers the non-destructive nature, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, with the core purpose stated first and immediate usage guidance following. Every word earns its place, making it both concise and effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only one parameter, full schema coverage, and a readOnlyHint, the description provides the essential information: what it returns and how to obtain the required parameter. The only minor gap is not describing the response format, but since no output schema is present, some description of return value structure could be helpful, but overall it is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description for the 'name' parameter is 100% covered, providing examples. The description adds context that the name must be an exact interface id from list_interfaces, which is helpful but not essential beyond what the schema says. With full schema coverage, the baseline 3 is warranted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to retrieve every field for a single interface, including protocol-specific details. It also names the required input, 'name', and distinguishes it from list_interfaces by specifying the full detail level, making it distinguishable from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs to 'Get the exact name from list_interfaces first,' which provides direct guidance on when to use this tool and implies that list_interfaces is for listing all interfaces while this one is for a single detailed view. This is clear usage context, though it does not list alternatives explicitly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and openWorldHint=false. The description adds the diagnostic breakdown (which check failed) and clarifies it's a status read, not a configuration change. It doesn't describe return format or error handling, but for a read-only status tool the provided context is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero wasted words. The primary purpose and usage guidance are front-loaded, and the diagnostic detail is concise. Perfectly sized for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, no output schema, and the readOnly annotation, the description covers everything an agent needs: what it does, what it checks, and when to use it. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and it correctly implies the tool takes no input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource ('checks internet connectivity') and enumerates the specific checks (gateway reachability, DNS, captive-portal). It also signals the primary use case ('Start here when the user reports the internet is down'), which distinguishes it from sibling tools like get_dns_status or get_connection_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Start here when the user reports the internet is down', giving a concrete scenario. It doesn't explicitly mention when not to use it or point to alternatives, but the directive is sufficient for a zero-parameter diagnostic tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, covering the safety profile, so the bar is lower. The description adds useful context about what data is revealed (the data enumeration), but does not disclose additional behavioral traits 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste: the first front-loads the data content, the second delivers the usage rationale. Every phrase earns its place, including the justification for why the component list matters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only tool with no output schema, the description covers the essentials: what data is returned and when to call it. It does not specify response structure or unit formats, but for a simple info tool this is sufficient and discoverable from the actual response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4 per the rubric. There is nothing for the description to document regarding parameters, and it correctly implies a no-input call.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('get system info') and enumerates the exact data returned: model, firmware version, uptime, CPU/memory load, and KeeneticOS component list. It clearly distinguishes itself from siblings like get_connection_status and get_internet_status by identifying its own scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: 'Call this first when you need to know what the router supports.' It gives clear context for when the tool is appropriate, though it does not name specific sibling alternatives or exclusion conditions, leaving the comparison to other status tools implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint and openWorldHint annotations already establish safety, and the description adds useful behavioral context about output granularity and grouping. It explains that data is organized by radio/band and what each entry contains, going beyond the bare annotation without needing to cover destructive concerns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler: the first states what is returned, the second gives the routing guidance. Every word adds value and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only tool with no output schema, the description supplies the essential context: the data content, its structure, and when to prefer this over the closest sibling. Nothing critical is missing for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so there is nothing for the description to explain. The tool takes no input, and the description's focus on what data is returned is appropriate for a parameterless read-only lookup.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (Wi-Fi status), the data grouping (radios by band), and the specific fields returned (access points, SSIDs, link state, connected clients). It also explicitly differentiates itself from the sibling tool list_interfaces, making the tool's role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states exactly when to use this tool: 'Use this rather than list_interfaces when the question is about Wi-Fi coverage or which network a device should be on.' This gives the agent an explicit selection rule and names the alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the agent knows this is safe. The description adds valuable behavioral detail by enumerating the fields returned (IP, name, connection type, signal, traffic counters) and the filtering/sorting options, which sets expectations about output content. There is no contradiction with annotations, and the description enhances the read-only context with field-level transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose, followed by usage guidance. No redundancy, filler, or irrelevant detail. Every sentence earns its place by conveying scope and customization options efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with three optional parameters and no output schema, the description covers the essential data scope and provides usage hints. It lists the fields that will appear in the result, which effectively substitutes for an output schema. It does not mention pagination or default behavior explicitly, but the schema already contains defaults, so the combination of schema and description is sufficiently complete for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters already have clear descriptions and enums. The description reinforces how filter and sort work (e.g., 'narrow to active, wired...' and 'rank by traffic...') but does not add semantically new information beyond the schema. Per the calibration, baseline 3 is appropriate when the schema carries the parameter documentation load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States the specific action 'list' on 'devices', and describes exactly what the result contains (IP, name, connection, signal, traffic). The phrase 'every device the router knows about' implies a broad listing scope, clearly distinguishing it from the sibling get_device, which presumably targets a single device. The description effectively tells an agent what this tool is for and how it differs from nearby tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context on when to use the tool (when a comprehensive device list is needed) and how to refine results via 'filter' and 'sort'. However, it never explicitly mentions when not to use it or names alternatives (e.g., get_device). The guidance is adequate but lacks explicit exclusion or alternative routing, so it does not fully meet the 5-bar.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds value by warning that the full listing is very large and that summary detail is the default, which helps the agent anticipate response size. It also mentions the fields returned. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficiently structured sentence. It front-loads the purpose and scope, then adds a key behavioral hint about default detail. No filler or redundancy; every piece of information is necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description partially compensates by naming the fields returned (link state, address, default route) and the default detail level. It does not mention pagination or handling of large results beyond the default, but the schema already defines a limit parameter. Given the simplicity of the tool, this is adequate but could hint at using limit for large listings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each parameter is already documented with descriptions and enums. The description does not introduce additional parameter semantics beyond what the schema provides, so the baseline of 3 applies. It mentions fields returned but not parameter-specific details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists every interface on the router, enumerating types (WAN, bridges, Wi-Fi, VPN) and the included attributes (link state, address, default route). This distinguishes it from siblings like get_interface or list_devices, though it doesn't explicitly name an alternative. The verb 'list' and resource 'interfaces' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as get_interface for a single interface or list_vpn for VPN-specific listings. It only notes the default detail level, which is more about output behavior than usage context. No exclusions or alternative routing is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, covering the safety profile. The description adds helpful domain context about what a connection policy is and what the returned names represent, but it doesn't disclose return format, ordering, pagination, or empty-result behavior. With annotations handling safety, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The first sentence defines the domain, and the second states what the return values mean. It's efficient, though slightly dense and could be restructured for immediate clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only listing tool, the description explains the domain, the typical use, and the meaning of the returned names. It doesn't explicitly state the return type (e.g., array of strings), but given the simple resource and no output schema, this is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema fully documents that (100% coverage), so the baseline for a no-param tool is 4. The description adds useful semantic context about the returned values even though no parameters need explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explains that the tool returns connection policies, defines what they do (decide which link a device uses), and clarifies that the returned names are the values assigned to devices. It identifies the resource clearly, though the verb 'list' is only implied by 'The names returned here' rather than stated explicitly, and it doesn't directly contrast with sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a typical use case—routing some devices through a VPN tunnel and the rest direct—which implies when an agent might need policy names. However, it doesn't explicitly say when to use this tool versus alternatives like list_vpn or list_routes, or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and openWorldHint=false; the description does not contradict these. It adds the contextual note that kind=default reveals which link traffic leaves through, which provides behavioral insight beyond the schema. However, it does not elaborate on limits, formatting, or any side effects (none expected for a read-only operation). Given the annotations already cover safety, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no superfluous content. The main return is front-loaded ('The routing table...'), and the optional parameter guidance follows. Every word earns its place, and the structure is immediately scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with fully specified parameters and no output schema required, the description covers the essential purpose and a key use case. It does not describe the exact output format, but that is not mandated for a straightforward list operation. The description is complete enough for an agent to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (kind and limit) are fully documented in the input schema. The description only reinforces the kind=default usage without adding new meaning. Since the schema does the heavy lifting, the baseline 3 applies; the description adds little beyond what is already structured.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the resource (routing table) and the fields it returns (destination, gateway, outgoing interface, metric). It also mentions the use of kind=default for the default route, adding specificity. It is distinct from sibling tools like list_vpn or get_connection_status, so 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a specific usage hint for kind=default ('tells you which link traffic leaves through') but does not provide guidance on when to use this tool versus alternatives such as list_interfaces or get_connection_status. There is no explicit when/when-not comparison, though the default-route use case offers some context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description's added value is the explanation of uiVisible and the behavior of bridges without VLANs. This is useful beyond the structured metadata.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no waste. The core purpose is front-loaded, and the explanatory nuance is concise and directly relevant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only list tool, the description covers the key output concept (uiVisible) and the edge case of non-VLAN bridges. It does not describe the exact output format, but given the absence of an output schema, this is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so the baseline is 4. The description does not need to add parameter details; it focuses on output semantics instead.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists bridges and whether the web interface treats them as segments, with a precise distinction about uiVisible. It differentiates from sibling tools like list_interfaces and list_devices by focusing on bridge/segment semantics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (when you need segment visibility on bridges) and explains a key nuance about non-VLAN bridges. It does not explicitly name alternatives or exclusions, but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, so the safety profile is known; the description adds real behavioral context the annotations do not carry, namely that responses are size-capped, that the cap can only be lowered and never raised, and that broad paths blow the budget. It stops short of warning about what POST actually mutates or whether commands are reversible.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with zero filler: purpose and fallback scope first, then method semantics, then the practical size constraint. Every sentence carries actionable information and the most decision-relevant content is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a raw pass-through tool with no output schema, the description covers invocation well and explains the one surprising return characteristic (a truncated/capped response). It could say more about error behavior or what a batch POST returns, but nothing an agent needs to make the call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description goes further by supplying concrete path examples ("show/version", "interface/Bridge0") and clarifying that body mirrors the CLI tree and must be JSON rather than a stringified object. That is meaning beyond the schema's own wording.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Sends a raw request to the router RCI interface") and immediately positions itself as the escape hatch relative to the other tools. An agent can distinguish it from get_interface or set_interface_state without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly scopes use to "anything the other tools do not cover," which is a when-not rule routing the agent to the 17 typed siblings first. It also disambiguates the two methods (GET reads a path, POST executes a command) so method selection is not left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=true, so the bar is lower. The description adds real context the annotations don't carry: the write target (startup config) and the reboot-persistence effect. It stops short of noting that an existing saved startup config is overwritten, which is what makes the destructive hint non-obvious.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, effect front-loaded before the usage caution, with no filler. Each sentence carries distinct information: what it does and when to invoke it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, zero params, and a flat schema, the description supplies enough to call the tool correctly: action, persistence effect, and the confirmation condition. The one gap is not stating that the previous saved configuration is replaced, which would fully explain the destructive annotation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The absence of args is consistent with the description's framing as a single global commit action.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and both resources ('writes the running configuration to the startup configuration') plus the observable consequence ('pending changes survive a reboot'). This clearly separates it from sibling read/backup tools like get_config_state and backup_config.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly scopes when to call: 'Nothing else in this server saves, so call this only once the user has confirmed the changes are what they want.' That names the exclusivity relative to all siblings and imposes a confirmation prerequisite, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds substantial context they don't carry: taking down a bridge or WAN link can sever the router's own management connection, i.e. a self-lockout risk. That is exactly the kind of consequence information an agent needs before invoking a destructive mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with no filler: purpose first, hazard second, precondition last. Every sentence carries actionable information and the ordering front-loads what the tool does before the caveat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and a fully documented 2-parameter schema, the description covers the remaining gaps: pre-call verification and the potential to cut off access. Nothing an agent needs in order to call this safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for both parameters, with 'name' sourced from list_interfaces and 'state' constrained to an up/down enum, so the schema does the heavy lifting. The description adds no format, naming, or default details beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair ('enables or disables') and an unambiguous resource ('network interface'), with the scope clarified as administrative state. An agent can tell this apart from read-only siblings like get_interface or list_interfaces without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names a prerequisite step ('Confirm what the interface carries with get_interface before calling this'), which routes the agent to a sibling for verification. It lacks an explicit when-not-to-use clause or guidance on alternatives to reach the same outcome, so it falls short of a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructiveHint=true and idempotentHint=true; the description adds the crucial non-obvious trait that changes are volatile until save_config is called. It does not, however, note that blocking access can cut a device off the network or confirm idempotency, so it stops short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: capabilities first, then the persistence caveat. Every clause earns its place and nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, the description covers the operation surface and the key side-effect (reboot discards unsaved changes), which is exactly what an agent needs before invoking. Annotations carry the safety profile.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each parameter is already documented (including enums for access and the 0-7 priority range), so the baseline is 3. The description's phrasing largely restates those parameter descriptions rather than adding new syntax or format detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource plus the full set of mutable attributes (rename, access, policy, schedule, priority). An agent can immediately tell this apart from read-oriented siblings like get_device or list_devices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear condition for how results behave (changes apply immediately, need save_config to persist) and points to list_policies as the source for policy names. It lacks an explicit when-not-to-use statement, but the context is unambiguous for a manage-device operation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.