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

No annotations are supplied, so the description carries the full burden; it conveys read-only intent implicitly through "summary/rollup" and by disclosing the categories of diagnostics returned (crashes, low power, tunnels down, config errors). It does not state whether data is live or periodically sampled, what permissions are needed, or how an unscoped call behaves, which are meaningful gaps for an unannotated tool.

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

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

A single sentence (with list) that front-loads the tool's identity and then packs the return contents densely; every clause carries information and nothing is repeated from the schema or annotations.

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

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

With no output schema, the description correctly takes on the duty of describing return contents, and it does so thoroughly across counts, breakdowns, and problem lists. The only shortfall is the unstated default scope when location_id is null and no note on data freshness.

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 parameter already documents itself as "Scope to a location subtree." The description adds no syntax, ID format, or subtree-depth semantics, and notably does not say that omitting location_id yields the whole fleet, which is the one piece of meaning the schema leaves implicit.

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 verb and resource ("Fleet health rollup for managed APs") and then enumerates exactly what the rollup contains: online/offline counts, model and firmware breakdowns, upgrade/config-push status, offline APs, and problematic APs. The AP scope plus the enumerated payload content distinguish it cleanly from siblings such as cvcue_network_health and cvcue_client_health_summary without needing to name them.

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 word "rollup" and the fleet-wide framing, which suggests an aggregate overview rather than per-device detail. There is no explicit guidance on when to call this versus cvcue_list_aps for raw AP data or cvcue_network_health for a broader network view, and no exclusions are 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?

With no annotations, the description carries the full burden and does so: pagination convention (0-based startindex + pagesize), location subtree scoping, selective-fetch failure code, the modelspecific=false workaround, oversized-result refusal with shape preview, and secret redaction with a warning not to echo ***REDACTED*** back in a write body.

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 purpose followed by a block of practical conventions and a scannable example list; nearly every line carries operational value. It runs long for a single tool, and the parenthetical "step 4 of API discovery" is cryptic without the earlier steps in view.

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?

No output schema exists, and the description compensates by explaining response-side behavior: redacted secrets, huge devicetemplate payloads, selective field fetch, and refusal of oversized results. For a six-parameter generic dispatcher, an agent has enough 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 a 3 is the baseline, but the description adds real meaning: it shows how path_params substitute {placeholders}, what query_params typically carry for list endpoints, and gives four concrete invocation examples spanning path, query, and path params.

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?

"Execute ANY CV-CUE API call (step 4 of API discovery)" states a specific verb and resource and makes clear this is the generic escape hatch, with paths anchored to the API base URL. It doesn't name which siblings it supersedes (e.g. cvcue_list_aps), so differentiation is left 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?

The "step 4 of API discovery" framing gives an explicit position in the workflow, and the non-GET line states a hard precondition (writes must be enabled for the connection). No explicit "prefer the typed tools when they cover your case" routing, so one gap remains.

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?

No annotations are supplied, so the description carries the full disclosure burden. It does reveal the return content (modules with operation counts) and the module taxonomy, which is real behavioral value, but it says nothing about whether the list is static, whether it requires authentication, or the response shape beyond the count.

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 purpose and workflow position are front-loaded in the first sentence, and the module enumeration is genuinely useful for disambiguating similar-sounding modules (manageddevices vs. aps). The list is truncated with an ellipsis, so it is illustrative rather than exhaustive, which keeps it from feeling bloated but leaves the enumeration slightly ragged.

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 discovery tool with no output schema and no annotations, the description covers purpose, output content, the module taxonomy, and the next step. Only minor gaps remain, such as whether the module list is fixed or environment-dependent.

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 sets the baseline at 4. The description's mention of `module` refers to the sibling cvcue_api_search call rather than this tool, but it usefully clarifies how the output feeds forward, so no penalty is warranted.

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

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

States a specific verb and resource ("List the CV-CUE API modules with operation counts") and explicitly frames itself as "step 1 of API discovery," which distinguishes it cleanly from the sibling tools cvcue_api_search, cvcue_api_schema, and cvcue_api_execute.

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 "step 1 of API discovery" framing plus the explicit handoff ("Pass a module name as `module` to cvcue_api_search") tells the agent exactly where this tool sits in the workflow and what to do next. It does not state when to skip this tool (e.g., if the module is already known), so it stops just short of explicit 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?

With no annotations, the description carries the full burden. It discloses useful behavior by stating that component $refs are inlined up to ref_depth, which explains why the response may be large. However, it doesn't say whether the lookup is read-only, whether it can fail for unknown paths or methods, or how large expanded schemas can become.

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 the core action front-loaded and the ref_depth caveat appended. There is no wasted wording, though the parenthetical workflow tag could be folded more naturally.

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 3-parameter read lookup with a fully documented schema and no output schema, the description mostly suffices: it names what is returned and explains the one non-obvious parameter's effect. The main gap is that it doesn't describe the response envelope or the error behavior for unknown paths or methods.

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. The description adds some meaning by explaining that ref_depth controls $ref inlining depth, but it adds nothing about how path and method interact, for example whether a missing method defaults to GET, and it adds no guidance on choosing a ref_depth value.

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 verb and resource: get parameters, request body and response schema for one endpoint, with the scope narrowed to a single endpoint. It distinguishes itself from the api_search and api_execute siblings by positioning itself as 'step 3 of API discovery', though it doesn't name those siblings explicitly.

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 phrase 'step 3 of API discovery' implies where the tool fits: after searching for endpoints and before executing a call. However, it never states the prerequisite step explicitly, gives no when-not guidance, and doesn't point to api_search for finding the path or to api_execute as the follow-up.

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?

