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

With no annotations provided, the description carries the burden and does well: it discloses input validation against the OpenAPI spec, the read/write execution split, the server-side env-flag gate, and the human-approval requirement for mutations. It stops short of saying whether writes are reversible, how failures surface, or how list responses are shaped/truncated.

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 with the core contract first, then the validation guarantee, then the read/write gating. Nothing is padded and no sentence could be dropped without losing a constraint an agent needs.

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

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

For a six-parameter nested-object dispatcher with no annotations and no output schema, the critical call-time facts (identifier source, spec validation, write gating, approval) are all present. Remaining gaps are response shape and error behavior, which matter less here because the payload is dictated by the underlying vManage operation rather than by this tool.

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

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

Schema coverage is 100%, so the schema alone justifies a 3; the description earns the bump by framing body/query/path_params as spec-validated inputs that must be looked up via describe_api_operation, and by tying operation_id to search_api_operations. The confirm semantics it states largely restate the schema text, and max_items is left to the schema.

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

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

Opens with a specific verb+resource ("Call any vManage API operation by operation_id") and immediately distinguishes itself from the discovery siblings by naming the identifier it consumes, which the schema ties back to search_api_operations. An agent can tell this is the execution endpoint of the search/describe/call triad 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?

Clearly separates the read path (runs directly) from the write path (needs VMANAGE_ALLOW_WRITE=true plus confirm: true after user approval), which is exactly the precondition an agent must check before calling. The gap is that it never addresses when to prefer this generic dispatcher over the dozens of typed siblings like get_bgp_neighbors or get_omp_routes, leaving the main routing decision unstated.

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 does the work: 'Show' signals a non-mutating lookup, and it explicitly enumerates what information is returned (params, body schema/example, access level, description), which is a solid disclosure for a read-only introspection tool. It omits any mention of authentication or that the API spec must already be loaded, a minor gap.

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

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

A single front-loaded sentence with the resource and returned fields packed in; no filler, nothing 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 a one-parameter read tool with no output schema, the description usefully enumerates the returned content, compensating for the missing output schema. The only shortfall is the absence of workflow guidance tying it to search_api_operations and call_api_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 coverage is 100% and the single parameter's description already explains that operation_id comes from search_api_operations. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Show') and enumerates the resource content it returns (parameters, request body schema/example, access level, description) scoped to 'one vManage API operation'. This is clearly distinguishable from search_api_operations and call_api_operation by the word 'documented' and the singular scope, though it never names 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 description body gives no explicit when/when-not guidance or alternatives. The usage chain is only implied: the schema's operation_id description ('operationId from search_api_operations') suggests searching first, and 'Show documented parameters' implies inspecting before call_api_operation, but the agent must infer this.

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 behavioral burden. "Get" implies a read, but it does not explain permissions, freshness, time window, or what "being logged" means operationally, leaving important behavioral context undisclosed.

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 filler or redundant phrasing. Every part of the sentence contributes to identifying the operation.

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

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

For a simple one-parameter read tool, the description covers the core purpose adequately. However, with no annotations and no output schema, it still omits useful context such as what the count represents, whether it is current or historical, and what the return value looks like.

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

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

Schema coverage is 100%, and the single device_id parameter is already documented as "Device ID or system-ip." The description adds no parameter meaning beyond what the schema provides, 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?

The description states a specific verb and resource: getting a count of packet flows logged for a device. It is clearly distinguishable in concept from flow-listing siblings like get_app_log_flows or get_cflowd_flows, but it does not explicitly name or differentiate from those alternatives.

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

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

There is no guidance on when to use this tool versus get_app_log_flows, get_cflowd_flows, or get_cflowd_statistics. The word "count" implies aggregate usage, but the description provides no explicit when-to-use or when-not-to-use context.

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

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

With no annotations, the description carries full behavioral burden, and it discloses almost nothing. It doesn't state that this is a read-only operation, doesn't mention time range or default window for flow data, log volume, pagination, or permissions. For a flow-log retrieval tool these omissions matter to correct invocation.

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 or redundancy. It is efficient, though its brevity edges toward under-specification rather than optimal density.

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 and no annotations, so the description must fill in the blanks itself — and it doesn't. It never explains what fields the flow logs contain, the default time window, or how much data comes back. For a telemetry-retrieval tool this leaves the agent guessing.

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 is documented as 'Device ID or system-ip,' so the schema does the heavy lifting. The description adds nothing beyond 'for a device,' which merely restates the required parameter. Baseline 3 is appropriate.

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

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

States a specific verb and resource: 'Get packet flow logging information' scoped to 'a device.' An agent can tell it retrieves flow logs rather than config. However, it does not differentiate itself from close siblings such as get_cflowd_flows or get_app_log_flow_count, leaving the exact data source 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?

There is no guidance on when to use this tool versus alternatives. Given siblings get_cflowd_flows and get_app_log_flow_count exist, the absence of any routing hint is a real gap. The only implied usage is 'you want flow logs for a device.'

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 behavioral burden. The verb 'Get' implies a read, but there is no disclosure of permissions, return shape, or what SLA class data includes; it adds little beyond restating the name.

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 clearly stated and no filler. It is appropriately sized, though quite thin.

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

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

For a simple one-parameter read with no output schema, the description covers the basic purpose. However, with no annotations and no indication of what SLA class data is returned or when the tool is relevant, it is only minimally adequate.

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

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

The single parameter has 100% schema description coverage ('Device ID or system-ip'), so the schema already does the work. The description adds no further detail about the parameter, making the baseline 3 appropriate.

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

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

States a specific verb (Get) and a specific resource (SLA class information for application-aware routing) scoped to a device. It's clearly distinct from siblings like get_app_route_statistics in subject matter, though it doesn't explicitly name the sibling boundary.

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

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

The description gives no when-to-use guidance, no prerequisites, and no alternatives. An agent must infer context entirely from the tool name and the SLA/routing terminology.

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 of behavioral disclosure. It implies a read-only statistics retrieval, but does not state whether the stats are real-time or cumulative, what time window applies, whether device connectivity is required, or what the response includes.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently states the resource and scope.

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

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

