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

Annotations already declare destructiveHint=true, idempotentHint=true, and closed-world read/write status. The description adds useful behavioral context by disclosing pool eligibility and the one-user-per-machine constraint in most configurations.

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 three short sentences, front-loads the core action, and follows with two relevant constraints. Every sentence adds useful context with no filler.

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

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

For a tool with rich annotations, complete parameter schema, and an output schema, the description is largely complete: it covers the action, eligibility, and cardinality caveat. It lacks only a pointer to alternatives or related tools, which is a minor gap.

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

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

Schema description coverage is 100%, and the schema already explains action, user_ids, and machine_id in detail. The description adds no parameter-level meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description states a specific verb pair (assign/unassign) and resource (users to a dedicated desktop machine), and scopes it to dedicated non-floating pools. This clearly distinguishes it from sibling tools that manage machines, pools, or AD objects.

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

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

It gives a clear applicability constraint: only dedicated (non-floating) desktop pools. It does not name an alternative tool or explicitly state when not to use it beyond that pool-type exclusion.

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

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

Annotations already declare the safety profile (readOnly=false, destructive=false, idempotent=false), so the description only needs to add context beyond that. It adds almost none: no note on what happens with duplicate names, required permissions, whether publishing is reversible, or side effects on the target farm.

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, correctly sized for a one-line summary. It is efficient, though its brevity leaves the definition thin overall rather than earning a 5 for well-structured completeness.

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

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

An output schema exists, so return values need not be explained, and annotations carry the safety profile. However, for a 9-parameter mutation tool with a required farm dependency, the description omits creation semantics and side effects, leaving it only minimally 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%, so all 9 parameters, including the multi_session_mode enum and executable_path format, are already documented in the schema. The description contributes no parameter meaning beyond that, which is the expected baseline of 3 when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Publish a new application pool') plus its source ('from an RDS farm'), which is enough to separate it from create_desktop_pool, create_rdsh_farm, and update_application_pool. It stops short of explicitly naming the siblings it is not, so it lands at 4 rather than 5.

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

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

The description gives no when-to-use guidance, no prerequisites (e.g. that an RDS farm must already exist), and no routing to alternatives. The only prerequisite hint, 'obtain from list_rdsh_farms', lives in the farm_id schema description, not in the tool description.

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

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

Annotations declare a non-read-only, non-idempotent, non-destructive mutation, but the description adds genuinely valuable behavioral context beyond them: an AUTOMATED pool immediately begins creating VMs in vCenter and requires user confirmation. It stops short of covering auth/permission needs or the fact that each call produces a distinct new pool.

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

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

Two short sentences, front-loaded with the action and followed by the critical caution. Every sentence earns its place with zero 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?

An output schema exists so return values need no explanation, and the schema fully specifies the complex 'spec' object. The description covers the key provisioning risk, though it omits auth/permission prerequisites and any mention of idempotency behavior that would round it out.

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

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

Schema description coverage is 100% and the 'spec' object is exhaustively documented inline (required keys, nested settings, cross-referenced sibling tools for IDs). The description adds no parameter meaning of its own, so the baseline of 3 for high-coverage schemas 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 (Create) and resource (desktop pool), clearly distinct from sibling creation tools like create_rdsh_farm and create_application_pool. An agent immediately knows this tool's job.

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 'Always confirm with the user before calling this' directive is a useful usage guardrail, but it does not tell the agent when to choose this tool over alternatives (e.g. create_rdsh_farm for RDSH workloads) or what prerequisites must be gathered first. Usage is implied rather than fully specified.

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

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

Annotations only declare the generic non-read-only/non-destructive flags. The description adds genuinely useful behavioral context: an AUTOMATED farm immediately begins creating VMs in vCenter and should be user-confirmed first — a side effect the flags alone do not convey. It says nothing about permissions or failure/rollback behavior, keeping it below 5.

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

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

Two short blocks: the purpose is front-loaded, and the caution follows with no filler or redundancy. Every sentence earns its place.

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

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

A create operation whose full spec is exhaustively documented in the schema, with an output schema present so return values need no description. The description supplies the critical side-effect caveat. Minor gap: no mention of the login/prerequisite context, though siblings cover that.

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 `spec` parameter is documented in exceptional depth inside the schema, including required keys, enum values, and pointer tools (list_base_vms, list_datacenters, etc.). The description adds no parameter meaning beyond that, so the baseline 3 for full schema coverage 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+resource ("Create a new RDS farm") that an agent can distinguish from create_desktop_pool and the other create_* siblings by resource type. It stops short of explicitly differentiating itself from siblings like update_rdsh_farm or delete_rdsh_farm, so it does not reach the top band.

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

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

Usage is implied by the verb and reinforced by the warning to confirm with the user before provisioning an AUTOMATED farm, which is a real precondition. However, it never names alternatives (e.g., create_desktop_pool vs. this) or states when a farm is the right choice over a pool, leaving the routing decision to inference.

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

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

Annotations already declare destructiveHint=true and non-idempotent behavior, so the bar is lower. The description adds material context: users immediately lose access, and user confirmation is required. It stops short of describing reversibility or required privileges.

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

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

Front-loads the verb and resource in one sentence, then immediately follows with the caution and confirmation requirement. No 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 destructive delete with an output schema, the description supplies the critical behavioral caveat and confirmation requirement. It leaves minor gaps such as whether deletion is reversible, but annotations and schema cover most of what an agent needs.

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

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

Schema description coverage is 100%, so the schema fully documents pool_id and confirm. The description adds no parameter-level meaning beyond that baseline.

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

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

Names a specific verb ('Delete') and resource ('published application pool'), clearly distinct from sibling deletes for desktop pools and RDSH farms. The scope is explicit enough to route correctly.

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

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

Provides a clear precondition: always confirm with the user before calling. It warns of immediate loss of access, but does not name alternative deletion tools or when not to use this tool.

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

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