No annotations exist, so the description carries the full burden, and it does disclose the non-obvious matching semantics: every word of the keyword must match across path, operationId, summary and description (implicitly AND-style multi-field matching). It does not describe the shape of returned results or whether the search is paginated beyond the limit parameter, which keeps 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?

Three short clauses, zero filler, with the identity and pipeline position front-loaded and the downstream tool routing last. Every sentence earns its place.

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

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

For a four-parameter, read-only discovery tool with full schema coverage and no output schema, the description covers purpose, matching behavior and the surrounding workflow. The remaining gap is that an agent cannot tell what a result entry looks like (identifier, method, path), which it would need to hand off to cvcue_api_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 coverage is 100%, so the baseline would be 3, but the description adds real meaning for the required keyword parameter by specifying which fields it is matched against and how (every word). It adds nothing new about limit, module or method_filter, which is acceptable since the schema documents them 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?

The description names a specific verb and resource ('Search CV-CUE API endpoints') and positions itself in a discovery pipeline ('step 2 of API discovery'), which cleanly separates it from cvcue_api_modules (step 1), cvcue_api_schema and cvcue_api_execute. An agent can distinguish it from all siblings without opening a schema.

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

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

It states the exact follow-up workflow: use cvcue_api_schema on a result before cvcue_api_execute. Combined with the 'step 2' framing, the when-to-use and the alternatives are both explicit, leaving nothing to inference.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It does imply a read-only history lookup and hints at the returned fields (AP, SSID, timestamp), but it gives no retention window for 'recent', no cap on number of records returned, and no indication of what happens for an unknown or never-seen MAC address.

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, and the parenthetical return summary is placed immediately after the core statement. Nothing is redundant or padded.

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

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

This is a simple read-only lookup with one fully documented parameter and no output schema, and the description conveys the essential shape of the result. The only meaningful gap is the undefined 'recent' time window, which the agent would need in order to interpret the data 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?

With a single parameter and 100% schema description coverage, the schema already defines mac_address as 'Client MAC address'. The description adds no format details (colon-delimited vs bare hex) or case sensitivity beyond what the schema provides, so 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 names the resource precisely ('associations for a client') and parenthetically enumerates what is returned (APs/SSIDs joined and when), which is more informative than the tool name alone. It does not distinguish this from neighboring client tools such as cvcue_client_events or cvcue_troubleshoot_client, which likely surface overlapping data, 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?

There is no statement of when to call this versus cvcue_client_events, cvcue_find_client, or cvcue_troubleshoot_client, and no prerequisites (does the client need to be currently connected, must it be on this controller). The word 'recent' is left undefined, so the agent cannot tell whether this covers minutes or days.

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?

No annotations exist, so the description carries the full behavioral burden. It usefully discloses the implicit default filter (Failures only, 24h window), which is the main way an agent could misread results, and 'logs reported by APs' implies a read-only query. It omits pagination behavior, expected result volume, and any ordering or retention characteristics of the returned records.

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 identifies the resource, the reporter (APs), and the default filter with no filler. The parenthetical event list earns its space by clarifying scope, and nothing is repeated.

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 an 8-parameter but fully schema-documented read tool with no annotations, the description supplies the essential scope and the surprising default. The main remaining gap is sibling disambiguation against cvcue_query_events and cvcue_client_association_history; a brief note on what a returned event record contains would also help since no 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 100%, so every one of the 8 parameters is already documented, including the Failure default for event_type and the 24h default for hours. The description restates those defaults rather than adding new meaning (e.g., how the SSID/AP name patterns are matched, or how location_id scoping interacts with ap_name filtering), 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 uses a specific verb+resource (client connection event logs reported by APs) and enumerates the event categories covered (association, authentication, DHCP, DNS, roaming), which makes the data set concrete. It does not, however, distinguish itself from closely related siblings like cvcue_query_events, cvcue_event_summary, or cvcue_client_association_history, so an agent cannot tell from the text alone which of these to pick.

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: 'defaults to failures in the last 24h' tells the agent what happens if it calls with no arguments, which is a useful entry hint for troubleshooting. There is no explicit statement of when to prefer this over generic event querying or client association history, and no exclusions or prerequisites 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the result includes totals across several dimensions and clients with poor performance, and that the scope is currently connected clients, but it does not state whether the operation is read-only, what permissions are required, or how 'poor performance' is defined.

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

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

The description is a single front-loaded sentence with no redundant wording. It efficiently lists the aggregation dimensions and the poor-performance inclusion without padding.

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

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

For a summary tool with no output schema and no annotations, the description does a fair job of naming the output aggregates. However, it leaves 'poor performance' undefined and does not clarify the return structure or safety profile, so it is only adequately complete.

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

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

The schema has 100% description coverage for the single location_id parameter, including the meaning 'Scope to a location subtree'. The description adds no parameter-specific meaning beyond that baseline.

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 resource and operation: a rollup of currently connected clients, broken down by SSID, AP, protocol/band, OS, vendor, signal quality, and poor performance. This is clear enough to distinguish it from listing or finding individual clients, but it does not explicitly name sibling alternatives such as cvcue_list_clients or cvcue_ap_health_summary.

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 terms like 'rollup' and 'clients with poor performance', suggesting an aggregate health overview rather than per-client lookup. However, the description does not say when to use this tool versus cvcue_list_clients, cvcue_network_health, or cvcue_ap_health_summary.

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?