For a simple one-parameter read tool, the description is minimally sufficient to identify the operation. However, with no annotations and no output schema, it leaves behavioral details and expected return information implicit.

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

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

The single device_id parameter is fully documented in the schema as accepting a device ID or system-ip. The description does not add meaning beyond the schema, so the high schema coverage baseline of 3 applies.

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

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

The description states a specific verb and resource: get application-aware routing statistics, clarified as tunnel stats, for a device. It is clearly distinct from generic siblings, though it does not explicitly contrast with closely related tools like get_app_route_sla_class or get_sdwan_stats.

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

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

There is no guidance on when to use this tool versus related routing/statistics tools, nor any stated prerequisites such as device reachability or required permissions. The phrase 'for a device' implies context but does not provide usage 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?

No annotations are provided, so the description carries the full disclosure burden, yet it only says 'Get'. It does not state the operation is read-only, whether results are paginated or bounded, whether devices from child/derived templates are included, or what happens with an invalid template ID.

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. It is efficient, though its brevity reflects under-specification rather than tight editorial trim.

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 should at least hint at the shape of the result (device IDs vs. full records) and the scoping semantics of 'attached'. It stops short of that, so the agent must probe the response to learn what comes back.

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 is required with a description, so the baseline is 3. The phrase 'specific device template' mildly reinforces that template_id is a template (not a device) identifier, which is useful disambiguation but adds little beyond the schema.

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

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

States a concrete verb and resource ('Get devices attached to a specific device template'), so the agent knows exactly what the call returns conceptually. It does not differentiate against near-neighbors such as list_devices or get_device_details, leaving the agent to infer the template-scoped 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 only implied: you call it when you already have a template ID and want its membership. There is no explicit when-to-use versus list_devices or get_device_details, and no prerequisite or exclusion 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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It says 'Get' but does not describe read-only safety, required permissions, whether results are current or historical, pagination, or return behavior.

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

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

The description is a single front-loaded sentence with no wasted text. It is appropriately sized for a simple one-parameter lookup 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?

The tool has low complexity and full schema coverage, so the description is adequate to support invocation. However, with no annotations and no output schema, it could do more to describe return content or operational context.

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

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

Schema description coverage is 100%, and the single parameter is documented as 'Device ID or system-ip.' The description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Get BFD sessions') and scopes it to a device. It is clear what the tool retrieves, but it does not explicitly differentiate itself from close BFD siblings such as get_bfd_summary and get_bfd_tloc.

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 guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The intended usage is only implied by the tool name and resource.

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. 'Get' implies a read, but nothing states permissions, whether the device must be reachable, pagination, or what a summary contains versus raw session data — significant gaps for a monitoring tool 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?

A single front-loaded sentence with no filler. It is efficient, though its brevity comes partly from omitting useful differentiation.

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 a fully documented schema and no output schema, this is minimally viable, but the absence of any distinction from sibling BFD tools and any return-shape hint leaves an agent guessing in a crowded BFD/sibling namespace.

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

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

Schema coverage is 100% and the sole parameter is documented as 'Device ID or system-ip'. The description adds no meaning 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 ('Get BFD session summary for a device'), but does not distinguish it from the close sibling get_bfd_sessions or explain what makes this a 'summary' versus a full session listing. The scope is vague enough that an agent can't confidently choose between the two BFD tools.

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

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

No guidance on when to use this versus get_bfd_sessions, get_bfd_tloc, or get_bfd_sessions for a device. The only implied context is that it's per-device, which the schema already conveys via the required device_id.

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. 'Get' implies a read operation, but it does not state read-only semantics, permissions, rate limits, or what 'summary' actually 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?

A single short sentence that front-loads the action and resource with zero filler. 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 simple one-parameter read tool this is minimally adequate, but with no output schema and no annotations, the description could explain what the per-TLOC BFD summary contains or what TLOC means in context.

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

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

Schema coverage is 100% and the single device_id parameter is documented as 'Device ID or system-ip'. The description adds no extra parameter meaning beyond the schema, which is the expected 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: get BFD session summary, scoped per TLOC for a device. It is clear what it does, but it doesn't distinguish itself from siblings like get_bfd_sessions, get_bfd_summary, or get_device_tloc.

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

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

No guidance on when to use this tool versus get_bfd_sessions, get_bfd_summary, or get_omp_tlocs. The 'per TLOC' scope hints at usage but no exclusions or alternatives are named.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read-only lookup, but nothing is said about return shape, whether results are live-cached, or behavior when BGP is not enabled on the device.

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 short sentence with zero filler and the resource/scoping front-loaded. It is efficient, though its brevity reflects under-specification rather than discipline.

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

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

With no output schema and no annotations, the description should convey what a 'neighbor' record contains (peer address, AS, state, uptime) to let an agent judge relevance against get_bgp_routes/get_bgp_summary. It says nothing about return content.

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

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

Schema coverage is 100% and the single parameter (device_id, accepting ID or system-ip) is fully documented in the schema. The description adds nothing beyond that, 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 ('Get BGP neighbors') scoped to a device, which is unambiguous about what it returns. However, it does not distinguish itself from close siblings such as get_bgp_routes and get_bgp_summary, which an agent must choose between.

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

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

There is no guidance on when to use this versus get_bgp_routes or get_bgp_summary, nor any prerequisites (e.g., whether the device must have BGP configured). The device scoping is only implied by the parameter name.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing beyond the implied read operation. It does not state whether results are paginated, what route attributes are returned, or whether device type or permissions affect availability.

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 single sentence is front-loaded and free of filler. Its terseness is a completeness problem rather than a conciseness problem, so it scores well here but not perfectly.

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

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

For a tool with no annotations and no output schema, the description should explain what kind of route data is returned and how it relates to the BGP neighbors/summary siblings. It leaves both the return semantics and the tool-selection context unaddressed.

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

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