Annotations already flag destructiveHint=true and non-idempotent, but the description adds the crucial facts the annotations cannot convey: the operation is irreversible, all machines go, and active user sessions are terminated. That is exactly the extra context an agent needs before a destructive 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?

Two short parts: the action with scope first, then a front-loaded CAUTION that earns every word. No filler, 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?

For a destructive mutation tool with an output schema already present, the description covers purpose, irreversibility, affected entities, and the confirmation obligation. Nothing an agent needs to decide and call safely is missing.

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

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

Schema description coverage is 100%, and the schema itself documents pool_id source and the confirm/HORIZON_CONFIRMATION semantics in detail, so the description need not repeat it. Baseline 3 applies since the description adds nothing beyond the schema for parameters.

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

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

States a specific verb (delete) and resource (desktop pool) plus the blast radius ('and all of its machines'). It is clearly distinguishable from siblings like delete_rdsh_farm and delete_application_pool without opening any schema.

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

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

Gives explicit when-to-use guidance by mandating user confirmation before calling, and the schema reinforces this with the get_desktop_pool/list_sessions pre-check. It does not name a direct alternative, but none is really needed for a terminal delete.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description adds genuinely new behavioral detail beyond them — that the operation is irreversible, that every server in the farm is removed, and that active user sessions are terminated. It omits permission requirements, but the destruction semantics are well disclosed.

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: the effect first, then the caution. The destructive consequence and the confirmation requirement are front-loaded with zero filler.

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

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

For a destructive tool with an output schema, full annotation coverage, and complete parameter documentation, the description supplies everything an agent needs: what is destroyed, that it cannot be undone, and that user confirmation is mandatory.

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

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

Schema description coverage is 100% and both parameters (farm_id, confirm) are documented in the schema, including the HORIZON_CONFIRMATION/elicitation nuance. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb (Delete) and resource (RDS farm) and scopes it further with 'and all of its servers'. This clearly distinguishes it from the sibling mutation tools (update_rdsh_farm, rdsh_farm_action) and from delete_desktop_pool/delete_application_pool.

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

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

Gives explicit usage guidance ('Always confirm with the user before calling this') and points, via the schema, at the read-first workflow (get_rdsh_farm, list_sessions). It does not explicitly contrast with alternative farm-management siblings, so it stops short of the top score.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety bar is partly covered. The description adds real behavioral nuance beyond that: disabling sessions leaves existing sessions running, and provisioning vs. session control are separate concerns. It does not mention the confirmation flow, slighting an otherwise solid disclosure.

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

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

Four tightly scoped sentences, front-loaded with the high-level action list before the per-action semantics. Every sentence earns its place, with no filler.

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

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

An output schema exists and annotations cover the mutation profile, so the description need not explain returns. It covers the action semantics well but omits the confirm-parameter behavior and batch semantics for multiple pool_ids, minor gaps for a multi-target action 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%, including a fully documented enum for action, so the schema already carries the parameter semantics. The description largely restates the action semantics rather than adding format or syntax beyond the schema, matching the baseline of 3.

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 (enable/disable/toggle) and resource (provisioning for desktop pools), and clarifies the two distinct control surfaces: session admission versus VM provisioning. It is clear, though it does not explicitly differentiate itself from the sibling update_desktop_pool tool.

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

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

It gives clear per-action context for when to use each mode, and explicitly states that disabling provisioning is the correct way to pause scale-out during maintenance. It stops short of naming an alternative tool or stating exclusions.

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

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

With readOnlyHint/openWorldHint already covering the safety profile, the description adds genuine behavior: results are keyed by aspect name, a failed aspect returns {"error": ...} instead of aborting the call, and the tool internally resolves internal_session_id. It stops short of permissions or performance/rate-limit context.

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 paragraphs, front-loaded with purpose and aspect list, then error semantics, then the ID caveat. Each sentence carries information, though the 'verified live' anecdote is slightly more verbose than needed.

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

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

With an output schema present, return formatting need not be restated, and the description covers the remaining essentials: what aspects exist, what partial failure looks like, and the ID resolution quirk. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by warning that the underlying help desk endpoints need internal_session_id, not session_id, and that the tool transparently performs that lookup — non-obvious semantics the schema does not capture.

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 ('Retrieve diagnostic information for a user session') and enumerates the exact diagnostic aspects it can return, which cleanly separates it from the sibling read tools get_session and list_sessions.

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?

Establishes clear context ('in a single call', fetching any combination of aspects) so the agent knows this is the aggregated diagnostic path, but names no explicit exclusions or alternatives such as get_session.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely useful nuance beyond them: the session remains active and the user's applications keep running, which softens and disambiguates the 'destructive' hint. It does not discuss confirmation flow or permissions, but the confirm parameter schema covers the former.

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

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

Two tight sentences with zero waste; the core behavior (sessions stay active, clients disconnect) is front-loaded and the routing hint to logoff_sessions follows. Every sentence earns its place.

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

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

With an output schema present, return values need not be described, and annotations plus schema cover safety and parameters. The description supplies the one non-obvious behavioral fact (apps keep running, session survives) and the correct alternative, leaving nothing an agent needs missing.

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

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

Schema description coverage is 100%, so both parameters (session_ids and confirm) are fully documented in the schema itself. The description adds no syntax, format, or batching detail beyond what the schema provides, 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 (disconnect) and resource (user sessions) with clear scope (one or more), and explicitly distinguishes itself from the sibling logoff_sessions. An agent can tell it apart from logoff_sessions, reset_or_restart_sessions, and send_message_to_sessions without opening any schema.

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

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

It names the alternative explicitly ('Use logoff_sessions to fully terminate sessions') and gives the condition that selects it, so the choice between disconnect and logoff is unambiguous. The parenthetical also clarifies when this tool is the right fit (sessions must remain active).

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

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