No annotations exist, so the description carries the full behavioral burden; it discloses the important write-flag requirement and the parent-child constraint, which is real added value. It omits other mutation-relevant behavior: what happens on duplicate names, whether the call is idempotent, permission/error behavior, and what identifier is returned. For a write tool with zero annotation coverage this leaves meaningful gaps.

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 zero filler; the core action is stated first and the prerequisite follows. Nothing is repeated from the schema or padded.

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

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

With a fully described five-parameter schema and no output schema, the description covers the essentials: what is created, the parent requirement, and the write gate. The only real omission is what the caller gets back (e.g., the new location id), which matters for chaining into follow-up calls.

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 location_type enumeration values and timezone default is already documented structurally. The description only reinforces parent_id via "under a parent" and adds no syntax, format, or constraint detail beyond the schema, so 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?

"Create a folder or floor location under a parent" names a specific verb (create), the resource (location), and the two supported subtypes, which cleanly separates it from cvcue_list_locations, cvcue_get_location, and cvcue_delete_location. It stops short of naming those siblings explicitly, so it is clear but not fully differentiated.

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 write-gate prerequisite (CVCUE_ENABLE_WRITES=true) is genuine usage guidance a caller must satisfy before invoking. However, there is no guidance on when to choose this versus other location tools, no note on what to do if the parent is not a folder, and no mention of alternatives.

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?

With no annotations provided, the description carries the full burden and does well: it discloses that deletion cascades to children, that it is irreversible, and that two preconditions must hold. It stops short of stating what happens to APs or clients assigned to the location, or what the response contains.

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 terse sentences, with the destructive scope and irreversibility front-loaded before the prerequisites. 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 two-parameter destructive tool with no output schema, this covers the essentials: cascade behavior, irreversibility, and required flags. The remaining gap is what happens to dependent objects (APs, clients) and what the call returns.

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

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

Schema coverage is 100%, and both parameters are already documented there, including the same cascade note for location_id and the 'must be true' constraint for confirm. The description merely echoes the confirm requirement rather than adding format or edge-case detail, so this is baseline.

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 ('Delete a location') and immediately clarifies the blast radius ('AND all of its child locations'), which is exactly the kind of scope detail an agent needs before choosing a destructive tool. It is clearly distinguishable from cvcue_delete_ssid and cvcue_get_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 gives activation prerequisites (CVCUE_ENABLE_WRITES=true and confirm=true) that tell the agent when the call can succeed, but it offers no guidance on when to prefer this tool over siblings such as cvcue_get_location or cvcue_list_locations, and no advice on verifying the target first.

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?

There are no annotations, so the description must carry the behavioral burden, and it does disclose the key failure mode (template reference) and the write-gate/confirm requirements. It does not state irreversibility explicitly, whether this is a hard or soft delete, or what happens to devices or clients currently using the SSID. Solid but incomplete for a destructive operation with zero annotation coverage.

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

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

Three short sentences, front-loaded with the action, then failure mode, then preconditions. No filler. The inline GET path is slightly dense but functional.

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 two-parameter destructive tool with no output schema, the description covers the action, the blocking dependency, and the auth/confirm gates an agent needs to succeed. The remaining gap is downstream impact on devices referencing the SSID, which matters for an agent deciding whether the delete is safe.

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, and the description mostly restates the confirm requirement already present in the schema. Marginal added meaning beyond the schema, consistent with 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 and resource ("Delete an SSID profile"), which separates it from cvcue_get_ssid and cvcue_list_ssids by operation. It does not name a sibling explicitly, but the destructive verb plus the SSID-profile resource makes the scope 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?

Gives concrete preconditions for use: CVCUE_ENABLE_WRITES=true and confirm=true, plus the blocking condition that the profile must not be referenced by a device template. It even points at the check endpoint to verify that first. It lacks only a general statement of when to prefer alternatives (e.g. removing a device reference instead of the profile).

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?

With no annotations, the description carries the full burden; it does disclose one behavioral trait beyond the schema — results are ordered newest first — and implies a read-only listing operation. It omits any statement about read-only safety, retention window, rate limits, or what happens with out-of-range offsets, which matters for a log-retrieval tool.

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

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

A single front-loaded sentence that states the resource, the event categories, and the ordering with 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?

For a three-parameter, read-only listing tool with full schema coverage this is close to adequate, but with no output schema the description says nothing about what a log record contains or how pagination terminates. Given the crowded event-log sibling set, it is thinner than ideal.

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

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

Schema description coverage is 100%, with start, page_size, and location_id all documented in the schema, so the baseline is 3. The description adds no parameter-level meaning — notably it never mentions that location_id scopes the log to a location subtree, which is the most decision-relevant parameter.

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 concrete resource (AP/device event logs) and clarifies the content with parenthetical examples (reboots, crashes, config, upgrades), so an agent knows this is an event-retrieval tool. It does not explicitly distinguish itself from close siblings like cvcue_query_events or cvcue_event_summary, leaving overlap ambiguous.

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 contains no when-to-use guidance, no exclusions, and no mention of the sibling event tools (cvcue_query_events, cvcue_event_summary, cvcue_client_events) that an agent would need to choose between. Usage must be inferred entirely from the name and content examples.

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?

With no annotations provided, the description carries the full burden and does reasonably well: it discloses that the operation is forced, that the effect is non-permanent ('the client may reconnect'), and that two preconditions must be satisfied before the call will succeed. It does not state what happens on failure (e.g., unknown MAC, writes disabled), whether the disconnect is immediate versus scheduled, or what a successful response contains.

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

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