There is only one parameter, and the schema already documents it at 100% coverage as 'Device ID or system-ip'. The description adds no further semantics, 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 a clear verb (Get) and resource (BGP routes) scoped to a device. It does not, however, distinguish this tool from closely related siblings like get_bgp_neighbors, get_bgp_summary, or get_omp_routes.

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

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

There is no guidance on when to use this tool versus get_bgp_neighbors or get_bgp_summary, nor any prerequisites or exclusions. An agent must infer usage from the tool name alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read operation but never states that it is read-only, what permissions or device reachability are required, 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?

A single, front-loaded sentence with no wasted words. It is appropriately sized, though also under-specified rather than richly concise.

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

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

For a one-parameter read tool with a fully documented schema and no output schema, the description covers the basic purpose. It remains thin on scope—such as whether the summary is per-VRF, IPv4/IPv6, or session-state oriented—and on return behavior.

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

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

Schema description coverage is 100% for the single device_id parameter, so the schema already documents the accepted ID formats. The description adds no additional parameter meaning, but the baseline is 3 when the schema is complete.

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: 'Get BGP summary'. An agent can tell it retrieves BGP summary data, but the description does not distinguish it from closely related siblings such as get_bgp_neighbors or get_bgp_routes.

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

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

The description gives no guidance on when to use this tool versus get_bgp_neighbors or get_bgp_routes, and no prerequisites or exclusion conditions are mentioned. Usage must be inferred from the tool name alone.

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

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

No annotations are provided, so the description must carry the full behavioral burden. 'Get' implies read-only behavior, but the description does not disclose permissions, data freshness, pagination, response format, or what the bridge forwarding table 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?

The description is a single front-loaded sentence with no wasted words. For a simple one-parameter read tool, this is appropriately concise.

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

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

The tool is simple, has one fully documented parameter, and no output schema. However, without annotations or an output schema, the description does not explain return values or behavioral constraints, leaving it minimally viable rather than 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 coverage is 100%, and device_id is documented as 'Device ID or system-ip.' The description only says 'for a device' and adds no further parameter meaning, so it neither compensates nor detracts from the schema 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 uses a clear verb and resource: 'Get bridge forwarding table for a device.' It is specific enough to understand the operation, but it does not distinguish this from many sibling get_* diagnostic tools such as get_device_arp or get_device_interfaces.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, exclusions, or expected context. The only implied usage is that a device_id is required, which comes from the schema.

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 behavioral-disclosure burden. 'Get' implies a read operation, but the description does not explicitly confirm read-only behavior, authorization needs, rate limits, aggregation behavior, or what 'validity summary' includes.

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

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

The description is a single efficient sentence with no waste. The operation and resource are front-loaded immediately.

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

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

For a parameterless summary tool, the description identifies the domain but does not explain the returned summary structure or any scope limits. With no output schema and no annotations, that leaves an agent with adequate but incomplete context.

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

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

The tool has zero parameters, so there is no parameter semantics to document. The baseline for a parameterless tool is 4, and the description does not introduce confusion about inputs.

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

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

The description states a specific verb and resource: 'Get certificate validity summary for devices.' This clearly identifies the operation and the certificate-validity domain, which no sibling tool name duplicates. It does not explicitly contrast with sibling summary tools, so it falls short of a 5.

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

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

The phrase 'for devices' gives a scope hint, but the description does not say when to use this tool, when not to use it, or which sibling summary tool to prefer. There are no prerequisites or alternative-routing instructions.

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 not say whether results are time-bounded, paginated, aggregated, or how large the response may be, leaving the agent unable to predict the behavior of this read call.

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 short sentence with no filler, and the resource is front-loaded. It is arguably too terse for a tool with zero annotations, but it wastes no words.

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

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

With no annotations and no output schema, the description should explain the return shape, temporal scope, and any aggregation or pagination behavior. Instead it supplies only a bare purpose, leaving significant gaps for a data-retrieval tool.

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

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

Schema description coverage is 100%, so the single device_id parameter is already documented as 'Device ID or system-ip'. The description adds only the loose phrase 'for a device' and no format, alternative identifier, or default details beyond the schema.

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

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

States a clear verb and resource (get cflowd flow information) scoped to a device. However, it does not distinguish itself from nearby siblings like get_cflowd_statistics or get_app_log_flows, so the agent cannot tell from the description alone which flow-related tool applies.

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

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

No indication of when to use this versus get_cflowd_statistics, get_app_log_flows, or get_app_log_flow_count. The only implicit guidance is the device scoping, with no exclusions or alternatives named.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read, but nothing is said about required permissions, whether the device must be actively exporting cflowd data, or what the statistics contain (aggregation window, counters, error states).

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. It is efficient, though the brevity is partly under-specification rather than tight writing.

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

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

With no output schema and no annotations, the description should at least indicate what statistics are returned or the data window. As written, an agent knows the target resource but not what it will get back or under what conditions the call succeeds.

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 'Device ID or system-ip'. With only one parameter and full schema documentation, baseline 3 applies; the description adds no format or selection detail beyond 'a device'.

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 verb (Get) and resource (cflowd packet statistics) scoped to a device, which is interpretable. However, it does not distinguish itself from the nearby sibling get_cflowd_flows, so an agent cannot tell from this text alone when 'statistics' ends and 'flows' begins.

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

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

There is no guidance on when to use this over get_cflowd_flows, get_app_route_statistics, or get_sdwan_stats, nor any prerequisites such as cflowd being enabled on the device. The agent must infer the use case.

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

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

With no annotations, the description carries the full burden. 'Get' implies a read operation, but it says nothing about permissions, whether the response is per-device or global, pagination, or how large the config payload may be. For a cloud-controller query tool this is a significant gap.

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

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

A single front-loaded sentence with no filler. It is efficient, though the brevity borders on under-specification rather than tightness.

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, no annotations, and no parameters, the description is the only source of information an agent has, and it does not describe the shape of the returned apps/VPN configuration or the scope of the query. It is not wrong, but it is too thin for an unannotated tool with no output contract.

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

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

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. Schema coverage is 100% trivially.

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

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