Annotations already declare destructiveHint=true, so the description earns credit for going beyond the flag: it states the application is force-closed and that unsaved data will be lost, which tells the agent the concrete consequence rather than a generic 'destructive' label. It also flags the user-confirmation obligation, which is real workflow context not captured by annotations.

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

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

Three short sentences: purpose first, then the CAUTION, then the required action. Every sentence carries distinct information and nothing is padded.

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

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

With an output schema present and full parameter documentation in the schema, the description only needs to carry purpose and risk, which it does. The one remaining gap is that it never situates the tool relative to the session-termination siblings, which matters for a mutation with irreversible effects.

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 the confirm parameter's HORIZON_CONFIRMATION behavior and a pointer to diagnose_session for finding remote_application_id. The description adds no parameter meaning beyond what the schema already documents, 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 (terminate) and resource (a remote application running in a session), with the scope narrowed to a single identified application. It is reasonably distinguishable from the session-level siblings like logoff_sessions and disconnect_sessions, though it never explicitly contrasts itself with them.

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

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

The description gives a clear precondition for calling — confirm with the user first — but offers no guidance on when to use this versus logoff_sessions, disconnect_sessions, or reset_or_restart_sessions, which are the nearest alternatives for ending session activity. Usage is implied rather than routed.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds little behavioral context beyond the read nature, and because it operates on a known ID it does not disclose failure behavior (e.g., what happens for an unknown ID). With annotations carrying the load, a 3 is appropriate.

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

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

A single front-loaded sentence with no filler or redundancy. It is appropriately short for a simple lookup tool, though it errs toward minimalism rather than earning full marks.

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 param) and an output schema exists, so return values need not be explained. The main gap is the absence of routing information relative to the search sibling and any note on identifier sourcing, leaving the definition adequate but not fully rounded.

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 ad_id parameter, and the input schema already documents it as 'AD user or group ID'. 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?

The description states a clear verb (Get) and resource (AD user or group) scoped to 'a specific' item, which distinguishes it from the plural search_ad_users_or_groups and list_ad_* siblings. The phrase 'detailed information' is somewhat vague about what is actually returned, but the core purpose is unambiguous.

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

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

There is no explicit when-to-use guidance and no mention of the sibling search_ad_users_or_groups that an agent would logically use first to obtain the ad_id. The word 'specific' weakly implies a known identifier is required, but the routing condition is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the return shape (tools/resources/not_yet_supported), which is useful context, but since an output schema exists this partly duplicates structured data and adds nothing about limits or resource URI semantics.

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

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

Front-loaded purpose statement followed by a compact usage note and an indented section breakdown. Every sentence earns its place with no filler.

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

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

Given an output schema already exists, the description goes slightly beyond what is required by naming all three sections. It remains silent on the horizon:// resource addressing scheme and any size or pagination expectations, so it is complete but not exhaustive.

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

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

The tool takes zero parameters, so the baseline is 4; there are no inputs whose meaning could be explained further.

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

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

States a specific verb and resource: list all available Horizon MCP tools, resources, and unsupported operations. This is a meta/discovery tool clearly distinguishable from the operational siblings (get_settings, list_machines, etc.), and the three-section breakdown makes its scope unambiguous.

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

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

Explicitly says when to call it: before attempting a task, or when informing users which features are supported. That is strong positive guidance, but no when-not condition or alternative discovery path is named (there is effectively no sibling alternative, so the gap is minor).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — no error behavior, no note about what happens with an invalid pool_id, and no additional operational context.

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

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

A single efficient sentence with the resource front-loaded and no wasted words. It is appropriately sized, though it is so terse that it leaves useful routing information out.

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

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

An output schema exists, so return values need not be described, and the read-only annotations cover safety. With a single fully documented parameter, the definition is largely complete, missing only sibling routing guidance.

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 schema itself explains that pool_id is 'obtain from list_application_pools'. The description adds no further parameter meaning, 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 ('Get') and resource ('application pool') with the scope qualifier 'specific'. It is clear what the tool does, though it never names the sibling list_application_pools as the counterpart the way a stronger definition would.

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 prerequisites, and no mention of alternatives such as list_application_pools. Usage is only implied by the word 'specific', which is not enough to route an agent confidently.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds nothing beyond that – no mention of error behavior for invalid IDs, auth requirements, or whether config data is cached/live.

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

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

A single efficient sentence with no filler, front-loading the verb and resource. It is appropriately sized for a simple getter, though it could have used the space to route against the list sibling.

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

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

An output schema exists, so return values need not be explained, and annotations cover the read-only nature. Still, for a tool with a closely related sibling it omits the disambiguation that would make it fully self-sufficient.

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

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

Only one parameter exists and it is fully documented in the schema (100% coverage). The description adds no syntax or format detail for server_id, so baseline 3 applies; the schema does all the work.

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 (configuration details for a Connection Server), which is clear. However it does not distinguish itself from the sibling list_connection_servers, which an agent must infer from the plural 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 guidance on when to use this versus list_connection_servers, nor any prerequisites such as needing a valid server_id or prior login. The agent must infer the single-vs-list distinction from names.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond the basic purpose - no note on what 'detailed' includes, latency, permissions, or error behavior - so it earns only a minimum-viable score.

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

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

A single front-loaded sentence with zero waste. It is appropriately terse for a simple read tool, though it is so minimal that conciseness comes at the cost of coverage.

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

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

With annotations covering safety, a 100%-covered schema, and an output schema handling return values, the core needs are met. However, missing routing guidance relative to get_connection_server and get_infrastructure_health leaves a real gap for a tool in a crowded sibling set.

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% with the single server_id parameter fully documented in the schema. The description adds no syntax, format, or lookup guidance 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 detailed health information for a specific Connection Server.' An agent can tell it retrieves health data rather than config, but the description offers no differentiation from close siblings like get_connection_server or get_infrastructure_health.

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_connection_server or get_infrastructure_health, nor any prerequisites or conditions. The agent must infer usage 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds substantial behavioral context beyond annotations: it explains the v13 endpoint choice, why older v1 responses lack fields, and that the completeness was verified live with zero gap for update compatibility.

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 first sentence front-loads the purpose efficiently. The second paragraph is somewhat detailed about endpoint version history, but it earns its place by justifying the tool's completeness guarantee for update workflows. No significant waste, though it could be tightened.

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 get tool with an output schema and read-only annotations, the description is complete enough to call correctly. It covers purpose, parameter origin via schema, and why the response is suitable for update round trips. Return value details are appropriately left to the output schema.

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

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