Two sentences, zero filler, with the action and its reversibility stated first and the hard prerequisites second. Every clause earns its place and an agent can parse the gating conditions in a single pass.

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 two-parameter mutation tool with no annotations and no output schema, the description covers the essentials: what it does, that it is recoverable, and the write/confirm gates. The remaining gap is the absence of any statement about the return signal or failure modes, which matters more here because no annotations and no output schema exist to fill that in.

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 input schema, and the description only reinforces the confirm=true requirement rather than adding new meaning. No format hint for mac_address (colon-separated vs hyphenated) is offered beyond the schema. This is the baseline 3 case where 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?

Names a specific verb and resource: 'Force-disconnect (deauthenticate) a wireless client,' which cannot be confused with any read-oriented sibling such as cvcue_list_clients or cvcue_find_client. The parenthetical synonym removes ambiguity about what 'disconnect' means. It stops short of a 5 because it never explicitly positions itself against the other mutating siblings (cvcue_reboot_aps, cvcue_delete_ssid) or against a troubleshooting-first workflow.

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 gives gating prerequisites (CVCUE_ENABLE_WRITES=true, confirm=true), which is genuine when-to-use-possible context. However, there is no guidance on when this tool is the right choice versus diagnosing first with cvcue_troubleshoot_client or cvcue_client_events, and no when-not-to-use case. Usage is therefore implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the output shape (totals by severity, category, type, most frequent summaries, latest high-severity events), and the read-only nature is evident from "summarize," but it never states cardinality limits (how many "most frequent" or "latest" items), the severity threshold used, or whether results are truncated or paginated.

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

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

A single sentence, front-loaded with the operation, then the enumerated return content — no filler or repetition. The enumeration is long but each item is substantive information an agent can act on.

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?

There is no output schema, so the description appropriately enumerates what comes back, which is the main thing an agent needs for a two-parameter read-only aggregation tool. It falls short only on limits and threshold specifics, which for a summary tool are meaningful but secondary.

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 hours (default 24) and location_id (subtree scoping) are already fully documented in the schema, giving a baseline of 3. The description mentions a "time window" but adds no unit, default, or scoping semantics beyond what the schema already says, and it never references the location subtree filter.

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 (summarize) and resource (events) and enumerates the four output groupings, so the agent knows exactly what the tool produces. It does not name or contrast with the closest sibling, cvcue_query_events, which appears to return raw event records rather than aggregates.

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 word "Summarize" plus the aggregate outputs imply this is the overview/rollup tool versus the raw listing siblings, but there is no explicit statement of when to choose it, when not to, or which alternative to use. Usage has to be inferred from the framing.

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?

With no annotations, the description carries the full burden and does disclose two useful traits: the lookup scope (active or recently seen clients) and that multiple matches can be returned. It does not say what happens on zero matches, whether ambiguous queries fall back across fields, or anything about permissions or result fields.

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 the resource and accepted identifiers front-loaded; every clause conveys information and nothing is redundant.

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 read lookup this is close to complete: scope, matching order and multi-match behavior are all covered. The remaining gap is the shape of the results (which client fields come back), which is only partly excused by the absence of an output schema.

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

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

Schema coverage is 100% for the single 'query' parameter, so the schema already explains the accepted identifier types. The description adds a little matching semantics ('most specific field first', 'returns all matches') but no format hints such as MAC notation or username syntax, so 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?

The description states a specific verb ('Find') and resource ('client') plus the four accepted identifier types, which clearly separates it from enumeration-oriented siblings like cvcue_list_clients and cvcue_list_wired_clients. It stops short of naming those siblings explicitly, so it is clear but not fully differentiated.

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 parenthetical '(active or recently seen)' and 'Tries the most specific field first' imply when this lookup is appropriate versus browsing a list, but no sibling alternative is named and there is no statement of when not to use it (e.g. for bulk listing or fuzzy name search).

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?

No annotations are supplied, so the description carries the burden. 'Get' implies a read-only operation, but nothing is said about required permissions, behavior when the MAC or name does not match, or whether the name must be unique. It does add useful context by listing the data categories returned, which is more than the structured fields offer.

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 resource and the identifier first and the returned fields in a compact parenthetical. No wasted wording.

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 read tool with no output schema, the description adequately conveys scope and the shape of the response. Minor gaps remain around failure behavior and result size, but nothing essential to invoking 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 coverage is 100% and the parameter already documents 'AP MAC address or exact AP name'. The description's 'by MAC or name' restates that without adding format examples, casing rules, or lookup-precedence behavior, so 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?

Names a specific verb and resource ('Get full details for one managed AP') and enumerates the payload (radios, wired interfaces, mesh, health), which separates it from the list-style sibling cvcue_list_aps. It stops short of explicitly naming cvcue_ap_health_summary or cvcue_list_aps as the alternative, so the differentiation is implicit rather than stated.

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 single-AP scope and 'full details' framing imply when to reach for it over a listing or summary call, but there is no explicit when-to-use/when-not-to-use language and no mention of the health-summary sibling that covers overlapping data.

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?

No annotations are supplied, so the description carries the full burden. It does disclose useful return-shape behavior (path plus direct children, implying children are one level deep and not recursive), but says nothing about permissions, error behavior for an unknown ID, or whether children are full objects or references.

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 nine-word sentence with the resource and the return contents front-loaded. Nothing is wasted and nothing is 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 simple single-parameter read tool with no output schema, the description covers the essentials: what is fetched and roughly what comes back. Minor gaps remain around the depth/format of 'direct children' and failure modes, but nothing critical to calling 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 coverage is 100% and the single parameter's schema description already points to cvcue_list_locations as the source of IDs. The tool description adds no further meaning about location_id, 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 (Get) and resource (location) with explicit scope: a single location, returned with its path and direct children. That distinguishes it from the sibling cvcue_list_locations, though the description never names that sibling directly.

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: 'Get one location' suggests fetching details for a known ID rather than enumerating locations. There is no explicit when-to-use, no mention of cvcue_list_locations as the discovery alternative, and no stated preconditions.

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?