The description names a specific verb and resource: retrieving CloudExpress apps and VPN configuration. However, it does not say how this differs from sibling tools like get_cloudx_status, get_cloudx_gateway_list, get_cloudx_client_list, or get_omp_cloudx, so an agent must guess which endpoint surfaces apps/VPN data versus status or client lists.

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

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

There is no guidance on when to call this tool, what prerequisites exist, or which sibling to prefer for adjacent CloudExpress data. The agent is left to infer everything from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond a bare 'Get'. It does not confirm read-only safety, note pagination or result size limits, or describe what happens on empty results. For a zero-annotation tool this is a meaningful gap, though 'Get' weakly implies a non-mutating read.

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 short sentence with no filler, suitably sized for a trivial zero-parameter read. It is front-loaded with the verb and resource, though it is arguably under-specified rather than genuinely concise.

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

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

With no annotations and no output schema, the description is the only source of behavioral and return-value information, and it supplies neither. It does not say what fields each client/site entry contains or how the list is ordered. For a simple list tool this is thin enough to leave the agent under-informed before calling.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies a simple, unfiltered listing with nothing to configure, and there are no parameters whose meaning needs elaboration.

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 verb ('Get') and a resource ('CloudExpress client/site list'), so the basic operation is discernible. However, it never clarifies how 'CloudExpress' relates to the many sibling tools prefixed get_cloudx_* (get_cloudx_status, get_cloudx_gateway_list, get_cloudx_apps), leaving an agent unsure whether this is a distinct service or a synonym. The slash-joined 'client/site' also leaves the resource identity slightly 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?

There is no statement of when to use this tool versus the numerous get_cloudx_* siblings or the broader listing tools like list_devices. No prerequisites, no scoping conditions, no exclusions are given. The agent must infer usage purely from the name.

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

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

With no annotations, the description carries the full behavioral burden, and it only weakly implies read-only via the verb 'Get'. It says nothing about return contents, pagination, scoping, or whether gateways are filtered by anything.

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?

It is a single short, front-loaded sentence with no waste, but it is a bare label rather than a usefully concise definition. Brevity here comes at the cost of all substance.

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 annotations, no output schema, and no parameter docs mean the description is the only source of context, and it supplies almost none. An agent cannot tell what a gateway entry is, whether results are filtered, or how this relates to other CloudX listing tools.

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

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

The tool takes zero parameters, so the schema-side burden is minimal and the description has no parameter meaning to convey. Baseline for a no-param tool applies, with a slight deduction because nothing describes output shape either.

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 restates the tool name almost verbatim ('Get CloudExpress gateway list' for get_cloudx_gateway_list), adding no specificity. It doesn't clarify what a 'gateway list' contains or how it differs from nearby siblings such as get_cloudx_client_list, get_cloudx_apps, or get_omp_cloudx.

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

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

There is no guidance on when to call this versus the many CloudX-related siblings (get_cloudx_status, get_cloudx_client_list, get_cloudx_apps, get_omp_cloudx). The agent must infer selection from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read operation, but the description does not state freshness, aggregation behavior, whether CloudExpress must be enabled, or what the status output represents beyond 'sites per application.'

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 definition is a single concise sentence with the core resource and scope front-loaded. There is no redundant or filler text.

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 status tool, the description is minimally sufficient but leaves out useful context such as whether results are aggregated, how staleness is handled, and how it relates to the other CloudExpress tools. With no output schema, the description could do more to set expectations about the returned status.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. This matches the baseline expectation for a no-parameter tool.

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 and resource: 'Get CloudExpress (Cloud OnRamp) status,' and adds scope with 'sites per application.' It is clear what the tool retrieves, but it does not differentiate itself from nearby CloudExpress siblings such as get_cloudx_apps, get_cloudx_gateway_list, or get_omp_cloudx.

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

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

The description gives no guidance on when to use this tool versus the many sibling tools, including get_cloudx_apps, get_cloudx_gateway_list, get_cloudx_client_list, and get_omp_cloudx. It also provides no exclusions or 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 carries the full burden; 'Get' implies a non-destructive read, and 'per node' hints that results are broken down by cluster node rather than aggregated. Beyond that it says nothing about authentication requirements, error behavior when a node is unreachable, or cost/latency, which are real gaps for a cluster-wide query.

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, appropriately sized for a zero-parameter read tool. Every word (vManage, cluster, health, per node) constrains meaning.

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

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

There is no output schema and no annotations, so the description is the only source of return-value information; 'health status per node' gives the shape but not what fields constitute 'health' (node role, election state, service liveness, etc.). Adequate to call correctly, but thin for interpreting the response.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description does not claim any filtering options, which correctly matches the empty schema.

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

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

States a specific verb ('Get') and a specific resource ('vManage cluster health status') with a scope qualifier ('per node'), which distinguishes it from generic status siblings like get_system_status or get_control_status. It does not explicitly name or rule out those siblings, but the resource is narrow enough to be identifiable.

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

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

No explicit when-to-use, when-not-to-use, or alternatives are given; the guidance is only implied by the phrase 'cluster health status'. An agent can infer this is for cluster-wide health checks on vManage, but must guess how it differs from the many other status tools in the sibling list.

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

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

No annotations exist, so the description carries the full burden. 'Get' clearly signals a read-only operation and the mention of embedded feature profiles/devices conveys return shape, but nothing is said about behavior when the group doesn't exist, permission requirements, or result 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?

One sentence, front-loaded with the verb and resource, with the identifier options and returned contents appended efficiently. No filler.

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

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