Schema coverage is 100%, and the single parameter's description already tells the agent to obtain pool_id from list_desktop_pools. The tool description does not add syntax or format details beyond the schema, so this is the baseline score when the schema does the heavy lifting.

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

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

States a specific verb and resource: 'Get detailed configuration and status of a specific desktop pool.' This clearly distinguishes it from the sibling list_desktop_pools, which lists pools rather than retrieving one pool's full configuration.

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 important context for when to use this tool: it uses the v13 endpoint so the response contains all fields that update_desktop_pool may require, making a get-then-update round trip possible. However, it does not explicitly state when to prefer this over list_desktop_pools or other get tools, nor does it give formal exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds the scope ('all configured domains') and the mapping direction (NETBIOS->DNS), which is useful, but nothing about auth needs, caching, or edge cases. With annotations carrying the safety burden, a 3 is appropriate.

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

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

A single front-loaded sentence with no filler; the resource and scope are stated immediately and every word earns its place.

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

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

An output schema exists, so the return shape needn't be explained, and annotations cover the safety profile for this parameterless getter. The description is nearly complete, with only usage routing to sibling tools left 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?

There are zero parameters, so the baseline of 4 applies. No parameter semantics are needed and none are missing.

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 precise resource: a NETBIOS-to-DNS name mapping across all configured domains. This is clearly distinguishable from siblings like list_ad_domains, which enumerate domains rather than produce a name-correspondence map.

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 scope ('for all configured domains') is implied usage context, but there is no explicit when-to-use guidance and no mention of alternatives such as list_ad_domains for domain enumeration. An agent can infer the use case but is not routed.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe read-only nature is covered. The description adds useful scope context by naming the categories of properties returned, but it does not disclose anything further about behavior (e.g. whether values are live vs cached). With annotations carrying the safety profile, a 3 is appropriate.

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

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

A single front-loaded sentence that names the action, the resource, and the concrete contents with no filler. Every clause earns its place.

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

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

For a no-parameter read tool with an output schema, the description is close to complete: it tells the agent what scope of data it returns while the output schema carries the structure. The only gap is the absence of any sibling disambiguation, which is minor given the distinct name.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; the schema is empty and coverage is vacuously complete. Baseline 4 applies since the description has nothing it must compensate for.

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 environment-level properties') and enumerates the returned fields (version, FIPS mode, feature flags), so the agent knows exactly what this retrieves. However, it does not differentiate from similarly named siblings such as get_settings or get_api_coverage, leaving some ambiguity about which environment-scoped read 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives despite several overlapping sibling reads (get_settings, get_api_coverage, get_infrastructure_health). The agent must infer usage purely from the tool name and field list.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful detail that the response covers both configuration and connection status, but says nothing about auth requirements or what a failed/disconnected status looks like.

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; every word earns its place and the resource and scope come first.

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

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

For a zero-parameter, read-only tool with an output schema that carries the return shape, the description is sufficient. Nothing needed to invoke the tool correctly is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-arg 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?

States a specific verb ('Get') and resource ('the Horizon event database') with the exact scope of what is retrieved: configuration and connection status. No sibling tool covers the event database, so there is no ambiguity to resolve against the long list of get_* tools.

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

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

The description gives no when-to-use guidance, no prerequisites (e.g. that a horizon_login session is needed), and no alternatives. The agent must infer that this is a diagnostic call for checking event database connectivity.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description adds the useful 'environment-wide' scoping detail, but adds no further behavioral context such as whether results include inherited/default policies or how large the payload may be.

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

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

A single well-formed sentence with the resource stated first and the enumeration trailing; every clause earns its place. Slightly list-heavy at the end but far from verbose.

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

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

An output schema exists, so return values need no explanation, and a parameterless read-only call carries few unknowns. The only missing piece is routing context versus get_settings and update_global_policies.

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 no parameter semantics to communicate and the description correctly does not invent any. Score reflects the neutral baseline rather than added value.

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

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

Clear verb (Get) plus specific resource (global VDI policies), with an enumeration of the concrete policy categories it returns (USB redirection, multimedia redirection, clipboard). It does not, however, explicitly differentiate itself from the sibling get_settings or acknowledge the paired update_global_policies, so an agent must infer the 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 by the name and scope; there is no statement of when to call this instead of get_settings, nor any prerequisite or exclusion. With no parameters a caller cannot misuse it badly, but alternative-routing guidance is absent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: results are keyed by component name, and a failed component surfaces its error as a string instead of failing the whole call — important partial-failure semantics for an aggregator.

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 opening sentence front-loads the capability, and the bulleted component list is easy to scan. It is somewhat long given the component names already appear as schema enum values, but each bullet adds a short gloss that earns its place.

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

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

With an output schema present and annotations covering safety, the description is nearly complete — it explains scope, component coverage, keying, and partial-failure behavior. It omits authentication/rate-limit context, which is a minor gap for a read-only health aggregator.

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 'components' parameter is already well documented with allowed values and the all-components default. The description restates the same component list without adding selection syntax or semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get health and status across Horizon infrastructure') and scopes it as an aggregate check 'in a single call', which implicitly separates it from per-component siblings like get_connection_server_health and list_virtual_centers. The component enumeration further pins down exactly what is covered.

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

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