With no annotations, the description must carry behavioral disclosure. It communicates return breadth by naming the configuration areas included, which implies a read operation, but it does not state permissions, side effects, error behavior, or output format.

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

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

The description is a single front-loaded sentence with no redundant or filler wording. It efficiently communicates the core scope of the 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?

For a simple two-parameter getter whose schema is fully documented, the description is adequate about what configuration is returned. However, it omits sibling differentiation and explicit usage guidance, and with no output schema it does not describe the response structure in detail.

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

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

Schema description coverage is 100%, so the input schema already documents both parameters, including that template_id comes from cvcue_list_ssids and that location_id provides location context. The description adds no additional parameter meaning beyond that baseline.

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 identifies a specific resource, 'one SSID profile', and specifies that it returns the full configuration across security, network, QoS, firewall, and portal areas. This is clearer than a tautology, but it does not explicitly differentiate the tool from siblings like cvcue_list_ssids or cvcue_ssid_usage.

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

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

Usage is implied: retrieve the detailed configuration for a known SSID profile. The schema notes that template_id comes from cvcue_list_ssids, but the description itself does not state when to use this tool versus listing SSIDs or checking SSID usage.

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?

No annotations are supplied, so the description must carry the behavioral load. It signals the read-only nature via the GET endpoint and discloses the returned field set, which is genuinely useful. However, it says nothing about authentication requirements, result-size limits, or how pagination behaves (e.g. whether a total count comes back), leaving meaningful gaps for a no-annotation tool.

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

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

Two sentences, zero filler. The capability statement with returned fields comes first, and the sibling routing follows — a front-loaded structure an agent can parse in one pass.

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 an 8-parameter read tool with no annotations and no output schema, the description compensates well by naming the returned fields, which substitutes for the missing output schema. It falls slightly short on pagination semantics and permission/auth expectations, but nothing critical to invoking the tool correctly 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 every filter (name, model, active, location_id, software_version, include_radios, start, page_size) is already documented in the schema. The description adds no filter syntax, combination rules, or examples 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?

States a specific verb and resource ('List managed Arista APs') plus the backing endpoint (GET /manageddevices/aps) and enumerates the fields returned (status, model, firmware, IP, location, client count). An agent can distinguish this inventory-listing tool from health-rollup and single-AP siblings 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?

Explicitly routes the agent to alternatives with conditions: 'Use cvcue_ap_health_summary for fleet-wide rollups and cvcue_get_ap for one AP.' This covers the two most likely competing intents (aggregate stats vs. single-device detail) and implicitly defines when this tool is the right pick — a filtered list of individual APs.

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?

With no annotations, the description carries the full burden. It does disclose the default scope (currently connected only) and the shape of returned records, and 'List' plus the GET endpoint implies a read-only operation. However, it says nothing about pagination behavior, total counts, rate limits, or authentication requirements, which are meaningful gaps for an 8-parameter list tool.

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

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

Two tight sentences with the resource and returned fields front-loaded, followed by the important default-scope caveat. No filler, no repetition of the tool name, and nothing that could be cut without losing 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?

Because there is no output schema, the enumeration of returned fields is genuinely necessary and present. The remaining gap is modest: nothing on pagination semantics or how results are ordered, but for a filtered list tool with fully documented parameters this is close to 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 eight parameters are already documented with meaning and defaults. The description adds essentially no parameter-level detail beyond restating the default active-only behavior, so the schema does all the work and 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 Wi-Fi clients') and even names the backing endpoint (GET /clients), plus enumerates the returned fields (SSID, AP, signal, protocol, data rates, IP, username, OS). It implicitly separates itself from cvcue_list_wired_clients by saying 'Wi-Fi', but never explicitly distinguishes itself from cvcue_find_client, which an agent could easily 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?

The only usage signal is 'Defaults to currently connected clients', which hints that historic lookups require the active flag. There is no explicit statement of when to use this versus cvcue_find_client, cvcue_list_wired_clients, or cvcue_client_health_summary, and 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?

With no annotations, the description must carry the behavioral burden. It does disclose two non-obvious traits: the result is flattened rather than nested, and querying a location returns data for its entire subtree. It says nothing about whether the list is tenant-wide by default, ordering, pagination, 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?

Two sentences, zero filler, and the most important fact (what you get back) is front-loaded before the scoping rationale. Every clause carries 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?

No output schema exists, so the description is responsible for the return shape, and it partially delivers by naming the four fields and stating the list is flat. For a one-optional-param read tool this is nearly sufficient; only ordering/default-scope behavior is left open.

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 optional parameter `name_contains` is fully documented there, including case-insensitivity and that it matches name or path. The description adds no parameter-level 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 ('List the CV-CUE location hierarchy'), clarifies the shape ('flat list') and names the returned fields (id, type, parentId, path). Combined with the sibling names, an agent can infer this is the enumeration counterpart to cvcue_get_location, though it never names that sibling explicitly.

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 line 'Location ids scope most other tools via `location_id`' gives a concrete reason to call this first, turning it into a setup/step-zero tool. It stops short of explicit exclusions (e.g. when to call cvcue_get_location instead of this), 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?