With no output schema, the description helpfully names the main returned components (feature profiles, associated devices). Missing only edge-case/error behavior for a lookup tool, which keeps it just short of 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 coverage is 100% and the single parameter is fully documented as 'Configuration group ID or exact name'. The description restates the same fact rather than adding matching rules, case sensitivity, or ambiguity handling, 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 ('Get one configuration group') and even outlines the payload (feature profiles and associated devices). It implicitly contrasts with list_config_groups by emphasizing 'one', though no sibling is named 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 parenthetical 'by ID or exact name' hints at how to identify the target, but there is no explicit guidance on when to use this versus list_config_groups, get_feature_profile, or get_attached_devices. Usage is inferable from the name and description only.

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. 'Get' implies a read, but the description says nothing about whether values reflect inherited or overridden variables, whether resolution requires the device to be attached to the group, or what the response contains. For a no-annotation tool this is a meaningful gap.

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

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

A single sentence with the scope qualifier front-loaded in parentheses; no filler, no repetition of the tool name or title.

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

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

The tool is simple (2 params, 1 required), but with no annotations and no output schema, the description should say more about what the returned variable set looks like and how inheritance or overrides are represented. It is minimally sufficient to call correctly but not to interpret results confidently.

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 both parameters are already documented in detail, including the accepted device identifier formats. The description adds one piece of meaning the schema omits — that omitting device returns values for all devices — but contributes nothing further about the config_group identifier or value semantics.

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

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

The description states a specific verb and resource ('Get device-specific variable values of a configuration group') and scopes it with '(all devices, or one device).' It clearly distinguishes variable values from plain group metadata, though it never names the near siblings get_config_group or preview_config_group_device_config to clarify the boundary.

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

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

The parenthetical '(all devices, or one device)' implies when to supply the device argument versus omitting it, which is useful. However, there is no explicit guidance on when to use this tool rather than get_config_group or preview_config_group_device_config, and no prerequisites 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?

No annotations are provided, so the description carries the full burden. 'Get' implies a read, but the description says nothing about whether config retrieval requires elevated permissions, whether the two modes touch different endpoints, or what the response contains. For an unannotated tool this is a meaningful gap.

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

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

A single front-loaded sentence with zero filler. Its brevity is appropriate, though it leaves content gaps handled under other dimensions rather than being padded here.

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

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

A simple two-parameter, no-output-schema read tool, so the bar is modest. However, the description never clarifies what 'affinity configuration' or 'affinity status' actually report, leaving an agent to guess at the returned content.

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

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

Schema description coverage is 100%, with both parameters documented and the 'type' enum including its default ('status'). The description adds no syntax, format, or meaning beyond what the schema already states, 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 a distinct resource ('controller group affinity configuration or status') scoped to a device. Among the many get_control_* siblings, this names a unique resource, so an agent can discriminate it, though it never explicitly contrasts itself with neighbors like get_control_status.

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

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

No guidance on when to use this tool versus the many other get_control_* siblings, and no guidance on when to request 'config' versus 'status'. The two modes are named but not explained, leaving the choice entirely to the schema enum.

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, yet it says nothing about read-only semantics, whether data is live versus cached (that detail lives only in the schema), latency, or what the response contains. The only behavioral hint is the peer scope (vSmart/vBond), which is thin for a zero-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 short sentences with zero filler, the core purpose front-loaded. Nothing redundant and nothing wasted.

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

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

For a 4-parameter, zero-annotation tool with no output schema, the description is adequate but sparse: it doesn't clarify return content or differentiate from the many neighboring control/OMP/validator tools. Schema coverage compensates for parameters, but the behavioral and disambiguation gaps remain.

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%, including clear descriptions for synced, peer_type, and system_ip, so the schema does the heavy lifting. The description adds no parameter-level meaning beyond the peer-type hint, 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 (get control plane connection status for a device) and adds scope with 'connections to vSmart/vBond'. It doesn't distinguish itself from close siblings like get_control_connections_history or get_validator_connections, so an agent must infer the boundary from the name alone.

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 guidance, no mention of prerequisites, and no routing to alternatives such as the history variant or summary tools. Only a minimal implied context ('for a device') is present.

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 behavioral burden. It discloses useful return-content categories (past connection attempts, errors, down reasons), but does not cover permissions, time range, freshness, pagination, or response structure. Some behavioral context is added, but significant gaps remain.

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 waste. The core action and scope appear first, and the parenthetical efficiently adds return-content detail without restating the name.

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

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

For a simple one-parameter tool, the description covers the basic purpose and lists the kinds of history returned. However, with no annotations and no output schema, it should clarify the time span of the history, any pagination behavior, or the response shape; those omissions leave the agent with an incomplete operational picture.

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 sole parameter device_id is documented in the schema as "Device ID or system-ip." The description does not add any parameter-specific meaning beyond that, 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: get control connection history for a device. The parenthetical clarifies the content as past connection attempts, errors, and down reasons. It does not explicitly name the sibling get_control_connections or explain the distinction, so it falls short of full sibling differentiation.

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

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

The description gives no explicit when-to-use guidance, no exclusions, and no alternatives. The implied use for troubleshooting past connection issues is present but only inferred from the purpose; an agent must decide on its own whether this or get_control_connections is appropriate.

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

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

No annotations exist, so the description carries the full behavioral burden, yet it discloses nothing beyond the aggregation itself. It does not say whether counts are a single total or a per-site/per-peer breakdown, whether results are cached or live, or anything about permissions or rates.

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

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

A single front-loaded sentence with no filler; the scope (fabric-wide) precedes the optional narrowing. Nothing is wasted.

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

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

For a one-parameter read tool with no output schema, the description covers the basic call but leaves the return shape ambiguous — 'counts' could mean one number or a structured breakdown. Minimal but not inadequate.

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 is already documented as 'Optional site ID'. The description adds one genuinely new semantic: omitting site_id yields fabric-wide counts rather than an error or empty result. That is useful but thin, keeping it at 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 ('Get ... control connection counts') plus a scope qualifier ('fabric-wide ... optionally for one site'). It implicitly separates itself from listing tools like get_control_connections by emphasizing aggregation, but it never names or contrasts a sibling such as get_control_statistics or get_network_connections_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 only implied: the agent infers 'call this when you want counts rather than a list' and 'pass site_id to narrow'. There is no explicit when-to-use/when-not-to-use guidance and no routing to alternatives among the many get_control_* siblings.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a read-only operation, but it does not explicitly state side-effect profile, permissions, return shape, or pagination behavior.

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

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