The 'single call' framing and component list imply this is the aggregate overview tool, but the description never states when to prefer it over the narrower per-component health/list tools, nor any prerequisites such as prior authentication. Usage is inferable but not explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — no auth requirements, no behavior when the machine_id is invalid or the machine is absent. With annotations carrying the load, the description is essentially silent on behavior.

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

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

A single front-loaded sentence with no filler or redundancy. It is appropriately sized, though its brevity reflects thin content rather than disciplined editing.

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

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

An output schema exists, so return values need not be described, and a one-param getter has modest requirements. Still, the definition leaves the agent without any usage context, prerequisites, or failure behavior for a tool that fetches a specific entity.

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 machine_id parameter is already documented with a useful hint ('obtain from list_machines'). The description adds no further parameter meaning, 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 (get) and resource (machine) with clear scope ('detailed information'). It is distinguishable from list_machines by the singular resource and 'detailed' qualifier, but it never explicitly names or contrasts with its siblings.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no reference to alternatives such as list_machines (to discover an ID) or machine_action (to change state). The agent must infer all routing 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description goes further and discloses non-obvious behavior: results are keyed by scope name, and a failed scope returns its error as a string rather than failing the whole call. That partial-failure contract is exactly the kind of runtime behavior an agent cannot infer from structured fields.

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

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

The core purpose is front-loaded in the first sentence, followed by a scannable scope list and two closing sentences on result shape and failure handling. No filler or redundancy; each sentence carries distinct 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?

An output schema exists, so return-value structure need not be restated. The description covers scope semantics, keying of results, and error behavior, giving the agent everything needed to invoke it correctly and interpret partial results.

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 enum values themselves are already documented, establishing a baseline of 3. The description adds genuine meaning by explaining what each scope actually measures (e.g., 'system: CPU and memory metrics for connection servers'), which enriches selection of scope values beyond the bare enum.

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

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

The description gives a specific verb and resource ('Get performance and capacity metrics') and enumerates exactly what each scope returns (pool counts, session totals, machine states, CPU/memory, RDS states, license usage). This makes the tool's purpose unambiguous. It does not, however, explicitly differentiate itself from siblings that also surface health/state data such as get_infrastructure_health or get_connection_server_health, 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?

Usage is implied by the enumeration of scopes and the 'in a single call' framing, which signals an aggregate/multi-metric use case. But there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., why pick this over get_connection_server_health). Guidance is inferable but not stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe read-only nature is covered. The description adds no behavioral details beyond what the annotations and output schema provide, but it does not contradict them either.

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 no wasted words, clearly front-loading the verb and the resource.

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 simple read-only nature, full schema coverage, annotations, and an existing output schema, the description is largely complete. It misses only an explicit tie-break against sibling entitlement tools, which is a minor gap for a straightforward getter.

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

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