No annotations are supplied, so the description carries the full disclosure burden. "List" plus the enumerated returned fields makes the read-only, per-radio nature clear, but it says nothing about pagination defaults (page_size 100, max 500), result ordering, empty-result behavior, or whether unscoped calls return the whole estate — relevant since it defaults to 100 records across all managed APs.

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 whose parenthetical field list is the highest-value information for an agent choosing between radio-level and AP-level tools. No filler, no restatement 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?

For a zero-required-parameter, read-only list tool with a fully described schema and no output schema, the description covers purpose and returned fields adequately. It stops short of telling the agent how the scoping filters interact or how to page through a large radio estate, which is the remaining 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 description coverage is 100%, so all five parameters (start, active, ap_name, page_size, location_id) are already documented in the schema with defaults. The description adds no filter semantics — it doesn't explain that ap_name and location_id combine, or that active toggles to inactive radios — so 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 Wi-Fi radios across managed APs") and enumerates what each record carries — channel, width, tx power, noise, RF utilization, client count. The trailing clause "the RF view for channel/power analysis" separates it from the co-located cvcue_list_aps, which returns AP-level rather than radio-level data.

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 phrase "for channel/power analysis" implies the scenario where this tool is the right pick, which is more than nothing. However, it never names an alternative (e.g. cvcue_list_aps for AP inventory, cvcue_ap_health_summary for rollups) or states when not to use it, so the agent must infer the boundary.

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?

No annotations are supplied, so the description carries the full behavioral burden; it does at least establish that this is a read/listing operation over WIPS-detected APs and enumerates the returned attributes. It omits whether results are paginated, whether they are cached or live, and any permission requirements for WIPS data.

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 what is listed and follows with the returned fields; no filler. It is slightly dense in its parenthetical value list, but nothing is 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 5 optional parameters, full schema documentation and no output schema, the description's enumeration of returned fields (SSIDs, vendor, signal, clients) usefully substitutes for the missing return-value documentation. What remains thin is the relationship to adjacent AP/rogue-summary tools, but the core call-and-interpret story is 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% (every parameter, including the four classification values and the page_size cap, is documented in-schema), so the baseline is 3. The description adds only the notion of filtering 'by classification', which restates the group parameter without new syntax or semantics.

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

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

States a specific verb and resource ('List APs detected by CV-CUE WIPS sensors') plus the classification dimension and the fields returned (SSIDs, vendor, signal, clients). This clearly separates it from the managed-AP listing, though it never names the sibling it is distinct from (cvcue_list_aps / cvcue_rogue_ap_summary), which keeps it 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?

Usage is implied by the WIPS/rogue framing and the 'by classification' phrasing, so an agent can infer this is for inspecting detected-but-unmanaged radios. There is no explicit when-to-use-vs-alternative guidance, e.g. when to prefer cvcue_rogue_ap_summary for aggregate counts or cvcue_list_aps for managed inventory.

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?

No annotations are supplied, so the description carries the full burden; it does disclose the returned fields, which is the most useful behavioral detail here. It is silent on ordering, pagination/result limits, and permission requirements, and 'List' only implicitly signals a read-only, non-destructive 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?

Two sentences, zero waste: the payload of returned fields is front-loaded and the alternative-tool pointer comes second. Nothing repeats the tool name or restates the 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 simple read-only list tool with two optional, fully documented parameters, the description covers purpose, return shape, and the detailed alternative. Minor gaps remain around result volume and location scoping behavior, but nothing an agent needs to invoke 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 location_id and include_subtree are already documented, and the phrase 'where the profile was created' only loosely gestures at location scoping. The description adds no syntax, defaults, or subtree semantics 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 and resource ('List SSID profiles (WLANs)') and enumerates exactly what is returned — name, enabled, VLAN, security mode, guest, client isolation, creation location. This distinguishes it cleanly from cvcue_get_ssid, which is named as the detailed counterpart.

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 routes the agent to cvcue_get_ssid when the full configuration is needed, which is a clear use-vs-alternative condition. It does not address the other SSID-adjacent siblings such as cvcue_ssid_usage or the write-side tools, so the routing is clear but not exhaustive.

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?

No annotations exist, so the description bears the full burden, and it does disclose a non-obvious behavioral trait: results cover only switches seen over AP LLDP uplinks, meaning directly-attached or unuplinked switches will not appear. It does not state read-only semantics explicitly or describe pagination/aggregation behavior, which keeps 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 dense sentences with zero filler, and the critical qualifier (LLDP-discovered via AP uplinks) is front-loaded before the field list. Every clause carries information the agent can act on.

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 three-parameter read-only inventory tool with no output schema and no annotations, the description compensates well by enumerating the returned fields and the discovery mechanism. The remaining gap is that location scoping and paging semantics are left entirely to 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 start, page_size and location_id are already fully documented in the schema, making 3 the baseline. The description adds no meaning beyond the schema — notably it never mentions that location_id narrows the inventory to a location subtree, nor that the counts are per page.

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 definition pairs the specific verb 'List' with the resource 'switches' and immediately qualifies the data source ('discovered via AP uplinks (LLDP)'), which distinguishes it from sibling inventory tools like cvcue_list_aps or cvcue_list_radios. It also enumerates the fields returned (name, vendor, chassis id, AP/client counts, PoE and link-speed distribution), so an agent knows exactly what this call yields.

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 resource name and the LLDP provenance, but there is no explicit 'use this when…' statement and no exclusion of alternatives. Since no sibling tool covers switches, the lack of a named alternative is a smaller gap, but the agent still has to infer when this is the right call versus a general AP or location listing.

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?