A single front-loaded sentence with no wasted wording. The scope qualifier is placed first, making the tool's breadth immediately clear.

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-only list tool, the description is sufficient to invoke it correctly, but without an output schema or annotations it leaves return shape and pagination unspecified. Adequate but with clear gaps.

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

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

Schema coverage is 100% and the single parameter is an enum with a description. The description adds no parameter details beyond the schema's 'state' enum, which is the expected baseline when the schema already documents the input.

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

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

States a specific verb ('list'), resource ('control connection links'), and scope ('Fabric-wide ... between all devices') plus a state filter. Clear enough to distinguish from a device-specific control connection query, though it does not explicitly name siblings like get_control_connections.

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

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

The description implies use for fabric-wide control-link queries in a given state, but provides no explicit when-to-use guidance, prerequisites, or alternatives such as get_control_connections or get_control_connections_history.

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 behavioral-disclosure burden. 'Get' implies a read operation, but the description does not state whether the call is real-time or cached, what permissions are required, or how the response is structured; the cached/real-time distinction appears only in the schema's synced parameter.

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

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

The description is a single front-loaded sentence with no wasted wording. The parenthetical field list is useful and directly supports interpretation of the returned data.

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 getter with fully described parameters, the description is nearly complete and usefully lists the returned fields in the absence of an output schema. It could be stronger by noting behavioral details such as read-only status or the synced versus real-time distinction.

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. The description lists returned properties rather than adding parameter semantics, so the schema 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 and resource: 'Get control plane local properties for a device,' and enumerates the returned fields. It is clear what the tool does, but it does not explicitly differentiate itself from nearby siblings such as get_validator_local_properties.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives, nor does it state any exclusions or prerequisites. The use case is only faintly implied by the tool name and the phrase 'for a device.'

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 aggregation scope (fabric-wide) and the data categories returned, which is useful. It says nothing about read-only nature, permissions, pagination, or result shape, 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?

A single compact sentence with the scope front-loaded and no filler. It reads as a fragment without an explicit verb, which slightly reduces scannability, but every element 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?

For a summary tool with no output schema and one optional enum parameter, listing the included metrics is a reasonable completeness level. The missing piece is disambiguation from the many similarly named control/OMP summary siblings, which an agent needs in this crowded namespace.

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 field is an enum, so the schema fully documents the 'state' filter. The description adds no information about it, 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 names the resource (per-device control plane summary) and enumerates the exact contents: control connections, OMP peers, vSmart peers, reachability, plus the 'fabric-wide' scope. That is far more specific than a tautology. It does not, however, differentiate itself from close siblings such as get_control_summary or get_omp_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 only implied: 'fabric-wide' hints that this aggregates across all devices rather than one device. There is no explicit when-to-use statement, no prerequisite, and no named alternative among the many control/OMP summary siblings that could be chosen instead.

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 of behavioral disclosure, but only states the retrieval target. It does not explicitly confirm read-only safety, describe the returned statistics, mention authentication or device reachability requirements, or clarify whether the data is live or historical.

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

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

The description is a single front-loaded sentence with no wasted words. It efficiently states the resource and scope without unnecessary elaboration.

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

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

Given no annotations and no output schema, the description should provide more context about what statistics are returned and how they differ from similar control-plane tools. It is too minimal to help an agent select this tool confidently among many get_control_* siblings.

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 device_id parameter is documented with 'Device ID or system-ip.' The description adds only the phrase 'for a device,' which reinforces but does not extend the schema's meaning, so the baseline of 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 and resource combination: 'Get control plane DTLS connection statistics for a device.' This clearly identifies the entity and scope, and is distinguishable from siblings such as get_control_connections or get_control_status, though it does not explicitly name sibling alternatives.

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

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

The description gives no guidance on when to use this tool versus alternatives like get_control_connections, get_control_status, or get_validator_statistics. It provides only a bare statement of what is retrieved, leaving the agent to infer selection criteria.

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 behavioral burden. It indicates an aggregate/dashboard read operation, but does not disclose freshness, aggregation semantics, permissions, or what 'dashboard view' specifically changes, leaving meaningful behavioral 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?

The definition is a single compact sentence with the scope and output type front-loaded. The phrase 'dashboard view' is slightly vague, but there is no wasted text.

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

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

For a zero-parameter read tool with no output schema, the description gives the core output idea (fabric-wide up/down counts). However, it does not clarify how this differs from numerous similarly named control, summary, and statistics tools, leaving an agent with insufficient routing context.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. The description appropriately does not introduce unnecessary parameter details, making the baseline score of 4 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 identifies a specific resource (control connections) and output shape (up/down status counts), and scopes it as fabric-wide. It does not explicitly name or distinguish itself from close siblings such as get_control_count, get_control_summary, or get_control_statistics, 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 explicit guidance on when to use this tool instead of nearby alternatives like get_control_connections, get_control_count, or get_control_summary. The only usage clue is 'dashboard view', which is not enough to route an agent reliably among many get_control_* siblings.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It implies a read-only operation via 'Get' and says the result is a device count, but it does not clarify authorization requirements, whether the count reflects connected devices or configured devices, error behavior, or other operational traits.

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 filler or repeated information. It is appropriately terse, though its brevity contributes to the sibling ambiguity noted elsewhere.

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

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

The tool is simple: one required parameter, complete parameter schema coverage, and no output schema. The description states the return subject (device count) but leaves 'control plane summary' underspecified and offers no behavioral context, which is a noticeable gap given the absence of annotations and output schema.

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

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

Schema description coverage is 100%; the single required parameter device_id is documented in the schema as 'Device ID or system-ip'. The description only adds the phrase 'for a device' and does not extend parameter semantics meaningfully beyond the schema.

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

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