Schema description coverage is 100%, so the schema fully documents both pool_id and pool_type, including the enum for pool_type. The description adds no syntax or format detail beyond what the schema already supplies, 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 ('Get') and resource ('users and groups entitled to access a specific pool'), making the purpose clear. It does not, however, differentiate itself from the sibling list_pool_entitlements tool, which likely also deals with pool entitlements.

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 such as list_pool_entitlements or set_pool_entitlements. Usage is implied only by the phrase 'specific pool', but no when-not or alternative routing is provided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds a genuine behavioral fact (v10 endpoint yields a superset of update_rdsh_farm's fields), but much of the second paragraph is developer meta-commentary ('verified live, zero gap', 'mirrors the same fix applied to get_desktop_pool') rather than agent-facing 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 first sentence is well front-loaded and sufficient. The second paragraph mixes one useful fact (v10 completeness) with self-referential justification ('mirrors the same fix applied to get_desktop_pool') that does not help an agent invoke the tool, so it only partially earns its space.

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

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

With an output schema present, return values need no explanation, annotations cover the safety profile, and the single parameter is fully documented. The description adds the endpoint-version rationale needed to trust round-tripping into update_rdsh_farm, making it 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?

Only one parameter and schema description coverage is 100%, so the schema already documents farm_id and its source. The description adds no parameter-level syntax or format detail beyond that, which is the baseline 3 case.

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

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

States a specific verb+resource ('Get detailed information about a specific RDS farm'), and the get/list contrast with list_rdsh_farms is reinforced by the schema parameter note ('obtain from list_rdsh_farms'). It does not explicitly name the sibling in the prose, so it falls just short of 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 v10 rationale implies a read-then-update workflow (it guarantees the fields update_rdsh_farm needs), and the schema points to list_rdsh_farms for obtaining the ID. However, there is no explicit 'use this when / not when' statement or named alternative, so 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the bar is lower, and the description adds meaningful security-relevant context: the returned ticket grants a technician view AND control of the desktop session. That consequence is not derivable from the schema or annotations and is genuinely useful, though it omits any expiry/lifetime or scoping details for the ticket.

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

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

Two sentences, purpose front-loaded, second sentence supplying the behavioral consequence. No filler, no repetition of the tool name.

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

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

With an output schema present, return-value documentation is not required, and the description nevertheless characterizes the return. Annotations cover the safety profile, so for a one-parameter tool this is largely complete; the only real omission is when-to-use guidance.

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 (session_id) is fully documented in the schema, so the description adds nothing about parameter meaning. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Generate a Microsoft Remote Assistance ticket for a user session') and clarifies the artifact produced. It is distinguishable from session-management siblings like get_session or diagnose_session, though it doesn't explicitly contrast with them.

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

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

The description says what the tool produces but gives no guidance on when to reach for it versus the many sibling session tools (get_session, diagnose_session, etc.). No prerequisites, no exclusions, no named alternatives — usage is left entirely to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say what 'detailed information' comprises, whether the session must be active, or what happens when the ID is unknown, so it contributes no behavioral context of its own.

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, front-loaded sentence with no filler or redundancy. It is efficient, though its 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?

For a simple one-parameter read tool with an output schema and read-only annotations, the definition is close to sufficient: returns need not be described and safety is declared. The only meaningful gap is the absent distinction from list_sessions and diagnose_session.

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 fully documented there, including its provenance ('obtain from list_sessions'), so the baseline of 3 applies. The description adds no format, validation, or sourcing 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?

States a clear verb (Get) and resource (detailed information about a specific user session), so the agent knows it is a point lookup by ID. It does not, however, distinguish itself from close siblings like list_sessions or diagnose_session, leaving the agent to infer where 'detail' ends and 'diagnosis' 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as list_sessions (for enumerating) or diagnose_session (for troubleshooting). The only routing hint, 'obtain from list_sessions', lives in the schema rather than the description.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful scope context by naming what kinds of settings are bundled into the global response, but says nothing about authentication requirements or the size/shape of the payload.

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

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

Two tight sentences with the core action front-loaded and the enumeration following as supporting detail. No filler, no repetition of the 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?

An output schema exists, so return values need not be explained, and the description still usefully sketches the breadth of the response. The remaining gap is sibling disambiguation against get_environment_properties and get_global_policies, which an agent needs to choose the right call.

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

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

The tool takes zero parameters, so the baseline is 4. Nothing in the description is needed to explain inputs, and the enumeration of returned setting categories is the only meaningful content.

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 (global Horizon configuration settings), then enumerates the concrete categories returned (session timeouts, pre-launch, display protocol, HTML Access). This distinguishes it from a generic settings tool, but it never contrasts itself with the closely related get_environment_properties or get_global_policies siblings, so an agent still has to infer which one holds a given setting.

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 when-to-use guidance, no prerequisites, and no mention of the update_settings sibling that pairs with this read. The read-only nature is only implied by the verb 'Get', leaving the agent to guess between this tool, get_environment_properties, and get_global_policies.

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

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

The annotations only give a bare safety profile (not read-only, not idempotent, closed-world), while the description adds genuinely useful behavior: tokens are held server-side, the session persists across subsequent calls, the server auto-renews with the refresh token after ~8 hours, and only short token hints come back. That is exactly the context an agent cannot derive from the structured fields.

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

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

Three tight sentences, front-loaded with the action and scoped by 'for this server'. The closing note about short token hints is slightly redundant given the output schema exists, but nothing is padded.

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

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

With an output schema present, return values need no explanation, and the session/refresh behavior is well covered for an auth tool. The remaining gap is the absence of any guidance on what to do on credential failure or how this interacts with horizon_refresh_token and horizon_logout, plus the fact that four params are accepted while only three are required is never discussed.

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 defaults, format, and writeOnly masking for the password, so the schema already carries the parameter semantics. The description adds no parameter-level detail such as domain format or base_url fallback, which is the expected baseline 3 when the schema does the heavy lifting.

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

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

The description gives a specific verb (Authenticate) and resource (Horizon) plus the side effect of activating a server-side session, which cleanly separates it from the read-oriented siblings like list_connection_servers. It does not explicitly name horizon_refresh_token or horizon_logout, so sibling differentiation is left implicit.

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

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

The token-lifecycle sentence ('subsequent tool calls work immediately', auto-renewal at ~8 hours) implies this is a one-time entry point rather than something to call repeatedly, but there is no explicit when-to-use statement, no precondition checklist, and no pointer to horizon_refresh_token as the alternative once a session exists.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the state-changing nature is covered. The description adds genuinely useful detail that both access AND refresh tokens are invalidated, but says nothing about auth requirements, whether an already-invalid session errors, or idempotency behavior (annotations claim idempotentHint=false, which is questionable for a logout but not contradicted).

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 that conveys the exact effect of the call. Nothing is wasted and nothing essential is buried.

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

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

An output schema exists, so return values need no explanation, and both parameters are documented in the schema. For a simple token-invalidation tool with full annotation coverage, the description is nearly sufficient; only the routing versus sibling session tools is missing.

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

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

Schema description coverage is 100%: base_url and the optional refresh_token override are fully documented in the schema, including the 'omit to use the stored token' fallback. The description adds no parameter-level meaning beyond that, 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 (invalidate) and resource (current Horizon session, access + refresh tokens), which is more precise than 'logout' alone. It implicitly differs from logoff_sessions (which terminates user sessions on machines) but never names that sibling or horizon_refresh_token, so differentiation is left to inference.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as horizon_login (to start a session) or logoff_sessions (to end a user's remote session). The agent must guess the routing from the description's scope alone.

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

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

Annotations already declare non-read-only, non-idempotent, non-destructive, closed-world. The description adds that automatic refresh normally supersedes this call, which is useful behavior context, but omits whether the stored refresh token is rotated/invalidated and what happens on an invalid token.

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, zero waste, with the primary action stated first and the caveat immediately after. Nothing to 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?

With an output schema present and fully documented optional parameters, the description need not explain return values. It covers the main practical concern (when it's needed at all); only edge-case failure behavior is unaddressed, which is minor here.

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

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

Schema description coverage is 100% and both parameters (base_url, refresh_token) are documented in the schema, including the 'omit to use the stored token' default. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

The description states a specific verb (exchange) and resource (refresh token for access token), so the operation is unambiguous. It does not explicitly differentiate itself from horizon_login/horizon_logout, but the token-exchange semantics are distinct enough on their own.

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

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

It gives explicit when-not guidance: 'Rarely needed: the server already refreshes an expired access token automatically.' That tells the agent the default path is automatic refresh and this tool is the exception, which is exactly the routing information needed.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the meaningful behavioral context that this is the API equivalent of the Horizon Console OU picker, i.e., a discovery step feeding a provisioning flow. It does not discuss pagination or result size, but the output schema exists.

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

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

Front-loaded with the purpose, then downstream usage. The long parenthetical naming both create_desktop_pool and create_rdsh_farm paths is dense but earns its place by preventing a wrong-parameter mistake. Slightly verbose but no filler sentences.

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 single-parameter read tool with full schema coverage, an output schema, and annotations covering safety. The description covers the remaining risk (where the rdn is consumed and where it is not), which is exactly the gap needed for correct end-to-end use.

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?

One parameter (domain_id) with 100% schema description coverage, and the schema already says 'obtain from list_ad_domains'. The description's mention of ad_container_rdn refers to another tool's parameter, so it adds no meaning beyond the schema for this tool's own input. Baseline 3 applies.

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

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

States a specific verb and resource ('List AD containers (OUs)') plus scope ('available in a domain'), and clarifies the OU concept to separate it from list_ad_domains or search_ad_users_or_groups. An agent can identify exactly what this returns.

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

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

Explicitly tells the agent where the result goes: the rdn becomes ad_container_rdn in create_desktop_pool's customization_settings (or create_rdsh_farm's automated_farm_settings.customization_settings), and explicitly warns it is NOT provisioning_settings. That is precise downstream routing plus an exclusion.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a summary of what the response contains (trust relationships, status, bind accounts), which is some useful context, but since an output schema exists this is largely duplicated and no operational notes (auth scope, environment assumptions) are added.

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

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

Two short sentences, front-loaded with the action and scope, and the second sentence only adds return-value detail. No filler or redundancy.

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

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

For a zero-parameter read tool with annotations and an output schema, the description is nearly sufficient. The only missing element is any usage routing versus neighboring AD-related tools, which is a minor gap given the simplicity of the 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?

The tool takes zero parameters, so per the scoring baseline the schema carries no semantic burden the description must compensate for. Nothing confusing or misleading is present.

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

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

States a specific verb and resource ('List all Active Directory domains configured in the Horizon environment') and names the returned detail set (trust relationships, status, bind accounts). It is clearly distinguishable from siblings like list_ad_containers or list_ic_domain_accounts, though it does not explicitly contrast itself with them.

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

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

Usage is implied by the resource scope: an agent needing the AD domain inventory would pick this. However, the description names no alternatives, prerequisites, or conditions under which this tool should not be used.

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

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

Beyond the read-only annotation, the description discloses the return shape, pagination behavior, automatic fetch limits (10 pages / 5000 items), and the critical warning that has_more=true means the result is not the complete list. This is rich operational context that helps an agent avoid incorrect assumptions.

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 front-loaded with the purpose, then efficiently covers return fields and pagination handling. Every sentence earns its place; there is no redundant or filler content.

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

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

For a read-only list tool with an output schema and annotations, this description is complete enough. It explains the key pagination semantics and the has_more warning, so an agent has all the context needed to call it correctly.

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

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

Schema coverage is 100%, so all parameters are already documented. The description still adds value by explaining fetch_all's automatic stopping limits and truncated flag, and by recommending a filter when only a subset is needed, going beyond the schema's basic definitions.

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 opens with a specific verb and resource: 'List published application pools in the environment.' It clearly distinguishes this plural list operation from single-item siblings like get_application_pool and from other list tools such as list_desktop_pools.

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 useful guidance for handling pagination and fetch_all, but it does not explicitly state when to choose this tool over alternatives like get_application_pool or list_desktop_pools. Usage is implied rather than contrasted with siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds critical pagination behavior: has_more semantics, next_page continuation, fetch_all auto-fetch limits (10 pages / 5000 items), and the truncated flag. It also warns never to treat has_more=true results as complete, which is exactly the kind of behavioral disclosure that prevents agent error.

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

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

Front-loads the core action and then provides pagination guidance efficiently. The explicit return-field list is somewhat redundant because an output schema exists, but the pagination sentences are essential and well-integrated.

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 read-only annotations and an output schema, the description still supplies the key operational context an agent needs: use cases, return structure, pagination continuation, auto-fetch limits, and truncation warning. Nothing important for correct invocation appears to be missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining how to use page=next_page, how fetch_all behaves, and why a filter is preferred when a subset is needed.

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

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

States a specific verb and resource: list Horizon audit events, scoped to administrative actions and system events. The sibling tools do not include another audit-event lister, so the tool is clearly distinguishable.

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

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

Gives clear context with review, troubleshooting, and compliance-auditing use cases. It does not explicitly state when not to use it or name alternative tools, so it falls short of full when/when-not routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the meaningful filter that only instant-clone-eligible VMs are returned, but says nothing about pagination, empty results, or result richness beyond what the output schema carries.

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

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

A single tight sentence that front-loads the action and the qualifying scope with zero filler. Every clause earns its place.

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

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

For a read-only list tool with a complete schema, an output schema, and annotations covering safety, the description is sufficient to invoke it correctly. It would be fully complete with a brief note on when to prefer it over the vm_templates or base_vm_snapshots 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 description coverage is 100%, so both vcenter_id and datacenter_id are fully documented in the schema, with the vcenter_id description even pointing to list_virtual_centers. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

Specific verb (List) plus resource (VMs in vCenter) plus a clear scope qualifier (usable as base images for instant clone pools/farms). This distinguishes it from nearby siblings like list_vm_templates and list_base_vm_snapshots, though it never names them 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 'base images for instant clone pools/farms' phrasing implies when the tool is relevant, and the schema notes list_virtual_centers for obtaining IDs. However there is no explicit when-to-use/when-not, nor any routing to the template/snapshot siblings an agent might confuse it with.

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

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

Annotations mark this as a safe read-only operation, and the description adds critical behavioral context beyond that: snapshots taken before Horizon Agent installation will cause AGENT_CUSTOMIZATION_FAULT / IC Agent missing, so names should be checked for agent-related indicators. This is exactly the kind of failure-mode transparency an agent cannot infer from annotations.

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

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

Front-loads the tool's purpose, then the downstream usage, then a focused caution. Every sentence earns its place by preventing a known provisioning failure or clarifying snapshot selection.

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

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

An output schema exists, so return-value details are appropriately left out of the description. The description covers the remaining agent needs: what the tool lists, how the output connects to create_desktop_pool/create_rdsh_farm, and the snapshot-selection pitfall.

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?

Input schema description coverage is 100%, so both vcenter_id and base_vm_id are already documented in the schema. The description adds useful downstream meaning for the returned id, but it does not further explain the input parameters beyond what the schema already provides.

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

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

Starts with a specific verb and resource: 'List snapshots of a base VM.' It immediately explains the snapshots' purpose as images for instant clone pools or farms, which clearly distinguishes it from sibling tools such as list_base_vms and list_vm_templates.

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

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

Explicitly states when and how to use the result: the returned id becomes base_snapshot_id in create_desktop_pool or create_rdsh_farm when source is INSTANT_CLONE. It also warns against naive selection and says to ask the user when in doubt, covering when-not and alternative decision paths.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only the pod-scoping context; it says nothing about result volume, pagination, or ordering for what could be a multi-item listing.

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

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

One short sentence, front-loaded and free of filler. It is appropriately terse for a zero-argument listing tool, though it is arguably too terse to earn a 5.

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

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

An output schema exists, so return values need no explanation. For a zero-param, read-only enumeration the description is largely sufficient; the only gap is routing between this and the singular/health/backup connection-server 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify and nothing is misrepresented.

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

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

States a specific verb (List) and resource (Horizon Connection Servers) with scope limited to 'the pod'. It implicitly contrasts with the singular get_connection_server sibling, but never names it, so differentiation is left to inference.

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 when-to-use guidance and no alternatives named. With siblings like get_connection_server, get_connection_server_health, and trigger_connection_server_backup, an agent gets no explicit signal about when this enumeration is the right choice over those.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond annotations by explaining what the specs are (Sysprep/QuickPrep) and how the id is consumed downstream (hostname, domain join, license key). It says nothing about ordering or filtering, but that is minor given the read-only nature.

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

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

Two tight sentences, front-loaded with what the tool returns, then the downstream purpose. No filler, and every clause carries information the agent needs.

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

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

For a low-complexity, one-parameter read-only lister with an output schema present, the description covers identity, prerequisite, and consumer. Return-value details are rightly left to the output schema, so nothing needed to call it correctly is missing.

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

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

Schema coverage is 100% and the single vcenter_id parameter already documents its source ('obtain from list_virtual_centers'). The description adds no further parameter syntax or format detail, so the baseline 3 for high-coverage schemas 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?

Specific verb+resource: 'List vCenter customization specifications (Sysprep/QuickPrep) available for pool provisioning.' It names the OS-customization domain and scopes it to pool provisioning, which cleanly separates it from sibling listers like list_vm_templates or list_base_vms.

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

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

The second sentence supplies the usage context: the returned customization_specification_id feeds create_desktop_pool and create_rdsh_farm provisioning_settings. That effectively tells the agent when to call it (prior to pool/farm creation), though it states no exclusions or explicit alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the downstream-dependency rationale, which is useful, but says nothing about result size, pagination, or behavior when the vCenter has no datacenters.

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

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

Two sentences, both earning their place: the first names the operation, the second explains the value of the output. Nothing is padded or redundant.

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

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

With an output schema present, return values need not be described, and the parameter is fully documented. Purpose plus downstream usage is sufficient for an agent to call this correctly; only minor behavioral detail (e.g. empty results) is absent.

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

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

Schema coverage is 100% and the single parameter already documents its origin ('obtain from list_virtual_centers'), so the schema does the heavy lifting. The description adds no syntax or format detail beyond that, 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 and resource with scope ('List datacenters in a vCenter Server'), which an agent can distinguish from other list_* tools by resource. It stops short of explicit sibling differentiation beyond naming downstream consumers.

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

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

The second sentence explains why you would call this: the datacenter ID feeds list_vm_folders, list_hosts_or_clusters, and provisioning settings for create_desktop_pool / create_rdsh_farm. That is clear context for sequencing, though there are no explicit when-not conditions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful constraint that results are scoped to a host or cluster and that this feeds provisioning, but says nothing about pagination or result size. With annotations and an output schema carrying most of the load, a 3 is apt.

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

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

Two tight sentences: the first identifies the resource and its scope, the second states the downstream use. Nothing is redundant and the essential scope is front-loaded.

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

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

For a read-only list tool with an output schema, full parameter coverage, and safety annotations, the description is complete. It supplies the one thing structured fields cannot: why the agent would call this and what to do with the returned 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 description coverage is 100% and both parameters document their source tools (list_virtual_centers, list_hosts_or_clusters). The description adds no input-parameter detail beyond what the schema states, 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+resource ('List datastore clusters') and disambiguates from the near-name sibling list_datastores by glossing the resource as 'Storage DRS pods'. An agent can distinguish this from listing plain datastores without opening either schema.

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

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

Explicitly routes the agent downstream: the returned datastore_cluster_id feeds create_desktop_pool or create_rdsh_farm provisioning_settings when using Storage DRS. It gives clear context but no explicit when-not-to-use rule (e.g., when plain datastores suffice).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only that datastores are provisioning-relevant; it says nothing about filtering, pagination, or result scope, though an output schema exists to carry return details.

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 action and scope front-loaded and no filler. Slightly terse given it omits any routing to related list tools.

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 100% schema coverage and an output schema covering returns, the description is sufficient to call it correctly. It only lacks sibling differentiation against list_datastore_clusters.

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

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

Schema description coverage is 100%, and both parameters document their own purpose plus pointer tools (list_virtual_centers, list_hosts_or_clusters). The description adds no additional 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?

The description states a specific verb ("List") and resource ("datastores") with scope ("available in vCenter") and a use context ("for desktop pool or farm provisioning"). It does not distinguish itself from the closely named sibling list_datastore_clusters, which an agent would need to 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?

The phrase "for desktop pool or farm provisioning" implies when the result is useful, but there is no explicit when-to-use, prerequisite, or alternative (e.g., list_datastore_clusters) guidance. Usage is inferable, not stated.

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