No annotations are supplied, so the description carries the full burden; it does disclose the data source (AP LAN ports) and the fields returned, which tells the agent this is a read operation over AP-observed wired hosts. It says nothing about pagination behavior, freshness of the traffic counters, or what happens when a host is seen on multiple ports.

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 zero filler; the parenthetical field list packs in return-value detail without padding. Nothing could be cut without losing information.

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

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

For a simple, read-only, three-parameter list tool with no output schema, the description usefully enumerates the returned fields and the observation point, which substitutes for the missing output schema. The remaining gap is routing guidance versus cvcue_list_clients and cvcue_find_client.

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% (offset, page size max 500, location subtree scoping all documented in the schema), so the description need not repeat them. It adds no scoping hints of its own, making 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 and resource ('List wired hosts seen on AP LAN ports') and enumerates the returned fields, which implicitly separates it from the wireless-oriented cvcue_list_clients. It stops short of naming that sibling explicitly, so the differentiation requires the agent to infer it.

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: 'wired hosts' suggests this is the tool for wired clients while cvcue_list_clients covers wireless, but no when/when-not guidance or explicit alternative is given. The agent must already know the sibling landscape to choose correctly.

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

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

No annotations are supplied, so the description carries the burden. It discloses the metric categories and the child-location breakout, implying a read-only analytics call, but never states permissions, whether results are live vs. aggregated over the look-back window, or how large the response may be.

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 resource first and the metric families as a compact list. Dense but readable; the trailing dashboard reference is mildly decorative rather than informative.

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

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

With no annotations and no output schema, the description must stand alone, and it does cover what data comes back at a category level. Missing is the default scope when location_id is null and any hint of result shape or aggregation, which an agent would want before calling a metrics endpoint.

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 ssid, hours, and location_id are already documented, including the note that children are broken out. The description adds scope framing (location plus children) but no new meaning for any parameter, so 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?

Names the resource (network health metrics) and its scope (a location plus each child location), and enumerates the metric families covered: connectivity, performance, application experience, infrastructure. That is more specific than the sibling health tools (cvcue_ap_health_summary, cvcue_client_health_summary), though it never explicitly says how it differs from them.

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 location-level rollup to call when it wants broad health across a site and its children. There is no explicit when-to-use, no mention of when to prefer the AP- or client-level health siblings, and no prerequisites 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?

No annotations are provided, so the description carries the full disclosure burden. It does add genuinely useful behavior: results are ordered newest first, and each record carries severity, category, type, summary and timestamps. It does not state that this is a read-only query, whether results are paginated beyond the limit, or any 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 compact sentence with the resource and ordering front-loaded and no filler. The parenthetical category list earns its place by scoping what 'events' means, though the trailing field enumeration is somewhat list-like.

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

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

With no output schema and no annotations, the description compensates reasonably by describing the returned fields and sort order. For a read-only query tool with fully documented parameters, this is nearly sufficient; only the read-only nature and any auth/rate-limit context are 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 all six parameters are already documented in the schema, making 3 the baseline. The description adds little parameter-level meaning beyond listing the event categories that the returned 'type' field can take, which is mild value for interpreting results rather than for constructing the call.

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

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

The description names the specific resource (CV-CUE events/alerts) and enumerates the event categories it covers (WIPS, performance, connectivity, system), plus the fields returned. It does not explicitly differentiate itself from the sibling cvcue_event_summary or cvcue_client_events, so an agent must infer the boundary, but the purpose itself 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 when-to-use guidance and no mention of alternatives, even though cvcue_event_summary and cvcue_client_events are close siblings that an agent could easily confuse with this tool. The only implicit signal is 'Recent', which hints at a time-windowed listing but never says when to prefer this over the summary 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?

With no annotations, the description carries the full burden and does disclose the key destructive side effect ('clients will be disconnected') plus the write-enable and confirm gating. It does not cover whether the reboot is applied atomically to all listed MACs, how invalid/unknown MACs are handled, or whether the call blocks until APs return.

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 compact sentences, with the action and its risk front-loaded ahead of the prerequisite flags. No filler and nothing redundant.

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 two-parameter destructive tool with no annotations and no output schema, the definition covers what it does, its blast radius, and its safety gating. Remaining gaps (partial-failure behavior, return value, per-AP vs. bulk semantics) are minor but non-zero for a write operation.

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, including confirm's 'must be true to proceed'. The description merely restates that confirm requirement and adds no format or batching semantics for mac_addresses beyond what the schema 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 ('Reboot one or more managed APs') plus the immediate consequence in parentheses. An agent knows exactly what action is performed, though the description does not distinguish this from a nearby destructive sibling like cvcue_disconnect_client (single client vs. whole AP and its attached clients).

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

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

It gives hard preconditions (CVCUE_ENABLE_WRITES=true and confirm=true) which is useful gating, but says nothing about when to prefer this over alternatives such as disconnect_client, or when a reboot should be avoided (e.g., during active troubleshooting). Usage context is implied rather than stated.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does usefully disclose the shape of the result (aggregate counts, associated clients, top vendors/SSIDs among rogues), which goes beyond a bare purpose statement, but it says nothing about read-only safety, permissions, result size, or scoping behavior when location_id is omitted.

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 compact sentence in a label-plus-list structure, front-loaded with the domain context 'WIPS overview' and then the contents. It is a noun-phrase fragment rather than a sentence, but nothing is redundant.

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

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