States a specific verb and resource: get a control plane summary for a device, with the parenthetical clarifying that it returns a device count. The purpose is understandable without opening the schema, though it does not explicitly differentiate itself from close siblings such as get_control_count or get_control_network_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?

Provides no guidance on when to use this tool versus semantically close siblings like get_control_count, get_control_status, or get_control_network_summary. The agent must infer the selection criteria from the name and is not told when this tool is inappropriate.

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 makes clear this is a read of controller-held data and that the argument must be a vSmart system-ip (not a vEdge), but says nothing about scope, permissions, or result 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 that are front-loaded with the resource and end with the key input constraint. No wasted clauses, though the second sentence largely restates the schema's device_id description.

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

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

For a two-parameter read tool with full schema coverage and no output schema, the description is sufficient to invoke it correctly. The main residual gap is not explaining the semantics of the `list` selector.

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

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

Schema description coverage is 100%, so the schema already documents both parameters, establishing a baseline of 3. The description reinforces that device_id is a Controller system-ip but adds nothing about the `list` enum values (devices/vsmarts/vmanage_id) beyond the plural phrasing.

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 ('Get the authorized device lists held by a Controller (vSmart)'), and the explicit 'Controller (vSmart)' qualifier distinguishes it from the near-identical sibling get_validator_valid_devices.

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

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

'Use a controller system-ip' gives a precondition for the input, but there is no explicit when-to-use or when-not guidance and no routing to alternatives such as get_validator_valid_devices or list_controllers. Usage is only implied.

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

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

No annotations are provided, so the description must carry the behavioral burden. It usefully identifies the returned state fields, but it does not disclose whether data is real-time or cached by default, permission requirements, or rate/query behavior; the 'synced' parameter documents that choice only in the schema.

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

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

The description is a single dense sentence with no wasted text. The resource and return fields are front-loaded, making it easy to scan.

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 read tool with full schema coverage and no output schema, the description is mostly complete because it names the key return fields. It could mention the real-time versus cached behavior as behavioral context, but that is already covered by the schema's synced parameter.

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, including the synced-vs-real-time distinction. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description uses a specific verb and resource: 'Get control plane WAN interface (TLOC) state for a device,' and enumerates the state fields (color, public/private IP/port, connection counts). It is clear what the tool does, but it does not explicitly distinguish itself from closely related siblings such as get_device_tloc or get_control_connections.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it state any prerequisites, exclusions, or preferred contexts. It only implies usage by saying the query is 'for a device.'

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 burden of behavioral disclosure. It conveys that this is a retrieval operation and what data is returned, but does not mention permissions, device reachability requirements, error behavior, or pagination.

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

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

The description is a single, front-loaded sentence with no wasted words. It immediately states the operation and the returned data.

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

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

For a simple one-parameter read tool with no output schema, the description is largely complete: it names the resource, clarifies the returned mapping, and the parameter is fully documented in the schema. Minor omissions include device reachability or empty-table behavior.

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

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

Schema description coverage is 100%, so the device_id parameter is already fully documented as 'Device ID or system-ip'. The description adds no parameter-specific semantics beyond what the schema provides, making the baseline score of 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?

The description states a specific verb and resource: get the ARP table for a device. It also clarifies the content as IPv4-to-MAC mappings, which helps distinguish it from generic device tools, though it does not explicitly name or differentiate from sibling tools like get_bridge_table.

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

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

Usage is only implied by the tool name and description; there is no explicit guidance on when to use this tool versus alternatives such as get_bridge_table or get_device_interfaces. No exclusions or prerequisites are mentioned.

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 behavioral burden. It implies a read-only lookup but does not disclose permissions, error behavior for unknown devices, response shape, or whether the data is live versus cached.

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?

It is a single front-loaded sentence with no wasted words. The key purpose and identifier options appear immediately.

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

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

For a simple one-parameter lookup, the description covers the basic operation. However, with no output schema and no annotations, it leaves the meaning of "detailed information" and returned fields underspecified.

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 is already documented as a UUID or system-ip. The description repeats the accepted identifier forms but adds no syntax, formatting, or validation detail beyond the schema.

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

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

The description states a specific verb and resource: get detailed information for a specific device. It distinguishes lookup of one device by ID/IP from list-oriented siblings, but does not explicitly differentiate from the many other device-specific detail tools.

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

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

It implies usage when the caller has a device ID or system IP and needs device details, but gives no explicit when-to-use guidance, exclusions, or named alternatives among the many sibling device/control tools.

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 implies a read ("Get") and reveals that it returns both operational status and configuration, but says nothing about permissions, whether all interfaces are returned or a subset, pagination, or volume—significant gaps for a zero-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?

A single front-loaded sentence with no waste. It is efficient, though its brevity borders on under-specification rather than tightness.

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

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

The tool is simple (one required parameter) but has no annotations and no output schema, so the description is the only place to learn what comes back. It names status+configuration, which is the minimum viable coverage, but omits scope and return shape.

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 device_id parameter is documented as 'Device ID or system-ip'. The description only confirms the device scoping, so it adds nothing beyond the schema—baseline 3 applies.

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

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

States a specific verb (get) and resource (interface status and configuration) scoped to a device, which is far more informative than a tautology. However, it never distinguishes itself from siblings like get_control_wan_interfaces or get_bridge_table, leaving the agent to guess which interface view 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternative tools. With several sibling tools returning interface-adjacent data, the agent gets no routing signal at all.

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 implies a read operation via 'Get' but says nothing about permissions, whether the device must be online, what happens if TLOC data is unavailable, or what shape the response takes.

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 well-formed sentence with the essential resource stated up front and the acronym explained. It is not padded, though it is arguably under-specified rather than optimally concise.

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

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

For a simple one-parameter read tool with no output schema, the description is minimally adequate but leaves the agent guessing about what TLOC data is returned and how it differs from the sibling TLOC endpoints. Slightly more routing context would complete it.

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

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

