pktctl

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that results come back in two formats (text and HTML), which is modestly useful, but says nothing about pagination behavior, page-size, out-of-range pages, or failure modes.

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

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

A single efficient sentence with the resource and output format front-loaded and no filler. Appropriate size for a one-parameter read tool.

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

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

With an output schema present, return values need no explanation, and the one parameter is fully documented. The main remaining gap is the absence of any usage condition (e.g., an activity must be open), which keeps it short of a 5.

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 the single 'page' parameter is already documented in the schema with its default. The description only hints at pagination via 'a page of'; it adds no syntax or edge-case detail beyond the schema, 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 (Read) and resource (the open activity's instructions) and notes the dual text/HTML representation. It does not name or differentiate against a sibling, but the resource is distinctive enough to be 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The phrase 'the open activity's instructions' implies an activity must already be open, but this is left to inference rather than stated.

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 and openWorldHint=false, so the safety profile is covered. The description adds one behavioral edge case — that on a non-activity network it returns an 'is not an activity' result rather than failing — which is genuinely useful, though it does not cover failure modes or empty-state behavior beyond that.

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

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

Two tight sentences, front-loaded with the primary payload (activity progress) followed by the caveat. Every clause carries information; no filler or repetition of the tool name.

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

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 semantics carried by annotations, the description need not detail return shapes. For a zero-parameter, read-only query tool it is effectively complete, missing only differentiation from the check_activity sibling.

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 no parameter semantics to document. Baseline of 4 applies; the description's listing of returned fields is orthogonal to parameters and does not mislead.

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?

Names a specific resource (the open .pka activity) and enumerates what the tool reports: percentage complete, score, assessment items/points, instruction pages, time elapsed or left. This is a concrete verb+resource statement. It does not, however, distinguish itself from the sibling check_activity, which appears to overlap.

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 clause 'For a plain network it only says it is not an activity' implies when the tool is pointless, giving implicit usage guidance. But it never states when to prefer this over check_activity or status, nor any prerequisites, so routing is 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 declare it is a non-readonly, non-destructive, closed-world write. The description adds genuine behavioral context beyond that: 'Routers and switches boot immediately' tells the agent the device becomes active on add, which the annotations do not convey. It stops short of stating auth needs or whether a failed add 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.

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

Three tight sentences with the core action front-loaded, followed by the boot behavior and return note. No filler; every sentence carries information the agent needs.

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 an output schema exists, the description need not detail return values, and it appropriately just notes the device is returned as shown. Combined with the boot-behavior note and full schema coverage, it is nearly complete; only cross-tool routing (remove_device, arrange_devices) is absent.

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 four parameters (model, name, x, y) are already documented in the schema. The description restates the model-name source and optional naming/placement but adds no new syntax or format detail beyond the schema, matching the baseline for full coverage.

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 (Add) and resource (a device to the logical workspace) with the scope constraint that it is selected by model name. It clearly distinguishes itself from siblings like list_models and list_devices, so an agent can identify the tool without opening the 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?

It routes the agent to list_models for valid model names and explains the x/y pairing (both or neither). However it gives no exclusions or guidance on when to prefer add_module, connect, or power_cycle_all instead, so usage is clear-context but not fully comparative.

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 only declare non-read-only, non-destructive, closed-world. The description adds the critical behavior that cities and wiring closets are created via Packet Tracer's own buttons while other kinds are written into the network file into a temporary copy that requires save_network to persist — exactly the kind of non-obvious side effect an agent needs before calling.

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-loaded verb and resource with the kind list immediately after, followed by the persistence caveat. Two sentences with little waste, though the second sentence is dense and could be split for scannability.

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 an output schema present, return values need not be explained, and annotations cover the safety profile. The description supplies the unusual persistence behavior and kind semantics; the only gap is the absence of sibling routing or failure conditions for a mutation 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?

Schema description coverage is 80%, so the per-parameter docs already carry most meaning; the description only paraphrases 'an optional name and position'. It adds no syntax or format detail (e.g. inside path form, percent semantics) beyond what the schema already provides.

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 ('Create a place in the physical workspace') and enumerates the exact kinds it accepts, so an agent can immediately tell this apart from siblings like add_device or remove_location. The scope (locations, not devices or links) 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?

It gives contextual guidance ('save with save_network to keep them') which is real usage advice, but never states when to choose this over move_to_location, rename_location, or remove_location, nor any prerequisites. Usage is implied by the enumerated kinds rather than explicitly framed.

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, but the description goes further by spelling out the exact mechanism and consequence: power off, module inserted, power on, 'so unsaved configuration is lost.' That is the kind of concrete side-effect detail the annotation cannot convey. It stops short of mentioning permissions or failure modes.

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 clauses: what it does, the hardware-emulation side effect, and the return value. Front-loaded with the action and free of 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?

With annotations covering the safety profile and an output schema covering the returned ports, the description adds the essential prerequisite (empty slot) and the destructive consequence (config loss). Complete for the call decision, though it doesn't address whether prior device configuration must be saved first or any dependency on the device already existing.

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% and the schema already provides examples for both module and slot, so the schema does the heavy lifting. The description only adds the 'empty slot' constraint, a marginal gain over structured data.

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 (install) and resource (module) with a concrete example model (HWIC-2T for serial ports) and target context (empty slot). This clearly distinguishes it from the sibling remove_module without needing to open either 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?

The prerequisite that the slot must be empty and the fact that the device is power-cycled give clear usage context, and the schema points to list_slots for valid slot paths. There is no explicit when-not-to-use or named alternative, but the operating conditions are unambiguous.

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, destructiveHint=false, and openWorldHint=false, so the agent knows this is a non-destructive local write. The description adds that the note is returned with its id, which is useful confirmation of the mutation's result. It does not state whether placement collides with existing notes or what happens on duplicate coordinates.

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 short sentences with no filler; the action and scope come first, the return behavior second. Every clause earns its place.

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

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

With full schema coverage, an output schema for the return value, and annotations covering the safety profile, the description supplies what the agent needs to call the tool. Only minor gaps remain, such as how notes interact with existing canvas content.

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 x, y, and text are already documented in the schema, including a concrete example for text. The description adds no parameter syntax or constraints beyond what the schema provides, so the baseline of 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?

The description states a specific verb and resource ('Write a text note on the logical canvas') and clarifies the target surface is the canvas rather than e.g. a device config. It doesn't explicitly differentiate itself from siblings like remove_note or list_notes, but the action 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?

'for example to label a subnet or a VLAN' implies the intended use case (annotating/labeling the topology). There is no explicit when-not guidance or naming of alternatives such as list_notes for reading notes back.

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 establish readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds non-obvious behavioral context the annotations cannot convey: the mode-dependent execution timing (immediate vs. deferred until simulation_step). It does not say what state the PDU changes or how it appears in the simulation.

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, no filler, with the core action front-loaded before the mode-dependent caveat. Every clause carries information an agent needs.

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 an output schema present, return values need not be described, and the mode-specific timing behavior is covered. The only remaining gap is that nothing states the effect (does it create a persistent object in the workspace?) or whether source/destination must be existing devices.

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 both parameters (source, destination) are already documented with examples in the schema. The description conveys the 'one device to another' relationship but adds no format, naming, or edge-case detail beyond what the schema provides. 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 and resource — 'Send a simple PDU (ICMP echo) from one device to another' — and anchors it to the familiar 'Add Simple PDU' UI button, so the agent understands exactly which capability this is. It does not name or contrast any sibling tool, so it stops short of the 5 tier.

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 describes the two usage contexts: it fires immediately in Realtime mode and defers to simulation_step in Simulation mode, which is genuine when-to-use guidance tied to sibling tools. It lacks any when-not-to-use or prerequisite statements.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds essentially nothing beyond that: no mention of required permissions, idempotency, what happens on duplicate usernames, or any side effects.

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

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

A single efficient sentence with the verb and both variants front-loaded. Nothing is wasted, though there is very little content to begin with.

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?

An output schema exists, so return values need not be explained. However, for a six-parameter mutation tool with low schema coverage, the description leaves the required parameters and the semantics of the two service modes under-specified.

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 only 33%, so the description needs to compensate, and it partially does: the FTP-vs-email branching explains why 'permissions' matters only for FTP and why 'domain' matters only for email, which the raw schema does not express. It still leaves 'device', 'username', and 'password' entirely unexplained.

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 ('Add') and two concrete resources ('FTP account', 'email account') plus the target ('to a server'). It is immediately clear what the tool does, though it gives no hint of how it differs from nearby tools like set_server_service or configure_email.

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

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance. The agent must infer from the sibling list alone whether add_server_user or set_server_service is appropriate.

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=false with destructiveHint=false, so the agent knows this mutates layout without destroying anything. The description adds valuable context beyond that: devices located elsewhere are pulled in, and coordinates are percentages as drawn by Packet Tracer, both of which shape expectations about side effects.

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

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

A dense but front-loaded passage: the action and target come first, then the positioning modes. No filler sentences, though it is long enough that a shorter split would aid scanning.

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?

An output schema exists so return values need not be described, and the safety profile is covered by annotations. The description covers the mutation's side effect (pulling devices from elsewhere), the required location path source (`list_locations`), and the coordinate model – nothing essential to correct invocation 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 adds relational meaning the schema lacks – that `columns` and `margin_percent` jointly shape the grid and are only relevant when `spots` is omitted. It also reinforces the percentage semantics of `spots`, which the schema states per-field but not globally.

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: 'Lay devices out inside a room, building, rack or table', with the added scope 'moving in the ones that are somewhere else'. This clearly separates it from single-device siblings like move_device and move_to_location.

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 lays out three concrete modes of use – omit positions for an even grid, set `columns`/`margin_percent` to shape it, or supply exact `spots` – which tells the agent how to pick a strategy. It does not explicitly say when to prefer this over move_device or move_to_location, so it falls short of full when/when-not guidance.

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 readOnly, non-destructive and openWorldHint=false; the description reinforces this by explaining that URL names resolve through the host's own simulated DNS server, which clarifies why the operation is not truly open-world. It also surfaces the status vocabulary (ok, timeout, host_not_found) and the default/max timeout, adding 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.

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

A single dense sentence with the action and return payload front-loaded; nothing is wasted, though it is somewhat long and the DNS clause could be trimmed.

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?

An output schema exists so return-value explanation is largely redundant, yet the description still names the key response fields and error statuses, which is helpful. For a read-only browser-simulation tool the definition is essentially 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?

Schema description coverage is 100%, so all three params (url, device, timeout_secs) are already documented. The description adds only marginal meaning (DNS resolution, status names) and no param syntax beyond what the schema states, so the baseline of 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 (open), resource (URL in a device's Web Browser) and explicitly enumerates the return payload (status, server address, HTML, text). This clearly separates it from siblings like screenshot, run_host_command, or set_web_page.

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?

Usage is implied by the 'like typing it and pressing Go' framing and the DNS resolution note, but there is no explicit when-to-use vs. when-not, and no named alternatives among siblings (e.g. run_host_command or screenshot for other page inspection paths).

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=false and destructiveHint=true; the description reinforces this with 'including changes', which the agent needs to know before invoking a mutation path. It also adds behavior beyond the annotations: every step is validated against the official API before anything is sent, argument types are exacted, and returned objects carry a class and uuid usable in the next call. It stops short of describing error/partial-failure behavior in a multi-step chain, which is the one real remaining gap.

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-loaded with the core action, then chaining, then validation, then the routing rule — a sensible order with no filler. It is dense (long clauses, backtick examples) but every clause carries information; only the parenthetical example chain could be trimmed.

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 low-parameter but high-power escape hatch, the definition covers the prerequisite (describe_ipc), the safety posture (reaches changes), and the round-trip object contract. An output schema exists, so return values need no explanation, and the two nested-object parameters are schema-documented. Partial-failure semantics in a chained call are the only unaddressed area.

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% and the `from`/`steps` fields are well documented in-schema, so baseline would be 3. The description adds genuine meaning on top: the chaining contract ('each on the object the previous one returned'), the root-vs-uuid distinction for the start point, and the class+uuid round-trip that makes multi-step calls possible. It doesn't restate the argument-encoding rules, which the schema already covers.

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 ('Call any Packet Tracer IPC method'), explains the chaining model with a concrete example (`network` -> getDevice("R1") -> getPower()), and explicitly positions itself against the many dedicated sibling tools ('Prefer the dedicated tools when one fits'). An agent can tell exactly what this is and when it is the right reach.

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 an explicit routing rule ('Prefer the dedicated tools when one fits; this reaches everything else, including changes') plus a prerequisite ('read describe_ipc first'). Both the when-to-use and the when-to-use-something-else conditions are stated, not inferred.

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=false with destructiveHint=false, and 'Run ... tests' is consistent with a non-read-only, non-destructive operation, so no contradiction. The description adds that it returns current completion and score, but omits whether running the tests mutates simulation state or has prerequisites.

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

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

One front-loaded sentence with the action and its outcome stated immediately; no padding. The only soft spot is the trailing UI analogy, which is mildly wasteful for an agent reader.

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?

A zero-parameter tool with an output schema and annotations needs little, and the description covers the action and the returned values. However, in an activity/grading context it should state prerequisites (activity open/unlocked) or how the result relates to activity_status, which it leaves out.

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 no parameters, so per the rubric baseline is 4. The description correctly never invents parameter detail, and the empty schema leaves nothing to document.

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?

Specific verb (Run) plus resource (the open activity's connectivity tests) with a clear statement of what is returned (completion and score), which separates it from status-style siblings like activity_status. The trailing 'like Check Results' is a UI reference that adds little for an agent but doesn't obscure the purpose.

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

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

No explicit when-to-use guidance. With siblings such as activity_status, activity_instructions, and unlock_activity, the description never says whether this is a graded check, whether the activity must be open/unlocked first, or how it differs from simply reading activity_status.

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 the mutation profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description's key added value is that clients retain their existing association until connect_wireless reconnects them — a genuinely useful, non-obvious side effect. It could go further on defaults/permissions, but this is real 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.

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

Two tight sentences with zero filler; the action and its fields are front-loaded, and the follow-up caveat about client reconnection comes second. Every clause earns its place.

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

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

With five parameters, an output schema present, and annotations covering the safety profile, the description supplies the essentials: what gets changed and the delayed effect on clients. The main omission is that the security default of 'open' is never flagged as significant, which an agent configuring wireless security arguably needs.

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 60% (key and broadcast_ssid are documented; ssid, device, security are not), so the schema carries much of the load. The description enumerates the security values and names 'SSID broadcast', which maps to parameters, but adds no format or constraint detail beyond what the schema already encodes.

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 (Set) plus the exact resource fields (SSID, security, key, SSID broadcast) on an access point/wireless router, so the agent knows precisely what is configured. It is clear but does not explicitly name a sibling to distinguish itself from, e.g., connect_wireless, other than a passing mention in the follow-up sentence.

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 second sentence implies the workflow — configure here, then use connect_wireless to actually reconnect clients — which effectively tells the agent when this tool's effect materializes. However it never states prerequisites, when not to use it, or what alternatives exist for the same goal, so guidance remains 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.

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

Annotations already declare it is a non-read-only, non-destructive, closed-world write. The description usefully adds the idempotency semantics ('existing pools with the same name are updated') and the default-on behavior, but says nothing about whether unspecified pools are preserved or removed, or whether the service restarts.

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 action and then the pool fields and update rule. No filler, though the parenthetical field list is a slightly dense inventory.

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?

An output schema exists, so return values need no explanation, and annotations cover safety. However, for a mutation tool whose schema leaves `device`/`port` undocumented, the description should clarify which device identifier is expected and the port default to be fully actionable.

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 50%; the pool fields are well documented but `device` and `port` have no schema description, and the description only loosely covers `enabled` ('switch it on') without mentioning port or device naming. It compensates partially but leaves gaps.

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 (configure) and resource (DHCP service of a server), and enumerates the sub-actions (enable, create/update pools). It doesn't distinguish itself from the sibling configure_dns_server, so it stops short of a 5.

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

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

No guidance on when to use this versus configure_dns_server, set_server_service, or list_server_services, and no prerequisites or exclusions stated. The agent must infer the 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.

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds the non-obvious dual behavior — it both toggles the DNS service and creates records in one call — but says nothing about whether existing records are merged or replaced, error behavior on duplicate names, or permission requirements.

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

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

A single front-loaded sentence with no filler; the core action and resource come first and every clause earns its place.

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

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

An output schema exists, so return values need not be explained, but for a three-parameter mutation tool with low schema coverage the description leaves meaningful gaps: the role of `device`, the off-switch semantics of `enabled`, and how added records interact with existing DNS state.

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 only 33%, so the description must carry more weight than it does. It clarifies the record types (A, CNAME, NS) matching the enum, but says nothing about the required `device` parameter or that `enabled` can be set to false to switch the service off (description only says 'switch on').

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 names specific verbs (switch on, add) and concrete resources (DNS service, A/CNAME/NS records), so an agent can tell it apart from siblings like configure_dhcp_server. It does not, however, distinguish itself explicitly from set_server_service or configure_host, which operate in the same space.

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

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

There is no guidance on when to use this tool versus the very similar set_server_service or configure_dhcp_server siblings, and no stated prerequisites (e.g., whether the device must already exist or the service must be installed). Usage is only implied by the name.

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=false, destructiveHint=false and openWorldHint=false, so safety and scope are already covered. The description adds only the return-semantics note ('Returns the account as Packet Tracer now has it'), which suggests the operation is idempotent/reflective, but it says nothing about overwriting an existing account or failure modes.

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 action and the configured fields; the parenthetical POP3/SMTP glosses are genuinely useful. Slightly list-heavy but nothing is wasted.

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 an output schema present the description need not explain return values, and annotations carry the safety profile, so what remains — what gets configured and where — is covered. The only gap is the absence of any lifecycle context (setup-before-send, overwriting an existing account).

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 86%, so the schema already documents nearly every field with examples. The description restates the same field list (display name, address, user name, password, POP3/SMTP servers) and adds no format, ordering, or default information beyond it.

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

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

States a specific verb ('Set up') and resource ('the Email app of a PC, laptop or server') and enumerates exactly which settings are configured. An agent can distinguish this from send_email/receive_email by the setup verb, though the description never names a sibling to sharpen the contrast.

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

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

No explicit when-to-use, prerequisites, or alternative guidance. It never says, for example, that this must run before send_email/receive_email will work, or how it relates to add_server_user and set_server_service, all of which sit alongside it in the sibling list.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing pre-flight validation behavior (invalid mask, host equals network/broadcast, gateway outside subnet) that fires before the simulator is touched. It doesn't state idempotency or what an invalid input returns, keeping it 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 sentences, no filler, with the primary action and its two modes front-loaded and the validation guarantee as supporting detail. Every clause earns its place.

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

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

An output schema exists and annotations cover the safety profile, so return values and read/write nature need no explanation here. The description covers both modes and the validation contract; the only minor omission is the port parameter and its FastEthernet0 default, which lives only in the 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 every parameter is already documented, including the 'required unless dhcp is true' conditions and the gateway-in-subnet constraint. The description only restates that ip/mask are needed for static mode and gateway/DNS are optional, adding little beyond the schema. 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 (set) plus resource (IPv4 configuration) and scopes it to PC/laptop/server. The word 'IPv4' cleanly separates it from the sibling configure_host_ipv6, and the two operating modes (DHCP or static) are stated up front.

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?

Clearly frames the usage context: choose DHCP or static ip/mask with optional gateway and DNS. It does not, however, name when to prefer this over related siblings such as configure_host_ipv6 or configure_ios, so routing is left partly 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 this is a non-read-only, non-destructive, closed-world mutation, so the description is not required to restate safety. It does add real behavioral value beyond the annotations: it discloses the post-condition (returns the addresses Packet Tracer now has on the port) and clarifies that `off` simply switches IPv6 off.

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

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

A compact, front-loaded passage that leads with the verb and resource and then enumerates the meaningful modes. It is dense but every clause (modes, gateway, DNS, return value) carries information; only the redundant address/gateway examples are slightly wasteful.

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 annotations, full schema coverage, and an output schema covering return values, the description covers what an agent needs. Minor gaps remain: no note on prerequisites such as device power state or whether the change is persistent, and the default port is only in the 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 every parameter (including the mode oneOf meanings and the FastEthernet0 default) is already documented structurally. The description's examples (2001:db8:10::20/64, fe80::1) duplicate the schema text rather than extending it, which is the baseline-3 case.

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 (Set) plus a precise resource and scope (IPv6 configuration of a PC, laptop or server), and anchors it to the familiar IP Configuration UI. The 'IPv6 part' phrasing implicitly separates it from the broader configure_host and configure_ios siblings, so an agent can distinguish it without opening schemas.

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?

Usage is implied by the scope statement (host-side IPv6 addressing), and the mode examples hint at scenarios, but there is no explicit when-to-use guidance or contrast with alternatives such as configure_host, configure_ios, or configure_access_point. Nothing tells the agent when NOT to reach for this 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?

Goes well beyond the annotations by disclosing failure semantics (stops at the first rejected command), cleanup behavior (always leaves configuration mode), and the effect of `save` (runs `write memory`). These are exactly the behavioral traits an agent needs before issuing a destructive multi-command 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?

One dense but well-ordered sentence plus a short clarification – no filler, and the operational model (enter config, follow the prompt) is front-loaded before the edge-case behavior.

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

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

With an output schema available and annotations covering the safety profile, the description supplies everything else an agent needs: how commands are sequenced, failure handling, mode cleanup, and persistence via `save`. Nothing material is missing for a destructive tool of this complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the `save` behavior and the prompting model already documented in the schema, adding little new meaning about individual parameters.

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

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

States a precise verb+resource: apply a block of IOS configuration commands to a router or switch. The 'as if typed after `configure terminal`' framing pins down the exact operation and separates it from siblings like configure_host, configure_access_point, or run_cli.

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 strong operational context (commands execute in order, sub-modes work, leading enable/configure terminal and trailing end are handled) so an agent knows exactly when this tool applies. It does not, however, explicitly compare itself to run_cli or the other configure_* siblings for exclusion cases.

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, destructiveHint=false and openWorldHint=false, so safety is largely covered. The description adds real operational context beyond that: ports must already exist and be unoccupied, and the default `auto` selection is deterministic. It does not state error behavior or whether an existing link is replaced, which caps it at 4.

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, both earning their place: first the action and precondition, second the cable-selection behavior. The action is front-loaded and there is no 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?

With an output schema present, return values need not be explained, and annotations cover the safety profile. The description covers the action, prerequisites and cable semantics, but leaves unstated what happens if a port is busy or whether the call is idempotent, which is the only remaining gap for a mutation tool of this complexity.

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

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

Schema description coverage is 100%; the schema already documents all five parameters, including the auto-selection rules for `cable`. The description's mention of CCNA rules and forcing fiber/rollover/console overlaps with that schema text rather than adding new syntax or format detail, 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 and resource ('Cable two ports together') that unambiguously identifies physical link creation and distinguishes it from siblings such as disconnect and connect_wireless. The scope is clear from the first four words.

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 concrete precondition ('Both ports must exist and be free') and explains the default cable behavior, including the escape hatch of passing `cable` to force a type. It does not name an alternative tool or a when-not-to-use condition, 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.

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

Adds real behavior beyond the annotations (readOnlyHint=false, destructiveHint=false): it sets the client's current profile, operates on a temporary copy so the user's own file is not written, and reports association status and the access point joined. That non-persistence guarantee and the returned outcome are exactly the kind of context annotations cannot carry.

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 purpose and then the notable behavior; almost every clause earns its place. Slightly dense but no 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. The description supplies the crucial non-persistence detail and the loaded-network prerequisite, leaving mainly the underserved ip/mask/gateway/dns parameters as a 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?

Schema coverage is only 33% across 9 parameters, so the description must compensate. It covers ssid, security, key and the DHCP-vs-static distinction (ip 'Omit for DHCP'), but says nothing about mask, gateway, dns, or bring_access_point semantics. Partial compensation only.

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 ('Connect a laptop, PC or other client with a wireless card to a network') and enumerates the relevant inputs (SSID, security and key, DHCP or static address). The wireless-card scoping naturally separates it from the wired `connect` sibling.

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?

Implies when it applies (a client with a wireless card, a loaded network) via the prerequisite 'Packet Tracer only associates when a network is loaded', but never names an alternative such as `connect`, `configure_host`, or `wireless_status`, nor states a when-not condition. Usage is inferable but not spelled out.

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 and closed-world, so safety is covered. The description adds genuine behavioral detail beyond them: it explains that each mode changes what is returned (keyword search, full class listing, enum values, or roots) and frames the tool as read-only introspection never touching live state.

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-loaded with the purpose, then a compact enumeration of the four modes, and finally the routing advice. Every sentence earns its place; the mode list is dense but integral to usage.

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 an output schema present, return values need no explanation, and the description covers the discovery workflow and its handoff to call_ipc. The only gap is the unmentioned `events`/`limit` behavior, which is minor given full schema coverage.

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 schema fully documents all five parameters with examples. The description reinforces the search/class/enum modes but omits two parameters entirely (`limit` and `events`), so it does not add meaning beyond the schema and 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+resource: exploring Packet Tracer's complete IPC API down to classes, methods, arguments and enums. It also enumerates the four modes (search/class/enum/none), so an agent immediately knows what the tool does and how its shape differs from call_ipc.

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 clear usage context: 'Use it before call_ipc for anything the dedicated tools do not cover.' This establishes the discovery-before-execution workflow and when this tool applies. It stops short of naming specific alternative tools or stating exclusions for covered operations, so it falls just under the top band.

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 and readOnlyHint=false, so the agent knows this is a mutating operation. The description adds a small amount of context by specifying that a cable is removed from a port, but it does not disclose reversibility, side effects on the port or device state, or authorization needs. With annotations covering the safety profile, 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 a single, efficient sentence with no filler. The action and target are front-loaded, and every word earns its place.

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

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

Given the tool's simplicity, the presence of an output schema (so return values need not be explained), and annotations that already cover the mutation safety profile, the description is largely complete. A minor gap is that it does not mention the inverse relationship with connect or what happens to the port after disconnection, but these are not essential 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 both the device and port parameters are already documented in the input schema. The description mentions 'cable plugged into a port', which loosely maps to the port parameter, but adds no syntax, format, or usage details beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

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 (remove) and resource (cable plugged into a port). It clearly distinguishes the action from sibling tools like connect (opposite action) and remove_device (removes a device rather than a cable). However, it does not explicitly name or contrast with any sibling, 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.

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 connect or remove_device. There are no prerequisites, conditions, or exclusions stated; usage must be inferred entirely from the tool name and description.

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

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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=false. The description adds the crucial non-obvious behavior: drawings are written into the network file, Packet Tracer reopens from a temporary copy, and the change is only kept if the agent saves with a path. It also states the return value (an id) and its consumer. This is material context an agent cannot get from 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.

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

Four dense sentences: shapes first, then colour/fill, then persistence semantics, then return value. No filler, and the most consequential constraint (the temp-copy/save behavior) is stated before the return note.

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

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

The tool is a mutating canvas operation with an output schema, and the description covers the shape vocabulary, the coordinate conventions, defaults, and the persistence caveat. Nothing needed to invoke it correctly is missing; return-value detail is appropriately brief since an output schema exists.

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 75%, so the baseline is 3, but the description actively compensates: it specifies colour syntax (named palette or `#rrggbb`), the default outline colour (blue), radius default (60), and what x/y/to_x/to_y mean per shape. It largely duplicates schema text rather than extending it, so it stops short of 5.

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?

Opens with a specific verb and resource ('Draw on the logical canvas') and enumerates the three concrete shapes with their geometric meaning. It also names the sibling that consumes this tool's output ('Returns the id `remove_drawing` takes'), making it distinguishable from list_drawings/remove_drawing 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?

Each shape is tied to a use case ('ring a subnet or group', 'frame an area', 'mark a boundary'), which tells the agent which variant to select. It also says when to save ('save with a path to keep it'), a real usage condition. It does not, however, state when not to draw or name alternatives in the shape-selection space.

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 establish that this mutates state but is not destructive. The description adds real behavioral context by explaining what actually changes (spanning tree converges, DHCP leases arrive, routing protocols settle) and the time it saves, which is beyond what the annotations convey.

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 tightly written sentences, with the core action front-loaded and the usage timing following. Every clause earns its place by conveying either effect or timing.

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?

An output schema exists, so return values need no explanation. For a parameterless action tool, the description supplies purpose, effect, and invocation timing, leaving nothing essential 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 takes zero parameters, so there are no parameter semantics to explain; the baseline for a parameterless tool is 4. Nothing in the description is needed to clarify inputs.

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

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

The description names a specific action ('Press Realtime mode's Fast Forward Time button') and states its concrete effect ('timers jump ahead'), which is unambiguous. It is clearly distinguishable from siblings like simulation_mode and simulation_step because it scopes itself to Realtime mode's time-advance behavior.

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 gives explicit sequencing guidance: 'Call it after cabling or configuring, before testing connectivity.' This is clear contextual instruction, though it does not name an alternative tool or state when not to use it, so it stops short of full when/when-not guidance.

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 and openWorldHint=false, so the safe read-only nature is established structurally. The description adds only the scope of preferences returned; with an output schema present, the enumerated categories are partly redundant, and nothing extra is disclosed about auth or side effects.

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

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

A single front-loaded sentence that leads with the verb and resource. The trailing 'and more' is mildly vague filler but does not obscure the core meaning.

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 annotations covering the safety profile, an existing output schema covering return values, and no parameters, the description gives an agent everything needed to call it correctly. The only soft spot is the undefined 'and more' scope, which the output schema resolves.

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 the baseline is 4. There is no parameter surface for the description to explain, and it correctly avoids inventing input arguments.

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

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

States a specific verb (Read) and resource (Packet Tracer's preferences) and enumerates the setting categories covered. It does not name the set_preferences sibling, but the 'Read' verb implicitly distinguishes it as the retrieval counterpart to that mutator.

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?

Usage is only implied: an agent can infer this is the read side of preferences and that set_preferences handles mutation, but the description never states when to call it, its relationship to set_preferences, or any conditions. No alternatives or exclusions are named.

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 and readOnlyHint=false, and the description adds useful specifics: `write` creates or replaces a file, and `delete` removes `name`. This clarifies the destructive behavior beyond the annotation flag without contradicting it. It does not cover permissions or error behavior, but with annotations present that is a modest gap.

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

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

The description is a single, front-loaded sentence that names the resource, scope, and available actions without wasted words. It uses a colon to enumerate actions compactly and is appropriately sized for the tool. Every phrase contributes to identifying the tool's function.

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 that an output schema exists and annotations disclose the safety profile, the description does not need to explain return values. It adequately covers the tool's scope and action set for a host file utility. It could be more complete by mentioning access requirements or action-specific limitations, but the core operational context is present.

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 schema already explains each parameter and action in detail, including defaults and requirements. The description reinforces the action names and C:\ file scope but adds little syntax or semantic detail beyond what the schema already provides. Baseline 3 is appropriate when structured fields carry the parameter documentation.

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 resource and scope: text files on a PC, laptop or server, specifically files in C:\ that a Text Editor opens and `dir` lists. It enumerates the four actions (list, read, write, delete) so the agent knows what the tool does. It does not name or contrast any sibling tool, so it falls short of full sibling differentiation.

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

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

The description implies usage by defining the tool as working with host text files in C:\ and by listing the available actions. However, it gives no explicit when-to-use or when-not-to-use guidance, and it does not point to alternatives such as run_host_command or other host-configuration siblings.

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 and openWorldHint=false, so the safety profile is covered. The description adds that the scope is 'every device in the open network' and that names are reusable identifiers, which is useful context, but it says nothing about ordering, payload size, or whether an empty network returns an empty list.

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, both earning their place: the first defines scope and return shape, the second gives the practical follow-on action. Scope and content are front-loaded with no 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. For a zero-parameter read tool the description is essentially complete, with only minor gaps such as ordering/emptiness behavior.

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 the baseline is 4 per the rubric. Schema description coverage is 100% and there is nothing further the description could add about inputs.

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

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

The description gives a clear verb and resource ('List every device in the open network') and even enumerates the returned fields (model, kind, canvas position), so an agent can distinguish it from list_models, list_links or list_ports. It stops short of explicitly naming those siblings as alternatives, which keeps it at a 4.

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?

'Use the names to target devices in other tools' hints at downstream usage, but there is no statement of when to prefer this tool over sibling listing tools (list_models, list_slots, network_description) or any precondition/exclusion. Usage context is only implied.

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 and openWorldHint=false, so the safety profile is covered. The description adds that the listing covers shapes on the logical canvas with ids and centres, but says nothing about scoping or whether the list can be empty/partial.

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

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

One front-loaded sentence with no filler; the key noun phrase (what is listed) comes first and the returned fields follow.

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?

An output schema exists, so return details need not be repeated, and the description is sufficient for a zero-param read-only listing. It could be marginally stronger by noting the scope of the canvas being enumerated.

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; the baseline for a parameterless tool 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 (List) and resource (circles, rectangles and lines on the logical canvas), and even names the returned fields. Read alongside siblings like draw and remove_drawing, the intent 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?

There is no statement of when to use this versus alternatives such as screenshot or show_workspace, and no prerequisites or exclusions. Usage is only implied by the verb.

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 and openWorldHint=false, covering the safety and scope profile. The description adds that it enumerates every cable and includes endpoint and type details, but it does not disclose additional behavioral traits such as pagination, filtering behavior, or response characteristics beyond what the annotations and output schema imply.

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

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

The description is a single front-loaded sentence with no wasted words. It efficiently communicates the action, scope, and returned 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 zero-parameter, read-only listing tool with an output schema and annotations, the description is complete enough. It states what is listed and what details are included, while the output schema handles the return structure and annotations cover safety.

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 score is 4. The description correctly does not invent or discuss parameters, and the empty input schema is self-explanatory.

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

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

The description states a specific verb and resource: list every cable in the network, with the returned properties (both endpoints and cable type). This is clear, but it does not explicitly distinguish itself from sibling listing tools such as list_ports or list_devices, 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.

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 like list_ports or list_devices. The description implies it is for retrieving cable links, but it provides no explicit usage 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered. The description adds that entries carry path, position, and contained devices, but this is largely return-shape information that the output schema already supplies, so the marginal behavioral value is modest.

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

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

A single front-loaded sentence naming the verb and resource first, then the hierarchy. It is compact with no filler, though the long enumerations of levels and fields border on return-value description that overlaps the output schema.

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 with an output schema and clean annotations, the description is essentially complete. An agent knows what it returns and that it is safe to call; only an explicit pointer to the sibling alternative 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 takes zero parameters, which is the baseline-4 case; there is nothing to disambiguate. Schema description coverage is 100%, so nothing is left undocumented.

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 ('List') and resource (the physical workspace hierarchy: Intercity, cities, buildings, closets, racks), so an agent can distinguish it from list_devices, list_notes, and list_links. It does not explicitly contrast itself with show_workspace, which also exposes workspace structure, but the hierarchy enumeration is specific enough to route correctly.

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?

Usage is implied rather than stated: it is a read-only enumeration, so an agent can infer 'use this to discover the location tree.' But there is no explicit when-to-use guidance and no named alternative (e.g., show_workspace) for the overlapping case.

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 and openWorldHint=false, so safety and scope are covered. The description adds useful context that results come from a static hardware catalog rather than the active topology, but says nothing about result size, paging, or ordering.

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 action and followed by the filtering behavior. Slightly clause-heavy in the second sentence but no wasted 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?

With an output schema present, return values need no explanation, and annotations cover the safety profile. Both parameters are addressed and the catalog-vs-live distinction is made, leaving little an agent needs beyond this to call 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?

Schema coverage is 100% so the baseline is 3, but the description goes further by giving concrete device-kind and module-kind examples (access_point, interface_card, pt_laptop_module) and, importantly, explaining the interaction: passing a module kind to `kind` lists only modules. That interaction is meaningful semantics beyond the schema.

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

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

States a specific verb and resource ("List the device models this Packet Tracer can create") and clarifies the source is the hardware catalog rather than live network state, which implicitly separates it from list_devices/list_slots. It does not explicitly name a sibling, so it stops short of full differentiation.

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?

Explains the two practical usage modes (filter by kind, or set include_modules/adjust kind to surface modules), which is implied guidance. However, it never states when NOT to use it or points to an alternative such as list_devices for currently instantiated hardware.

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 and openWorldHint=false, so the safety profile is covered. The description usefully adds that port labels are excluded by default, going beyond the annotations, but says nothing about ordering, volume, or scope limits of the listing.

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 primary action and scope, followed by the one conditional caveat. No filler or redundancy.

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

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

For a simple read-only list tool with one optional boolean and an output schema that already defines return values, the description covers what an agent needs. Minor omissions (result ordering, whether it covers all pages of the canvas) are not critical here.

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% and the sole parameter is fully documented in the schema. The description restates the default behavior of include_port_labels ('left out unless ... is true'), which marginally reinforces rather than extends the schema, so the 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 (List) and resource (text notes on the logical canvas) plus what is returned (ids and positions), which cleanly separates it from add_note and remove_note. It does not, however, explicitly distinguish itself from the nearby list_drawings sibling, which an agent might reasonably confuse it with.

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?

Usage is only implied by the tool name and the note about port labels; there is no explicit statement of when to call this versus list_drawings or show_workspace. The include_port_labels sentence does convey a conditional behavior, which is a partial substitute for guidance.

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 and openWorldHint=false, so the safety profile is covered. The description reinforces that this is a state-inspection read but adds no behavioral detail such as ordering, pagination, or error behavior for unknown devices. Adequate but not rich 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.

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

Two sentences, no filler, with the purpose front-loaded and the usage hint second. Every clause earns its place by describing distinct returned fields.

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?

An output schema exists, so return-value detail need not be repeated, and annotations cover the read-only nature. The definition is sufficient for correct invocation, with only minor room to note how a device name is discovered or resolved.

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% — the 'device' parameter is already documented in the schema as 'Device name as shown by list_devices.' The description adds no further semantics about this parameter, 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 and resource ('List a device's ports') and enumerates what each entry contains (state, IPv4, connections), so an agent knows exactly what is returned. It does not explicitly differentiate from the nearest lookalike sibling (list_slots), so it falls just 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.

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

Gives a concrete use case: 'Use it to pick free ports before connect,' which names the sibling tool (connect) whose precondition it serves. It stops short of a 5 because it offers no when-not guidance or statement about ports that are already occupied.

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 and openWorldHint=false, so the agent knows this is a safe, local read. The description adds that it reports on/off status for each service, but says nothing about permissions, rate limits, or side effects beyond what the 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.

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

The description is a single front-loaded sentence with no wasted words. The resource is stated first, followed by the enumerated services and status detail.

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

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

The tool is simple, has only two parameters, full schema coverage, and an output schema. The description names the resource and the full set of services, and annotations cover the safety profile, so nothing an agent needs in order to call it correctly 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%, so both parameters are already documented in the schema. The description implies a server target ('of a server') but adds no syntax, defaults, or port semantics beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('List') and resource ('services of a server'), and enumerates the exact service types returned. It is easily distinguished from sibling tools like set_server_service or configure_dhcp_server, which mutate rather than list.

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

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

The description implies usage by stating what is listed, but gives no explicit when-to-use guidance or alternatives. It does not say to call it before set_server_service or how it differs from configure_* tools. Adequate but with clear gaps.

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 and openWorldHint=false, so the safety profile is covered. The description adds useful content detail by noting that include_decisions surfaces Packet Tracer's per-layer explanation, the same text as the PDU Details window. It says nothing about ordering beyond the schema's hint, pagination limits, or behavior on an empty/raw simulation.

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 with zero filler. The core read purpose and its field set are front-loaded, and the optional decision-text behavior is deferred to the second sentence, which is the right ordering.

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?

An output schema exists, so return-value documentation is unnecessary, and the description adequately covers what the list contains. The remaining gap is routing: with siblings like watch_events and simulation_step present, the description gives no guidance on which one to pick, so the definition is adequate but not complete for selection.

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 four parameters (limit, device, protocols, include_decisions) are already fully documented with defaults and semantics. The description only restates include_decisions at a higher level, adding no syntax or format detail beyond the schema. 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?

The description gives a specific verb (Read) and resource (simulation event list) and enumerates the fields returned: location, timing, protocol, accepted/dropped. That clearly distinguishes it from state-changing siblings. However, it never contrasts itself with close siblings like watch_events or simulation_step, so an agent must infer the boundary.

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

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

There is no explicit statement of when to use this tool versus watch_events, simulation_step, or simulation_mode. The use case (inspecting a completed simulation log) is only implied by the name and field list. No prerequisites or exclusions are 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 and openWorldHint=false, so the safety profile is covered. The description usefully discloses the shape of the returned content (paths, accepted module kinds, installed modules, supported models), but adds nothing about errors, permissions, or device-name validity.

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

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

A single front-loaded sentence with no filler; the parenthetical carries real information about the return payload rather than restating the name.

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 annotations covering safety, a fully documented single parameter, and an output schema present to describe return values, the description is sufficient to call the tool correctly. Only the lack of routing guidance to sibling tools keeps it from full marks.

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?

Only one parameter, and schema coverage is 100% with the schema already stating 'Device name as shown by list_devices.' The description does not add format or syntax detail beyond the schema, 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 ('List') and resource ('a device's module slots'), and the parenthetical enumerates what each slot record contains, so the agent knows exactly what it gets back. It does not explicitly differentiate from near-neighbours such as list_ports or list_models, though the scope is clear enough to infer.

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?

Usage is only implied: the tool is the natural precursor to add_module/remove_module, but the description never states when to call it or what alternative to prefer. No prerequisites or exclusions are 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=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds no behavioral context beyond that, such as whether coordinates are absolute or relative, whether the move is animated, or whether it requires a running simulation.

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

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

A single front-loaded sentence with zero waste. The verb and resource lead, and no padding follows.

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?

An output schema exists so return values need not be described, and three required params are fully documented in the schema. However, for a canvas-mutating tool with adjacent siblings, the description leaves selection context and coordinate semantics implicit.

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% and each parameter is documented as canvas x/y of the device center and device name, so the schema does the heavy lifting. The description adds nothing beyond the schema's own naming, making the baseline 3 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 (move) and resource (device) with the target surface (logical canvas position). It is clear what the tool does but does not distinguish itself from siblings like arrange_devices or move_to_location, which could also reposition things.

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

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

No guidance on when to use this versus alternatives such as move_to_location or arrange_devices. The agent gets no condition for selecting this tool over repositioning siblings.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context that a device moved into a wiring closet lands on its rack or table, but says nothing about reversibility, error conditions, or what happens to existing placement.

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 that front-load the core action and follow with the wiring-closet nuance. Minimal waste, though the closing detail partially duplicates the 'into' schema description.

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

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

An output schema exists, so return values need not be explained, and the description covers both target types and the notable placement rule. It is nearly complete, missing only the mutual-exclusivity rule for device vs location and any error behavior.

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 80%, so the schema already documents 'into', 'device', 'location' and 'x_percent'. The description largely restates that content (destination path, device-by-name, location-by-path, wiring-closet landing) rather than adding new semantics such as coordinate ranges or what happens when both/neither of device and location are supplied.

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 (move) and resources (a device or a whole location) plus the domain (physical workspace), with a concrete example path. It does not name or differentiate against the sibling move_device, which does similar work for devices, leaving the boundary implicit.

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?

Usage is only implied through the example ('for example a switch into Home City/Corporate Office/Main Wiring Closet'). There is no explicit when-to-use guidance, no mention of when to prefer this over move_device, and no statement of prerequisites.

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=false, destructiveHint=false, and openWorldHint=false, so the agent knows this is a local, non-destructive write. The description adds that 'replace' overwrites the existing description, which is useful signal, but it omits whether the prior value is recoverable or whether the operation requires the file to be saved. Modest added value over 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?

A single tight sentence with the read case and the write case front-loaded and zero filler. Every clause earns its place.

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

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

The tool is simple, has an output schema (so return values need no explanation), and 100% parameter coverage. The description covers both modes adequately. It is only slightly incomplete in not clarifying what happens to the existing description or whether reading returns HTML versus text.

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

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

With only one optional parameter and 100% schema description coverage, the schema already documents that `text` accepts HTML or plain text and that omitting it performs a read. The description restates this rather than adding syntax, format, or size constraints beyond what the schema provides, so the baseline of 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?

The description states a specific dual-mode operation: read the open file's description or replace it with `text`. It also maps the concept to a concrete UI affordance (the Description button in Packet Tracer), which grounds the agent's understanding. It does not explicitly distinguish itself from siblings like describe_ipc, 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.

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

The description implies when each mode applies — providing `text` triggers replacement, omitting it reads — but this is also encoded in the schema's default and parameter docs. There is no explicit statement of when to prefer this tool over alternatives, and no prerequisites or preconditions are 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 destructiveHint=true and readOnlyHint=false. The description adds concrete destructive behavior—unsaved changes are lost—and the exact mitigation via save_current_to, which is valuable 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.

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

Two front-loaded sentences with no wasted words; the destructive consequence and mitigation are stated directly.

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 one-parameter tool with annotations and an output schema, the description covers the action, destructive behavior, and optional save path. Nothing essential 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 one parameter has full schema description coverage and the description mirrors that text, adding no syntax or format details. Baseline 3 is appropriate because the schema already documents the parameter fully.

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 action ('Start') and resource ('empty network'). The word 'empty' differentiates it from open_network, so an agent can select it without opening the 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?

Explains the key decision point for the optional parameter: use save_current_to to preserve unsaved changes before starting, otherwise they are discarded. It does not explicitly name open_network or other alternatives, but the context for when this tool is appropriate is clear.

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 destructiveHint annotation already flags this as a data-destroying operation, and the description adds real value beyond it: it specifies exactly what is destroyed (unsaved changes in the current network), how to avoid it, and the non-obvious trait that it 'never shows a dialog', which matters for a headless agent.

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 short sentences, each carrying distinct information: what it opens, the destructive consequence and its mitigation, and the no-dialog behavior. Nothing is padded and the critical warning is front-loaded after the purpose.

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

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

An output schema exists so return values need no explanation, and the description covers destruction, mitigation, and the dialog behavior. The only minor gap is not routing to sibling tools for saving or creating networks.

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

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

With 100% schema description coverage, the baseline is 3, and the description adds semantic weight by clarifying that save_current_to must be supplied *before* opening or the current network's changes are lost, reinforcing the schema's default-null warning.

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 (open) and resource (.pkt/.pka file), which is clearly distinguishable from siblings like new_network and save_network. It stops short of explicitly contrasting with those siblings, but 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.

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

The conditional 'unless save_current_to gives a path' implies usage context and warns about data loss, but it never names save_network or new_network as alternatives, so an agent must infer when opening is preferable to creating or saving.

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, but the description goes well beyond them: it discloses that EVERY device reloads, that unsaved configuration on every router and switch is lost, and that there is no confirmation dialog. That is exactly the consequence-level detail an agent needs before firing a destructive bulk operation.

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

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

A single front-loaded sentence with the destructive consequence stated before the trailing return-value note; no wasted words and the most important warning is not buried.

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, destructive bulk action with an output schema that covers return values, the description supplies everything an agent needs: scope, irreversibility, absence of a confirmation gate, and the response shape. Nothing material 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?

There are zero parameters and the schema is fully covered, so there is nothing for the description to document; the baseline of 4 for a no-param tool 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+resource ('power cycle every device that is on') and pins the scope to on devices only, and it anchors the action to a known UI equivalent ('like the Power Cycle Devices button'), letting an agent distinguish it from per-device power tools like set_power.

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 the trigger (all on devices, bulk reload) and even explains the difference from the GUI button's confirmation dialog, but it never names an alternative tool such as set_power for granular control or states when-not to use this bulk action. Usage is inferable rather than explicit.

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 by disclosing a real side effect (POP3 semantics delete the mail server-side) and a critical operational caveat (the app's inbox is not exposed, so the caller must persist the return value). It also implies the call blocks up to a timeout on an empty mailbox, consistent with the schema's timeout_secs. This is exactly the extra context annotations cannot carry.

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: the action first, then the protocol/side-effect, then the retention warning. No filler, and the most important caveat is front-loaded rather than buried.

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 an output schema present the description need not explain the return shape, and it correctly spends its budget on prerequisites, side effects, and the retention requirement instead. Nothing needed to invoke it 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% and both parameters are already well documented there, including defaults and the empty-mailbox timeout behavior. The description adds no parameter-level semantics (e.g., device naming conventions), 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 concrete verb+resource (download the account's new mail over POP3) and names the mechanism, which cleanly separates it from send_email and configure_email in the sibling list. An agent can tell exactly what the call produces: the inbox contents for one device.

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 frames the tool as the 'Press Receive' action and ties it to a device that has already been set up via configure_email (echoed in the schema). It gives no explicit when-not-to-use or explicit alternative for reading existing mail, so it stops short of 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 declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond them: the operation cascades to all links attached to the device, which is a side effect an agent would not infer from the name alone. It still omits reversibility/confirmation expectations.

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

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

A single front-loaded sentence carrying the verb, the resource, and the cascade side effect with zero filler. Nothing to trim and nothing important buried.

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 one-parameter destructive tool with an output schema and full annotation coverage, the description is nearly complete: it conveys purpose and the cascading link removal. The only gap is the absence of any note on confirmability, permission needs, or whether a deleted device can be restored.

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% and there is only one parameter, whose schema description already explains the format and points at list_devices as the source of valid values. The description adds nothing to parameter semantics, 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 (delete) and resource (device), and adds the important scope detail that all of the device's links are removed too. This clearly separates it from sibling tools like remove_module, remove_location, remove_note, and remove_drawing, which operate on different resources.

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 destructive 'delete' verb implies when it would be used, but there is no explicit guidance about when to prefer it over alternatives (e.g. disconnect vs. remove, or rename_device for non-destructive edits) and no stated preconditions such as needing a valid device name.

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 and readOnlyHint=false, so the agent knows this mutates state. The description adds context that the target is a drawing on the logical canvas keyed by id, beyond the boolean flags. Output schema exists, so return value need not be explained. Not a full 5 because it doesn't clarify irreversibility or permission requirements beyond the destructive hint.

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

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

Single sentence, front-loaded with the verb, no filler. Exactly the right length.

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 a simple one-param destructive tool with a full schema, annotations, and an output schema, the description is nearly complete. It could mention irreversibility or handling of missing ids, but the destructiveHint covers the main risk.

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 schema fully documents the 'id' parameter. The description adds the useful scope that id refers to drawings (circle, rectangle, line) on the logical canvas, which is minor added value. Baseline would be 3-4 with full coverage; this is compatible.

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 (remove) and resource (circle, rectangle, line on logical canvas) scoped by id. Distinguishes from add-drawing operations, though it doesn't explicitly name the sibling toolbar draw tool. Clear enough for selection.

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

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

No guidance on when to use this versus alternatives, nor prerequisites (e.g., must exist first, ownership). Agent must infer context entirely from the name and description.

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 and readOnlyHint=false, but the description adds substantial context the annotations can't: exactly what is destroyed (everything inside, including Packet Tracer's power units in racks), and the critical fact that the edit is written as bytes into a temporary copy that is discarded unless save_network is called. That persistence caveat is the kind of behavioral disclosure that prevents silent data loss.

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 front-loaded sentences with no filler: the destructive scope comes first, the precondition second, and the persistence requirement last. Every sentence carries information an agent needs to act correctly.

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?

An output schema exists, so return values need no explanation. Between the destructive scope, the move-out precondition, and the temp-copy/save requirement, the description covers everything needed to call this mutation safely and correctly.

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

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

Schema coverage is 100% and the single 'path' parameter is fully documented in the schema, including the list_locations reference and the 'everything inside goes too' warning. The description's restatement of the deletable object types adds little beyond the schema, so the 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 ('Delete') and precise resources (city, building, wiring closet, rack) with the crucial scope qualifier 'with everything inside it.' An agent can distinguish this from siblings like remove_device and remove_note without opening the 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?

Explicit precondition ('Devices must be moved out first (move_to_location)') routes the agent to the correct alternative tool when the condition isn't met, and it names save_network + a path as the required follow-up to persist the change. Both when-to-use and the alternative path are spelled out.

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 and readOnlyHint=false, so the mutation profile is covered. The description adds real value beyond that: it discloses a power-cycling side effect on the device and that the returned ports are those that disappeared, which the annotations and schema do not say.

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 short sentences, front-loaded with the action and scope, with the side effect and return info trailing. Efficient and free of filler, though 'like add_module' is a slightly indirect way to describe the power-cycle behavior.

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

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

With annotations covering the destructive profile and an output schema existing (so return values need not be explained), the description supplies the key missing hazard (power cycling) and the return semantics. It omits any prerequisite or error condition (e.g., invalid slot), a minor gap for a two-parameter 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?

Schema description coverage is 100% and both parameters (device, slot) are fully documented in the schema with their meaning. The description adds no format or syntax detail beyond what the schema already provides, so the baseline of 3 applies.

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