With no output schema, the description correctly takes on the job of describing the returned metrics, and it does so concretely. Combined with a fully documented single parameter, an agent has enough to call it, though the lack of annotations leaves safety/scoping assumptions unstated.

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 parameter location_id is already documented as 'Scope to a location subtree.' The description adds no additional meaning about that parameter (e.g., whether omitting it returns all locations), 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 names the resource (WIPS rogue/detected AP data) and enumerates the specific aggregates returned: counts per classification, rogue APs with associated clients, top vendors, and top SSIDs. It is clear it is an aggregate overview rather than a raw list, though it never explicitly contrasts itself with the sibling cvcue_list_rogue_aps.

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 when-to-use statement, no exclusion, and no mention of the obvious alternative (cvcue_list_rogue_aps for per-AP detail). An agent must infer from the word 'overview' that this is the dashboard-style rollup and not the detailed listing.

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?

No annotations are provided, so the description carries the full burden. It discloses the three categories of data returned, which is the main behavioral fact for a zero-parameter info tool, but it never states explicitly that the call is read-only, requires no elevated permissions, or has no side effects, and gives no hint about response shape or size.

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 the returned data front-loaded before the usage hint. Every clause carries information and there is no filler or repetition of the tool name.

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

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

For a no-parameter, no-output-schema informational tool, the description covers the essentials: what data comes back and a reason to call it. The only real gap is the unaddressed overlap with cvcue_api_modules and the lack of any indication of what 'server health' comprises.

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 of 4 applies. The description correctly implies a parameter-free call.

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

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

The description names specific resources: server version, supported API module versions, and server health. It is clearly an informational lookup, but it does not distinguish itself from the sibling cvcue_api_modules, which plausibly covers overlapping 'supported API module' territory.

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 sentence 'Use to check whether an endpoint/version is available on this server' gives a concrete preflight use case. However, it offers no when-not guidance and never names the overlapping sibling cvcue_api_modules or cvcue_session_info, so an agent must guess which tool to call for module listings.

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?

No annotations are supplied, so the description carries the burden. 'Show' implies a read-only operation, and the connectivity-check framing adds useful behavioral context, but it does not explicitly declare that the call is non-mutating or describe any auth/permission expectations beyond noting a logged-in key/user.

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 zero waste: the returned fields come first, and the practical usage hint is front-loaded at the end. Nothing is redundant.

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

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

With no output schema and no annotations, the description compensates by enumerating what the response contains, which is the key missing piece. Slightly incomplete in not stating that it is a read-only, permission-scoped call, but strong overall for a zero-argument diagnostic tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description usefully clarifies that all output is derived from the active session rather than requiring input.

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

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

States a specific verb and resource ('Show the current CV-CUE API session') and enumerates the fields returned: key/user, role, customer, timezone, allowed locations, base URL and version. It is clear, though it does not distinguish itself from the sibling cvcue_server_info, which also appears to cover server URL/version.

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?

'Good first call to confirm connectivity' gives one concrete usage scenario but no explicit when-not conditions or named alternatives (e.g., cvcue_server_info vs this tool). Usage is implied rather than fully directed.

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?

No annotations exist, so the description carries the full burden. It does usefully disclose that the call is a GET (read-only) and that the data is live rather than historical, but it says nothing about freshness/staleness, pagination, or whether the counts are instantaneous or averaged.

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 plus an endpoint parenthetical, with zero filler. The reader learns the data domain and the return fields in two lines.

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 only two optional parameters and no output schema, the description does the main remaining work: it enumerates the fields the caller gets back (broadcast status, bands, AP/client counts). It falls short of fully describing return structure or aggregation semantics, which matters slightly given no 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 description coverage is 100%, so both parameters (active_only, location_id) are already documented in the schema. The description's mention of 'which SSIDs are broadcast' lightly reinforces active_only, and 'per SSID/WLAN' scoping aligns with location_id, but it adds no new meaning such as how the location subtree filter interacts with AP/client counts.

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 resource and verb: live per-SSID/WLAN monitoring data, enumerating broadcast SSIDs, bands, and AP/client counts. It also names the underlying endpoint (GET /manageddevices/aps/wlans). It does not explicitly contrast with sibling cvcue_list_ssids or cvcue_get_ssid, so an agent must infer the config-vs-usage distinction.

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 'live monitoring data' and the usage-count framing, which suggests this is for observing current SSID deployment rather than reading SSID configuration. There is no explicit when-to-use statement, no exclusions, and no pointer to cvcue_list_ssids for the configuration view.

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?

With no annotations supplied, the description carries the full burden, and it does disclose one genuinely useful trait: partial failures (e.g. permission errors) are reported inline rather than aborting the call. It does not say that the operation is read-only, whether it is expensive/slow given it fans out across several subsystems, or how the composite result is structured.

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 use case, then a compact enumeration of the sections returned, plus one sentence on failure handling. Every clause carries information; only minor tightening of the line-wrapped list would improve it.

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

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

For an aggregation tool with no output schema, enumerating the returned sections effectively substitutes for a return-value description, and the inline-failure note covers the main failure mode. Nothing an agent needs in order to call this correctly with a MAC and an optional hour window 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 mac_address and hours are already documented, and the description only reinforces the MAC scoping. 'Recent' hints at the look-back window but adds no format or default detail beyond the schema's 'default 24'.

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 resource (a single client, keyed by MAC) and enumerates exactly what it aggregates: client record, associations, connection logs, failure events and root-cause inferences. The word 'one-shot' plus that enumeration separates it from narrower siblings such as cvcue_client_events or cvcue_client_association_history, though it never names those siblings directly.

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?

'One-shot client troubleshooting' gives a clear context: reach for this when diagnosing one client rather than pulling individual data slices. It stops short of explicit exclusions or alternatives, so an agent must infer that the narrower sibling tools exist for focused queries and that bulk/multi-client work belongs to cvcue_list_clients.

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