Only one parameter with 100% schema coverage ('Device ID or system-ip'), so the schema already does the work. The description adds nothing about which identifier form is preferred or how lookup behaves, 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 (Get) and resource (TLOC information) scoped to a device, with the acronym expanded. However, it does not distinguish itself from close siblings like get_bfd_tloc or get_omp_tlocs, so an agent cannot tell from the description which TLOC tool 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?

No indication of when to use this versus the other TLOC-related siblings, no prerequisites (e.g., device must be reachable/managed), and no exclusions. The agent must infer usage from the name alone.

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

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, yet it says nothing about permissions, whether the data is live or configured, error behavior for unknown devices, or what the 'configuration' contains. Only the weak implication of 'Get' suggests a read-only operation.

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

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

A single front-loaded sentence with zero redundancy. It is appropriately tight, though the brevity leaves room for one clarifying clause at no structural cost.

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

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

For a low-complexity single-parameter read tool the definition is minimally viable, but with no annotations and no output schema the description never indicates what a 'VPN configuration' response contains or what happens on a bad device_id.

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 device_id parameter is fully documented in the schema (ID or system-ip), so the description does not need to restate it. Baseline 3 applies since the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('Get VPN configuration') plus the target scope ('for a device'), so an agent knows exactly what it retrieves. It does not differentiate itself from any sibling, though none of the listed siblings is a close VPN-config analogue.

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 offers no guidance on when to use this versus other device-scoped tools (e.g. get_device_details or get_device_interfaces), no prerequisites, and no exclusions. Usage must be inferred entirely from the name.

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

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

Without annotations, the description carries the full burden. It discloses that the tool retrieves a profile along with its features (parcels) and gives examples of feature contents, which is useful return-value context. However, it does not mention permissions, error behavior, or any operational constraints, leaving a gap for a mutation-free but still behaviorally opaque tool.

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

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

The description is a single well-formed sentence that front-loads the core action and resource, then supplies compact examples. Every part earns its place with no redundancy.

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

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

With no output schema and no annotations, the description does a reasonable job of explaining what is returned (profile plus features/parcels) and illustrates the domain. It omits edge cases like missing profiles or permission requirements, but for a simple read tool with fully documented parameters, it is largely 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 parameters are self-documented. The description adds examples of profile types (system, transport, service) and their contents, which gives some meaning to the profile_type values, but it does not mention the 'solution' parameter or clarify default behavior. 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 uses a specific verb and resource ('Get one UX 2.0 feature profile with its features (parcels)') and gives concrete examples of profile types, making it clear what the tool returns. It distinguishes itself from list_feature_profiles by specifying 'one', though it does not name the 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 description gives no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The examples of profile types indirectly hint at valid usage, but there is no stated context or alternative routing.

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

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

With no annotations, the description carries the full disclosure burden. It does communicate the fabric-wide aggregation scope and the grouping by device class, but it does not explicitly state that this is a read-only operation, whether counts are live or cached, or what permissions are required.

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 compact phrase that front-loads the fabric-wide scope and then enumerates the device classes. There is no filler or repetition.

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

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

Given the tool has no input parameters and no output schema, the description sufficiently explains that the result is counts per device class. It could be improved by clarifying usage relative to sibling summaries, but the core return concept is present.

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

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

The tool has zero parameters, so there is no parameter semantics burden. The baseline for zero-parameter tools is 4, and the description appropriately avoids unnecessary parameter discussion.

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

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

The description clearly states that this returns reachable/unreachable counts per device class across the fabric, which is more specific than the tool name alone. It distinguishes the result type (aggregate counts) from sibling list or detail tools, though it does not explicitly name which sibling to use instead.

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

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

There is no guidance on when to use this summary versus related siblings such as get_control_summary, get_control_count, or list_reachable_devices. The description only says what the output contains, leaving the agent to infer the appropriate context.

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

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

No annotations are provided, so the description carries the full burden. It correctly frames this as a retrieval of an existing structure, which implies a read-only, zero-parameter, low-risk call, but it says nothing about return shape, ordering, or whether the hierarchy is a nested tree versus a flat list.

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

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

A single front-loaded sentence with the resource named first and the level enumeration in parentheses. No filler, though the trailing purpose clause is slightly compressed.

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 is the only source of information about what comes back; it partially compensates by naming the four hierarchy levels. For a zero-param tool that is close to adequate, but the shape of the returned structure remains unspecified.

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 and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies; the description cannot and need not add parameter meaning here.

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 a specific resource ('UX 2.0 network hierarchy') and enumerates the levels it covers: global, regions, areas and sites. That contrasts reasonably with the closest siblings (get_ux2_overview, list_config_groups), though it never names an alternative to distinguish against.

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

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

The clause 'used by configuration groups and policies' implies the context in which an agent would need this tool, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many siblings. Usage must be inferred.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation but does not explain whether Cloud OnRamp must be configured, what happens when no routes exist, 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?

The definition is a single front-loaded sentence with no wasted words. It is efficient, though its brevity contributes to the gaps in usage and behavioral guidance.

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

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

With no annotations and no output schema, the description should do more to explain what Cloud OnRamp routes are and what the caller receives. For a domain-specific read tool in a large sibling set, this is under-specified.

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

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

Schema coverage is 100%, and the single device_id parameter is already documented as accepting a device ID or system-ip. The description adds only 'for a device', which is consistent but adds little beyond the schema.

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

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

The description states a specific verb and resource: get OMP Cloud OnRamp (CloudExpress) routes for a device. It is clearly narrower than a generic OMP route tool, but it does not explicitly differentiate itself from siblings like get_omp_routes or get_cloudx_status.

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

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

There is no guidance on when to use this tool versus get_omp_routes or the get_cloudx_* family. The only implied usage is retrieving Cloud OnRamp routes, but no prerequisites or 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; "list" plus "fabric-wide" conveys that this is a broad read aggregation across all devices rather than a targeted lookup. However, it says nothing about whether results are paginated, how down links are represented, or any auth/prerequisite details.

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