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

With no annotations provided, the description carries the full disclosure burden. It adds useful behavioral context: the tool only works on dedicated pools and a machine can hold only one assigned user in most configurations. However, it does not mention permission requirements, what happens when a machine already has a user, or whether unassigning a nonexistent assignment is an 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?

Three short sentences with no filler. The core action is front-loaded, and the critical constraints follow economically. 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?

The description covers the essential operational constraints: dedicated-pool applicability and the one-user-per-machine limitation. Since an output schema is present, return-value documentation is not needed. Minor gaps remain around failure behavior on conflict, but the description is sufficient for correct invocation in typical cases.

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

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

Schema description coverage is 100% and each parameter, including the action enum values, is documented in the input schema. The description adds machine-context but no additional parameter-level meaning beyond the schema, matching the baseline.

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

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

The description opens with a clear verb-resource pair: 'Assign or unassign users to a dedicated desktop machine.' It also distinguishes the tool from pool-level entitlement tools by emphasizing 'machine' and 'dedicated (non-floating) desktop pools,' making its scope immediately recognizable.

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 explicitly limits applicability to machines in dedicated non-floating desktop pools, which tells an agent when NOT to use this tool. It does not name an alternative tool for pool-level assignments, but the exclusion is clear enough to guide selection.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. 'Publish' implies a creation/mutation operation, and the schema shows defaults and optional fields, but the description does not disclose side effects, whether the operation is reversible, or what happens on success/failure. It does not contradict any annotations, but it adds minimal behavioral context beyond the verb.

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

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

The description is a single concise sentence that states the action and the source context. It is front-loaded and efficient, with no wasted words. It could arguably include a bit more context, but for its length it is well-structured.

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

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

Given the tool has 9 parameters, a rich schema, and an output schema, the description is minimal but not inadequate. The schema covers parameter semantics, and the sibling list provides context. However, the description does not mention what the output contains, whether the operation is idempotent, or any prerequisites beyond the implied farm_id. For a creation tool with no annotations, a bit more context would be expected.

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

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

Schema description coverage is 100%, so the schema already documents all 9 parameters. The description itself adds no parameter-level meaning beyond the schema, but the baseline of 3 applies because the schema does the heavy lifting. The description's mention of 'from an RDS farm' reinforces the farm_id parameter's role, but that is already clear from the schema.

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

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

The description 'Publish a new application pool from an RDS farm' uses a specific verb ('Publish') and resource ('application pool'), and clearly distinguishes it from sibling tools like list_application_pools, get_application_pool, update_application_pool, and delete_application_pool. It could be slightly more explicit about the RDS farm context, but it is clear enough to differentiate from siblings.

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

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

The description implies the tool is used to create/publish a new application pool, and the required farm_id parameter references list_rdsh_farms, which gives a hint about a prerequisite. However, it does not explicitly state when to use this tool versus update_application_pool or delete_application_pool, nor does it mention any preconditions like needing an existing RDS farm.

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?

A textual caution discloses the most impactful behavior: provisioning an AUTOMATED pool begins creating VMs in vCenter immediately. Since no annotations are provided, this description carries the full burden, and it addresses a critical side effect that would otherwise surprise an agent. It lacks details like whether the operation is asynchronous, but the disclosed warning is substantial and valuable.

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 extremely concise: two short sentences that front-load the purpose ('Create a new desktop pool.') and then deliver a necessary caution. No wasted words; every sentence serves a purpose.

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

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

For a tool with a complex nested object parameter, the input schema is comprehensive and the output schema exists, which covers parameter details and return values. The description fills the only major contextual gap by warning about the immediate VM creation and mandating user confirmation. It is complete enough for an agent to handle the most consequential aspects.

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 description itself adds no parameter details; however, the input schema already has an extensive spec description, covering required keys, nested structures, and ID lookup references (schema coverage 100%). The baseline score of 3 applies, as the description does not need to repeat schema information.

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 ('Create') and resource ('desktop pool'), which clearly conveys the tool's purpose. The name and description distinguish it from sibling tools like 'create_rdsh_farm' and 'create_application_pool' without ambiguity.

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

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

The description provides a clear usage condition: always confirm with the user before calling, and warns explicitly about the side effect for AUTOMATED pools. It does not mention alternatives like update_desktop_pool, but the context is sufficient to know when 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?

No annotations are present, so the description carries the full behavioral burden. It does disclose a critical side effect: provisioning an AUTOMATED farm immediately begins creating VMs in vCenter, and it instructs to confirm with the user. Still, it omits other behavioral details such as permissions, error cases, reversibility, or what happens on a MANUAL 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?

The description is only two sentences with no filler. The action is stated first, and the critical safety caution is immediate and prominent. Every sentence earns its place.

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

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

For a create tool with a nested spec, the schema supplies detailed parameter guidance and the output schema covers return values. The description adds the crucial safety context about immediate VM creation. It is largely complete, though it could be stronger by explicitly noting MANUAL vs AUTOMATED behavior beyond the warning and by routing to alternatives.

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 carries the parameter detail. The spec field's description is notably rich: it lists required keys, AUTOMATED provisioning fields, the desktop_id link, and the lookup tools for resolving IDs. The top-level description adds no additional parameter semantics, warranting the baseline score 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 and resource: 'Create a new RDS farm.' This clearly identifies the operation and distinguishes it at a basic level from sibling create tools like create_desktop_pool or create_application_pool. It does not explicitly contrast itself with those siblings, so it falls short of a 5.

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

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

The CAUTION gives a meaningful prerequisite: confirm with the user before calling, and warns about the immediate side effects for AUTOMATED farms. However, it does not explicitly state when this tool should be used instead of alternatives, nor does it provide exclusions or comparison 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?

Because no annotations are provided, the description carries the burden of disclosing risks. It does disclose the critical consequence: 'Users will immediately lose access to this application.' It also instructs confirmation, which matters for a destructive operation. It stops short of explicitly stating irreversibility or how failures surface, but the key hazard is 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?

The description is extremely concise and front-loaded with the purpose, followed by the necessary warning. Each sentence earns its place and there is no filler.

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

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

For a destructive action with no annotations, the description provides the essential human-safety warning: users lose access and confirmation is required. Combined with complete schema descriptions and presence of an output schema, this is nearly complete. A minimal addition, such as explicitness about irreversibility, would make it a 5.

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

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

Schema coverage is 100%, so the input schema already documents both confirm and pool_id. The description adds no extra parameter-level meaning, which is acceptable at the baseline since the schema fields are self-explanatory and include relevant descriptions.

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

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

States a specific verb and resource: 'Delete a published application pool.' This clearly differentiates it from sibling tools like list_application_pools, get_application_pool, create_application_pool, and update_application_pool without needing to inspect schemas.

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

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

Provides clear usage context by warning that users will immediately lose access and instructing the caller to always confirm before calling. However, it does not explicitly name alternatives or exclusion cases, so it stops short of full when/when-not guidance.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly states the operation is destructive, deletes all machines, terminates active sessions, and mandates confirmation. This fully informs the agent of the consequences before invocation.

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

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

Two concise sentences: the first gives the core action, the second (CAUTION) front-loads critical safety information. No filler; every sentence earns its place.

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

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

For a destructive operation with no annotations, the description completely covers what it does, its effects, and the required pre-checks and user consent. An agent has everything needed to decide and correctly invoke the tool.

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

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

Schema description coverage is 100%, and the 'confirm' parameter description already provides detailed guidance (must be true, pre-calls, user approval). The tool description adds no extra parameter meaning beyond reinforcing confirmation, 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?

States a specific verb ('delete') and resource ('desktop pool') plus its scope ('all of its machines'). This clearly differentiates from sibling read/update tools like get_desktop_pool and update_desktop_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?

Explicitly warns of irreversibility and requires user confirmation. The parameter description on 'confirm' goes further, instructing the agent to call get_desktop_pool and list_sessions to verify safety before proceeding. This gives clear when-to-use and prerequisites, and implicitly when not to use (without approval).

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

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

With no annotations provided, the description fully carries the behavioral burden. It explicitly discloses irreversibility, deletion of all servers in the farm, and termination of active user sessions — the key destructive effects an agent must know before invocation.

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

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

Three short, high-value sentences: the operation, the consequence, and the mandatory confirmation guard. No filler or redundant wording; critical safety information is front-loaded.

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

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

For a simple two-parameter destructive tool with an output schema, the description sufficiently captures purpose, consequences, and the safety protocol. It could additionally mention authorization requirements or expected failure behavior, but those are not necessary for correct invocation given the schema's confirm 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%, so the description does not need to add parameter-level meaning. The description itself says nothing about farm_id or confirm, but the input schema already documents the confirm requirement and farm_id source. This meets the baseline 3 for high schema coverage.

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

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

The description uses a specific verb and resource: 'Delete an RDS farm and all of its servers.' This clearly distinguishes the tool from siblings like delete_desktop_pool, list_rdsh_farms, or rdsh_farm_action by naming the exact object and scope.

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

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

The description provides clear context for safe use by warning that the operation is irreversible and requiring user confirmation before calling. It does not explicitly name alternatives or when-not-to-use cases, but the destructive purpose and caution are strong enough for an agent to identify the correct branch.

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

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

No annotations are provided, so the description carries the burden. It explains the behavioral difference between enable/disable (session establishment) and enable-provisioning/disable-provisioning (VM provisioning). It also notes that disabling sessions allows existing sessions to continue, which is important behavioral context. It doesn't mention side effects like whether disabling affects running VMs, but the core behavior is 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?

The description is compact and front-loaded. The first sentence states the purpose, the second clarifies the two action dimensions, and the third gives a practical use case. Every sentence earns its place with no redundancy.

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

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

For a two-parameter tool with a full schema and output schema, the description is nearly complete. It explains the core behavior and the maintenance use case. It doesn't describe return values, but the output schema exists, so that's not required. A minor gap is not mentioning whether actions are reversible or if there are prerequisites (e.g., pool must exist), but the schema and context cover most 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 already documents both parameters. The description adds value by explaining the semantic difference between the two action types and the maintenance use case. It doesn't add much beyond the schema's own parameter descriptions, but the schema is already thorough. The description reinforces the key distinction, earning a 4 rather than a baseline 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 clearly states the tool's purpose: enabling, disabling, or toggling provisioning for desktop pools. It distinguishes between session control and provisioning control, which is a key nuance. The verb 'enable/disable/toggle' is specific and the resource 'desktop pools' is explicit.

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

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

The description provides clear context on when to use the tool and even gives a specific use case: 'Disabling provisioning is the correct way to pause scale-out during maintenance.' It doesn't explicitly name alternatives, but the sibling list shows related pool tools (create/update/delete) and this tool's action-oriented purpose is clear. A slight gap is not mentioning when to use this vs. machine_action or rdsh_farm_action, but the pool-specific scope is evident.

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

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

No annotations are present, so the description must carry behavioral disclosure. It does this well by explaining result keying by aspect name and the partial-failure contract: a failed aspect returns its error message as a string rather than failing the whole call. It could add permission or response-size context, but the core behavior is clear.

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 main purpose front-loaded and the aspect list and error behavior in the second sentence. No filler or redundant restatement of the schema.

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

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

For a 2-parameter diagnostic tool with an output schema, the description covers what the call returns and how failures behave. It is complete enough to select and invoke the tool correctly. It could be improved by pointing to alternatives, but that gap is already captured in usage_guidelines.

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 prose adds 'any combination' and single-call semantics but mostly restates the aspect enum in different words. It does not add formats or relationships 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?

Description opens with a specific verb+resource: 'Retrieve diagnostic information for a user session' and enumerates the five diagnosable aspects. This makes it clear it is a session-diagnostics tool rather than a generic session getter. It does not explicitly name sibling tools like get_session or get_metrics, so some 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?

The phrase 'in a single call' and the list of combinable aspects imply the tool is for collecting multiple diagnostics at once. No explicit when-to-use, when-not-to-use, or alternative tool names are given. This is adequate but not strong guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait: sessions remain active but clients are disconnected, and that user applications keep running. This is valuable context beyond the schema. It doesn't mention side effects like whether reconnection is possible or if any cleanup occurs, but the core behavior is 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?

The description is two sentences with zero waste. The core action is front-loaded, and the critical distinction from logoff_sessions is placed immediately after. Every sentence earns its place.

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

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

For a single-parameter tool with a clear action and an explicit sibling distinction, the description is nearly complete. It doesn't describe the return value, but an output schema exists, so that's not required. It could mention whether the operation is reversible or if there are prerequisites, but the essential information for correct invocation is present.

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

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

Schema description coverage is 100%, so the schema already documents the session_ids parameter. The description adds the behavioral nuance that the session remains active but the client is disconnected, which reinforces the parameter's meaning. Since coverage is high, a baseline of 3 applies, and the description adds a bit more context, justifying a 4.

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

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

The description clearly states the action ('Disconnect one or more user sessions') and the resource (user sessions), and explicitly distinguishes it from the sibling logoff_sessions by noting that sessions remain active while clients are disconnected. This is a specific verb+resource with clear differentiation from siblings.

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

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

The description explicitly says when to use this tool vs the alternative: 'Use logoff_sessions to fully terminate sessions.' This provides a clear exclusion and routes the agent to the correct sibling when full termination is 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?

With no annotations provided, the description must carry the full behavioral burden, and it does. It explicitly says the application will be force-closed, warns that unsaved data will be lost, and instructs the agent to confirm with the user. This is exactly the critical destructive behavior a model needs to call this tool safely. It doesn't describe every edge case, but the core irreversible impacts are 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?

The description is remarkably concise: two sentences state the purpose and a short caution block communicates the danger and the required user confirmation. There is no filler or redundant re-explanation of the tool name, and the critical warning appears directly after the action statement, earning every character.

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 2-parameter, has full schema coverage, and includes an output schema, so the description does not need to explain return values. It fills the safety gap provided by zero annotations with the caution about force-closing and data loss. It could still be slightly more complete by explicitly stating that the session and other applications remain unaffected, but this is largely inferable from the wording.

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 input schema already provides meaningful parameter descriptions—including an example of how to discover remote_application_id via diagnose_session. The tool description itself adds no parameter-specific semantics, so it remains at the standard baseline given the adequate schema coverage.

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

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

The description uses a specific verb ('Terminate') with a specific resource ('a remote application') and scopes it to 'running in a session.' This clearly distinguishes it from sibling tools that operate on whole sessions (e.g., disconnect_sessions, logoff_sessions, reset_or_restart_sessions). An agent can immediately understand this tool ends an individual application rather than a session.

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

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

The description implies the tool should be used when one wants to terminate a specific remote application, but it does not explicitly contrast this with alternatives such as logoff_sessions or mention when not to use it. The caution about confirming with the user is a behavioral guideline, not a usage selector. The semantics are clear enough to infer the intended use, but the description stops short of giving explicit when/when-not guidance.

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

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

No annotations are provided, so the description must carry the full behavioral disclosure burden. It only says 'Get detailed information' and does not mention lookup behavior, authentication needs, error conditions, or what happens when the AD user or group is not found.

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

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

The description is a single sentence with no filler. The action and target are front-loaded, making it easy to scan and understand immediately.

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

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

This is a simple one-parameter tool with an output schema, so the basics are covered. However, the description lacks when-to-use guidance and behavioral context, leaving the agent with only the minimal information needed to invoke it.

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

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

The schema already provides 100% coverage by describing ad_id as 'AD user or group ID.' The description adds no additional parameter semantics beyond echoing the resource type, so it meets the baseline without adding 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?

Description uses the verb 'Get' with a specific resource, 'a specific AD user or group,' making the operation clear. It doesn't explicitly differentiate from the sibling search_ad_users_or_groups, so it misses the chance to distinguish itself by contrast.

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

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

No guidance is given on when to use this tool versus alternatives. The obvious sibling, search_ad_users_or_groups, is never mentioned, leaving the agent to infer the distinction between 'get specific' and 'search' without support.

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

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

With no annotations, the description carries the burden, and it discloses the tool's return shape: three named sections (tools, resources, not_yet_supported). It does not explicitly state that the call itself is read-only or mention authentication prerequisites, though 'List' and the described output strongly imply a safe read operation.

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

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

The description is compact, front-loaded with the main action, then usage rationale, then a bulleted return summary. Every sentence serves a purpose and no information is repeated.

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

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

For a zero-parameter discovery tool with an output schema present, the description supplies all decision-relevant context: what it lists, why to call it, and exactly what sections the response contains. Nothing needed for correct invocation is missing.

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

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

The tool takes zero parameters, so there is nothing to explain; the empty input schema and 100% schema coverage are self-sufficient. Per the baseline rule for zero-parameter tools, a 4 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 opens with a specific verb and resource: 'List all available Horizon MCP tools, resources, and unsupported operations.' It clearly defines the tool's scope and distinguishes it from the many sibling operating tools because it is the meta/capability-discovery endpoint.

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 explicitly states when to call it: 'before attempting a task' and when informing users about support. Since it is a unique discovery tool with no functional sibling overlap, the lack of a when-not clause is not a meaningful gap.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get detailed information' and does not mention failure behavior, permissions, or side-effect profile; the read-only nature is merely implied by the verb.

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 that front-loads the action and resource with no filler or redundant detail. 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?

For a one-parameter getter with an output schema and a fully documented parameter, the description is nearly sufficient. It could more explicitly state the relationship to list_application_pools, but the parameter description already provides that pointer.

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 pool_id parameter already has a clear description with provenance ('obtain from list_application_pools'). The tool description itself adds no additional parameter meaning, so the baseline of 3 applies.

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

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

States a specific verb ('Get') and resource ('application pool') and narrows scope to 'a specific' pool, which distinguishes it from list_application_pools and other pool-related siblings. The resource 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?

No explicit when-to-use or alternatives are given, but 'specific application pool' implies use when a single pool's details are needed rather than enumeration. The parameter description adds a workflow hint by directing the agent to obtain pool_id from list_application_pools.

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

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

No annotations are provided, so the description carries the burden. 'Get' implies a read-only operationhint, but the description does not state any side effects, authorization requirements, or edge-case behavior (e.g., what happens when the server_id does not exist). It is not contradictory, but it is thin for a tool with no annotation support.

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

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

A single sentence with no filler; the key scoping phrase 'configuration details' and 'specific' are front-loaded. Nothing extraneous.

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

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

For a single-ID fetch with an output schema, minimal context is acceptable, but the description does not mention how the ID is obtained or distinguish from listing/health siblings. There is no annotation safety profile, so a sentence noting this is read-only or linking to list_connection_servers 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 coverage is 100%: the only parameter server_id is documented as 'Connection server ID'. The description adds the meaning that the tool returns configuration details for that server, but otherwise relies on the schema. This meets the baseline for full schema coverage.

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

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

The description states a clear verb ('Get') and resource ('configuration details for a specific Connection Server'), and the qualifier 'specific' distinguishes it from the list_connection_servers sibling. It does not explicitly name the sibling, but the scope is unambiguous.

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

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

The description implies when to use it (when you need details for one specific Connection Server, not a list), but it gives no explicit guidance about alternatives such as list_connection_servers or health-related tools. There are no exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get detailed health information' – it does not disclose whether this is a read-only operation, whether it requires special permissions, whether it can fail for disconnected servers, or what 'detailed health' includes. For a health-check tool, an agent would benefit from knowing it is safe/read-only and what kind of data it returns.

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

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

The description is a single, front-loaded sentence with no wasted words. It clearly states the action and resource. It could add a brief note about usage or output, but as-is it is concise and scannable.

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

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

The tool has a single required parameter, a 100% schema-described parameter, and an output schema (not shown but indicated as present). The description is minimal but sufficient for an agent to know what the tool does. However, without annotations, the lack of behavioral context (read-only safety, error conditions) and lack of explicit relationship to sibling tools leaves some gaps. It is adequate but not rich.

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

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

Schema description coverage is 100%: the only parameter, server_id, is described as 'Connection server ID'. The description adds the context that the ID refers to a specific Connection Server, but it does not explain how to obtain the ID (e.g., from list_connection_servers) or any format expectations. Baseline 3 is appropriate since the schema already documents the parameter adequately.

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 ('detailed health information for a specific Connection Server'), which clearly distinguishes it from the sibling 'get_connection_server' (which likely returns general server info) and 'get_infrastructure_health' (which covers overall health). It lacks an explicit contrast with siblings, but the resource and scope are clear.

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

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

The description implies usage: call when you need detailed health for one Connection Server, identified by server_id. It does not explicitly state when not to use it or mention alternatives like 'get_connection_server' or 'get_infrastructure_health'. The context is clear enough for an agent to infer, but no explicit routing guidance 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?

With no annotations provided, the description carries the behavioral burden. 'Get' communicates a read operation and 'configuration and status' indicates what is returned, which is adequate for a simple lookup. It does not mention error behavior, permissions, or side effects, but no mutating behavior is suggested.

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 redundant detail. Every word contributes to identifying the operation, resource, and output scope, making it appropriately concise for a single-parameter read tool.

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

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

For a one-parameter get operation with an output schema, the core calling information is present: the resource, the high-level return content, and the strongly documented pool_id parameter. The main gaps are the lack of explicit sibling differentiation and the absence of read-only confirmation, which keeps it adequate but not comprehensive.

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 pool_id parameter description already tells the agent to obtain the ID from list_desktop_pools. The prose description does not add parameter-level meaning beyond the schema, so the high-coverage baseline of 3 applies.

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

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

The description uses a clear verb-resource pairing: 'Get' + 'desktop pool', and specifies the scope as 'detailed configuration and status.' It does not explicitly differentiate from list_desktop_pools or other get_* siblings, though 'specific desktop pool' implies a singular lookup.

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 or when-not-to-use guidance is given. The description does not name an alternative tool or provide context for choosing this over list_desktop_pools; the agent must infer usage from the tool name and the pool_id parameter description in the schema.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only states it 'gets a mapping' and gives no indication of return format, error handling, or side effects. The read-only nature is implied but not stated, leaving the agent with limited behavioral 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?

The description is a single sentence that front-loads the action and resource, with no unnecessary words. It is concise and well-structured, earning a perfect score.

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 operation with an output schema present, the description adequately conveys the purpose. It does not cover edge cases like empty results, but the output schema likely handles return values. Overall, it is complete enough for a simple lookup.

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

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

The tool has zero parameters, and schema description coverage is effectively 100% (empty schema). Per the rubric, a 0-parameter tool gets a baseline of 4 since parameter semantics are irrelevant. No additional description 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?

The description clearly states the action 'Get' and the specific resource 'mapping of domain NETBIOS names to DNS names for all configured domains.' It is unambiguous and distinguishes itself from similarly named tools like list_ad_domains by specifying the mapping nature, though it does not explicitly name alternatives.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or context. It is a simple read operation, but without any usage hints, the agent must infer when it is appropriate.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. The verb 'Get' communicates a read-only, non-mutating operation, and the listed property domains clarify what the call returns. It does not discuss authorization requirements or side effects, but for a zero-parameter getter that is a relatively minor gap.

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

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

A single sentence leads with the verb and resource, then gives concrete examples of what is included. There is no filler or redundancy; every part of the sentence adds useful scope information.

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

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

For a no-parameter, read-only tool with an output schema, the description is largely sufficient: it identifies the resource and the categories returned, while the output schema can handle exact return fields. It is slightly incomplete in not orienting the agent on when to choose this over the many sibling getter tools.

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

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

The input schema has zero properties and is fully covered by the empty schema, so there are no parameters for the description to clarify. The baseline for a 0-parameter tool is 4, and the description does not need to compensate for missing parameter documentation.

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

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

The description opens with a specific verb ('Get') and a clear resource ('environment-level properties'), and lists concrete examples such as version, FIPS mode, and feature flags. It does not explicitly contrast with similar sibling getters like get_settings or get_global_policies, so it falls short of full sibling differentiation.

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

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

No guidance is given on when to use this tool versus alternatives such as get_settings, get_global_policies, or get_api_coverage. The intended usage is only implied by the tool name and description; there are no explicit conditions, exclusions, or prerequisites.

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

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

With no annotations, the description carries the disclosure burden. It implies a read-only operation via 'Get,' but does not mention authentication requirements, potential latency, whether it can fail under certain conditions, or what 'connection status' concretely includes. This is adequate but leaves room for more transparency.

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

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

The description is a single, focused sentence with no filler or redundant phrasing. It is appropriately sized for a no-argument getter.

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 tool with an output schema available, the description covers the core purpose well. It could be slightly more complete by mentioning the read-only nature or typical use cases, but it is largely sufficient.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to add parameter-level detail because there is nothing to configure or pass in.

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 specifies a clear verb ('Get') and a well-defined resource ('configuration and connection status of the Horizon event database'). It is specific enough that an agent can distinguish it from other tools in the sibling list, such as health or metrics tools.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as get_connection_server_health or get_infrastructure_health. It states what the tool does but not the conditions or context that would select it over a sibling.

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

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

No annotations are provided, so the description carries the burden. The verb 'Get' implies a read-only operation, which is the essential behavioral fact. It does not disclose any further behavior, such as authorization expectations or what happens when no policies exist, but for a parameterless getter this is a minimally acceptable but not rich 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?

The description is a single well-structured sentence that leads with the action and resource, then lists illustrative policy categories without unnecessary detail. It earns its place and avoids over-explanation.

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

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

This is a low-complexity, no-parameter getter with an output schema available, so the description is largely enough to invoke the tool correctly. It would be slightly stronger with a note distinguishing it from the similarly named getters, but nothing critical is missing.

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

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

The tool has zero input parameters, so the schema already fully defines the empty input. The description adds no parameter-level meaning, but that is not needed here; the baseline for a 0-parameter tool is therefore an adequate score.

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

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

The description clearly states the action ('Get') and the resource ('global VDI policies') while giving concrete policy categories (USB redirection, multimedia redirection, clipboard settings). It does not explicitly differentiate itself from siblings like 'get_settings' or 'get_environment_properties', so it misses the top score.

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 only says what the tool returns and provides no when-to-use guidance, prerequisites, or alternatives. There is no clue about when an agent should choose this over the similar get_settings or get_environment_properties, making this dimension weak.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It explains the summary rollup, key-by-component-name result organization, per-component information (e.g., reachability, load, tunnel counts), and a meaningful error-handling behavior: a failed component returns an error string instead of failing the whole call. This goes well beyond a generic 'get health' statement and prepares the agent for partial-failure scenarios.

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, uses a tight bulleted list for the component breakdown, and closes with a concise behavioral note. Every sentence and bullet adds information the agent needs; there is no filler, repetition, or redundant restatement of the tool name.

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

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

For a single-optional-parameter read-only health tool with an output schema available, the description covers the important decision-relevant details: what components exist, what each returns, how results are keyed, and how component failures behave. The schema handles the default value and allowed enums, so nothing critical is missing for invoking the tool 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?

The schema already documents the components parameter with an enum and 100% coverage, so the baseline is 3. The description adds value by explaining what each component value actually represents, such as connection_servers returning 'reachability, load, and tunnel counts' and farms returning 'RDS farm health and server capacity.' This semantic detail is not in the schema, so the parameter meaning is usefully enriched.

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: 'Get health and status across Horizon infrastructure in a single call.' The bulleted component list makes the aggregate scope concrete and separates this from the per-resource sibling tools like get_connection_server_health and list_gateways. An agent can immediately tell this is a cross-component health rollup, not a single-component lookup.

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 'in a single call' and the enumeration of multiple component types clearly communicate that this tool is for broad infrastructure health checks. However, it does not explicitly name sibling tools or state when to prefer this over get_connection_server_health or the individual list_* tools. The context is clear but exclusions are 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?

The description clearly indicates a read-only operation ('Get detailed information'), which implies no mutation. No annotations are present, but for a simple getter this is reasonably transparent. It doesn't discuss errors or access requirements, but the operation's safety is evident.

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

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

The description is a single concise sentence that states exactly what the tool does. No filler or ambiguity.

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

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

There is an output schema (per context), so return structure is presumably defined. The single required parameter is documented with its source. The description is sufficient for an agent to invoke this simple getter 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?

The schema covers 100% of parameters, including a helpful note ('Machine ID — obtain from list_machines'). The description adds no additional parameter meaning beyond the schema, 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 clearly states a specific action (get detailed information) on a specific resource (a machine). It effectively distinguishes from list-oriented siblings like list_machines by indicating a single, specific machine. It doesn't explicitly differentiate from other get_* tools, but the resource is unambiguous.

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

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

The parameter schema explicitly instructs to obtain machine_id from list_machines, providing clear context for how to use the tool. It doesn't explicitly state when not to use it, but the read-only retrieval context is clear.

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

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

With no annotations provided, the description carries the behavioral burden and does well by disclosing that results are keyed by scope name and that a failed scope returns an error string without failing the whole call. It does not explicitly state side effects or permission requirements, but 'get' plus the error behavior gives adequate transparency.

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

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

The description is front-loaded with the purpose and then uses a compact bullet list that maps each scope to its meaning. Every sentence earns its place, and the final behavior note is important rather than 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?

The tool has one optional parameter, an output schema, and the description covers defaults, scope semantics, result keying, and partial failure behavior. Nothing an agent needs to call it correctly 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?

Although the input schema already enumerates valid scopes, the description adds genuine semantics by explaining what each scope returns, e.g., 'pools: session and machine counts per desktop pool' and 'system: CPU and memory metrics'. This materially helps an agent choose the right scope values.

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

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

The description clearly identifies the action ('Get performance and capacity metrics') and the resource ('across the Horizon environment in a single call'). The enumerated scopes make it immediately distinguishable from per-resource siblings like get_machine or get_desktop_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?

The description provides clear context for when to use this tool: collecting metrics across multiple scope types in one call. It does not explicitly name sibling alternatives or exclusion criteria, so it stops short of full when/when-not guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what is returned but does not explicitly state that this is a read-only operation, mention authentication requirements, or explain any edge cases or side effects. The verb 'Get' implies read-only behavior, but the description relies on that inference instead of stating it.

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

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

The description is a single, clear, front-loaded sentence that communicates the essential purpose without excess words. Every part of the sentence contributes meaning.

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

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

The tool is simple, has only two required parameters, and benefits from a full input schema and an output schema. However, the description lacks usage guidance and behavioral detail, so while an agent can likely call the tool correctly, some context around its relationship to sibling tools and its read-only nature is missing.

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

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

Schema description coverage is 100%, so the input schema fully documents pool_id and pool_type. The description adds no additional parameter-level meaning beyond the schema, which keeps this at the baseline score 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 clearly states the action ('Get') and the resource ('users and groups entitled to access a specific pool'). It is more specific than the generic tool name and conveys that it targets one pool, but it does not explicitly distinguish itself from the sibling tool list_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?

No guidance is given about when to use this tool versus alternatives such as list_pool_entitlements or set_pool_entitlements. The description implies the basic use case—retrieving entitlements for a specific pool—but provides no exclusions, prerequisites, or alternative routing.

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

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

No annotations are present, so the description bears the behavioral burden. 'Get' implies a read-only operation and 'detailed information' implies a richer response than a list, but the description does not disclose authentication needs, error behavior, or any side effects. It is minimally adequate for a simple read tool.

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

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

The description is a single, front-loaded sentence with no redundant words. It immediately communicates the action and target, and every word contributes to the meaning.

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

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

The tool is low-complexity with one required parameter and an output schema already defining the return value. The description plus parameter guidance covers the essential invocation path. It could be slightly more explicit about when to use list_rdsh_farms first, but nothing critical is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by telling the agent the farm_id should be obtained from list_rdsh_farms, which is useful provenance for correctly invoking the tool.

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

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

The description clearly states the verb ('Get'), the resource ('RDS farm'), and the singular scope ('a specific'), which distinguishes it from list/create/update/delete siblings. It does not explicitly name an alternative, but the singular 'specific' contrasts with list operations.

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 use case is implied: call this when you need detailed information about one RDS farm, and obtain its ID via list_rdsh_farms. However, there is no explicit guidance about when not to use it or which sibling to choose instead, so the agent must infer the context.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It does disclose a significant trait: the ticket grants view and control access to the user's desktop. However, it does not mention whether generating the ticket creates state, requires special permissions, expires, or has other side effects.

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

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

The description is two clear sentences, front-loaded with the primary action and followed by the key result. There is no filler or redundant restating of the tool name, and every sentence contributes useful information.

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

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

For a simple one-parameter tool with an output schema, the description covers the core action and result well. It is slightly incomplete only because it does not address usage boundaries or side effects, but those are not critical for a straightforward ticket-generation 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 schema already documents session_id with 100% coverage, so the description does not need to add much. It provides contextual framing by tying the ticket to a 'user session', but it does not add extra meaning about the parameter's format, constraints, or behavior beyond the schema.

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

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

The description uses a specific verb, 'Generate', and a specific resource, 'Microsoft Remote Assistance ticket for a user session'. It also clarifies the outcome: the ticket lets a help desk technician view and control the desktop session, which clearly differentiates it from sibling session and diagnostic 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 intended use case is implied by the description: generating a remote assistance ticket for an existing session. However, it does not explicitly state when to prefer this over related tools such as get_session or diagnose_session, nor does it mention any exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, yet it only states 'Get detailed information.' It does not explicitly confirm a read-only side-effect profile, mention authentication requirements, or describe error behavior on an unknown session ID.

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

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

The description is a single, front-loaded sentence with no filler. It efficiently communicates the tool's primary action.

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 getter with an output schema, the purpose is clear and the parameter is well documented. However, the absence of usage guidance and explicit behavioral disclosure leaves the description incomplete for an agent without annotations to rely on.

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

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

The schema covers the sole parameter session_id with a description that even points to list_sessions as the source. The tool description itself adds no parameter-level meaning, but given 100% schema coverage, 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 uses the specific verb 'Get' and resource 'detailed information about a specific user session,' making the operation clear. The word 'specific' differentiates it from sibling list_sessions, which lists all 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?

The description provides no guidance on when to use this tool versus alternatives such as list_sessions or diagnose_session. It does not state that the session ID should be obtained from list_sessions (that hint appears only in the parameter schema) or mention any 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?

No annotations are provided, so the description carries the full transparency burden. 'Get' strongly implies a non-mutating read operation, and the listed setting categories suggest what information is available, but the description does not explicitly state side-effect absence, authorization needs, pagination, or call cost.

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 exactly two sentences with no filler. The verb and resource are front-loaded, and the second sentence gives useful concrete examples of the settings scope without repeating schema or annotation information.

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

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

For a zero-parameter tool, the description covers the purpose and the content scope, and the availability of an output schema removes the need to detail return values. Nothing important is missing for the agent to select and invoke the tool 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?

The input schema has zero parameters, so the zero-parameter baseline applies. The description has no parameter semantics to clarify because the tool requires no arguments; the listed content scope is sufficient.

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: 'Get the global Horizon configuration settings'. It lists concrete included settings (client session timeouts, pre-launch settings, display protocol defaults, HTML Access) that distinguish it from sibling getters such as get_global_policies or get_environment_properties, though it does not explicitly name those alternatives.

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

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

The description makes clear this is a global settings read operation and implicitly separates it from update_settings, but it gives no explicit when-to-use or when-not-to-use guidance. It does not mention when an agent should prefer get_global_policies, get_environment_properties, or update_settings instead.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses a meaningful side effect (updating the running server's active token), token validity duration, and security requirements for handling tokens. This is strong transparency for an authentication tool.

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

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

The description is well-structured: purpose first, then token behavior, side effect, and security guidance. Every sentence adds useful information and there is no filler.

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

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

For an authentication tool with an output schema, the description covers what the agent needs: token lifetimes, refresh path, active-token side effect, and security handling. It is complete enough to call the tool correctly and manage the resulting credentials.

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

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

Schema coverage is 100%, and the schema already describes each parameter including base_url's default behavior. The description does not add new parameter-level meaning, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('Authenticate') and resource ('Horizon') and clearly states the return of access and refresh tokens. It also differentiates itself from the sibling horizon_refresh_token by explaining that the refresh token is used there.

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 explains when to use horizon_refresh_token instead of re-entering credentials, which provides alternative guidance. It does not explicitly state when not to call horizon_login, but the refresh-token flow is clear enough that an agent can infer the intended lifecycle.

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

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

With no annotations, the description carries the behavioral burden and does state the core effect: invalidation of access and refresh tokens. However, it does not disclose whether the action is irreversible, whether errors occur for already-invalidated tokens, or any rate/authorization constraints, leaving partial ambiguity about side effects.

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

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

A single, front-loaded sentence contains the essential action and scope with no wasted words. Every part earns its place, and the token scope clarifies exactly what the invalidate operation targets.

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 logout tool with an output schema and full parameter documentation, the description is mostly complete. The main missing piece is usage context relative to horizon_login and horizon_refresh_token, but the core callable semantics are adequately covered.

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 mentions tokens at a high level but adds no parameter-level meaning beyond what the schema already provides for refresh_token and base_url, such as token format or how to obtain the refresh token.

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

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

The description uses a specific verb ('Invalidate') and a clear resource ('current Horizon session') and even names the tokens affected. This cleanly distinguishes it from siblings like horizon_login and horizon_refresh_token, which create or refresh sessions rather than end 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 no explicit guidance on when to use this tool versus alternatives. It does not mention that horizon_refresh_token is for renewal or that logout should be called at session end, leaving the agent to infer the intended use from the name and sibling list.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses the exchange action and the time-based purpose, but does not mention security implications, error conditions, or whether the old token is invalidated. This is adequate but not rich.

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

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

Two sentences with no wasted words. The primary action is front-loaded, followed by the usage condition. Highly efficient.

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 description covers the main use case and condition. An output schema exists, so return values need not be explained. It could mention that the refresh token comes from horizon_login, but the schema already states this, making the description 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?

Schema description coverage is 100% for both parameters (base_url and refresh_token), so the schema already documents them. The description adds no extra parameter semantics beyond what is in the schema.

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

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

The description states a specific action ('Exchange a refresh token for a new access token') with a clear resource (refresh token -> access token). It is distinct from sibling tools like horizon_login (initial authentication) and horizon_logout (session termination).

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 to use: 'before the current access token expires (~8 hours) to maintain an active session without re-entering credentials.' This gives clear context, though it does not name alternatives or explicitly state when not to use it.

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

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

No annotations are provided, so the description carries the burden. It discloses that the rdn from results is used as ad_container_rdn, which is useful behavioral context. However, it doesn't describe the output structure, whether it returns all OUs or only those with certain permissions, or any domain-specific failure modes. The description adds some value but not deep behavioral detail.

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 compact and front-loaded: the first sentence states the verb, resource, and purpose. The second sentence adds the downstream usage context, and the third provides a helpful analogy. No wasted words.

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

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

For a simple one-parameter list tool with an output schema, the description is nearly complete. It explains why the tool exists, how the result is consumed, and where the parameter comes from. The only minor gap is not describing the output shape, but the output schema exists and the description's downstream usage context compensates.

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 domain_id is already described as 'AD domain ID — obtain from list_ad_domains'. The description adds the context that the domain is used for pool provisioning, but doesn't add new parameter-level meaning beyond the schema. 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 clearly states the tool lists AD containers (OUs) for a domain, with a specific purpose: pool provisioning. It explicitly names the downstream consumers (create_desktop_pool and create_rdsh_farm) and the exact field (ad_container_rdn) the result feeds into, which distinguishes it from sibling list tools like list_ad_domains or list_vm_folders.

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 explains when to use this tool: when picking an OU during pool/farm provisioning, and it references the Horizon Console's OU picker as an analogy. It doesn't explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to select it over sibling list tools.

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

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

With no annotations, the description carries the full behavioral burden. It transparently discloses a read-only enumeration operation and the kinds of details returned. The main gaps are no explicit mention of pagination or error behavior, but for a zero-parameter list tool with an output schema, these are low-impact omissions.

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 — a clear purpose statement followed by a brief return detail hint. No filler, no redundancy, and the key action ('List all ...') is front-loaded.

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

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

For a zero-parameter, read-only list with an output schema, the description covers the essential call semantics. It could be slightly more complete by explicitly contrasting with domain-adjacent siblings, but the complexity is low and no call-critical information is missing.

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

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

There are zero parameters, so there is no semantic baggage to document. The schema description coverage is 100%; nothing further is needed, and the description does not attempt to add unnecessary parameter context. The baseline of 4 is appropriate.

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

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

The description uses the specific verb 'list' with a clear resource: 'Active Directory domains configured in the Horizon environment.' It also names the returned categories (trust relationships, status, bind accounts), and this scope distinguishes it from siblings like list_ad_containers or get_domain_netbios_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 description implies the natural use case — enumerating configured AD domains — but it does not explicitly state when to prefer this over sibling tools such as list_ic_domain_accounts or get_domain_netbios_map. There are no exclusions or alternative routing cues.

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 verb 'List' and qualifier 'published' communicate that this is a read-only enumeration of a subset of application pools, which is meaningful context in the absence of annotations. It does not disclose behavior such as pagination limits, ordering, or how 'published' is determined, and there are no annotations to fill that gap.

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

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

The description is a single front-loaded sentence that identifies the operation and scope in eight words. There is no filler, redundancy, or structural clutter.

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 paginated list tool with a complete input schema and an output schema, the description is largely sufficient for an agent to call the tool. It still omits any explicit hint about when to prefer this over sibling read tools, so it is not a perfect 5.

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

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

The input schema already describes all three parameters, so the description does not need to repeat them; it adds nothing about the expected filter JSON syntax or pagination semantics beyond the schema. Baseline 3 applies because schema coverage is complete.

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

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

The description names a specific verb ('List') and resource ('published application pools'), so an agent immediately understands the operation and target. It does not reference sibling tools such as get_application_pool or list_desktop_pools, so there is some ambiguity for a reader unfamiliar with the pool hierarchy.

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

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

No guidance is given on when to use this tool instead of get_application_pool, list_desktop_pools, or list_pool_entitlements. A phrase such as 'Use get_application_pool to fetch a single pool' would disambiguate; without it the agent must infer the correct choice from the name alone.

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

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

No annotations are provided, so the description carries the full burden. It scopes the events to 'administrative actions and system events' and 'list' implies non-destructive read, but it does not explicitly confirm read-only behavior, pagination, or any access prerequisites. The assertion is not misleading, but could add more explicit safety 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?

Two sentences: the first states what the tool does, the second provides supporting use cases. No wasted wording, front-loaded with the key action.

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 output schema was already included, and the parameters are simple and 100% covered by the schema. The description adequately captures purpose and use cases. A bit more explicitly about filter usage or a confirming 'read-only' could be added, but overall the agent is well-positioned to use this tool 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?

The input schema already fully describes the page, size, and filter parameters with 100% coverage. The description adds no parameter-specific guidance, so the baseline of 3 applies because the schema carries the meaning.

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

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

The description clearly identifies the action ('List') and the specific resource ('Horizon audit events'), clarifying with 'administrative actions and system events'. This distinguishes it from siblings like list_sessions or get_settings, which target different resources.

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

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

The description states practical use cases: reviewing recent changes, troubleshooting, and compliance auditing. This gives clear context for when the tool is appropriate, but it does not explicitly name alternatives or exclusion conditions, so a 4 rather than a 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that it lists VMs but does not clarify whether it only lists VMs that are eligible as base images (e.g., powered off, not in use), whether it is a read-only operation, or any filtering logic. It does not describe the output format or any side effects. This is a gap for a tool that will be used to inform creation decisions.

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

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

The description is a single sentence with no fluff loss or padding. It is front-loaded with the action and purpose. It is appropriately sized for the simplicity of the tool.

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

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

Given the tool has only 2 parametersatine with clear schema coverage, the description is minimally complete. However, it lacks details on the return value structure (though an output schema exists), and important eligibility criteria for base images are omitted. An agent might struggle to understand exactly which VMs are included without further context. This is adequate but with clear gaps in behavioral expectations.

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 documents both parameters clearly (vcenter_id and datacenter_id). However, the description does not add any extra meaning beyond what the schema provides; it does not clarify the meaning of 'base images' in parameter context or how the datacenter filter affects results. With high coverage, baseline is 3, but the description adds no value about parameter usage beyond the schema, so a 2 is warranted for the complete absence of supplementary guidance.

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

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

The description clearly states the verb ('List'), resource ('VMs in vCenter'), and the specific purpose ('can be used as base images for instant clone pools/farms'). This distinguishes it from sibling tools like list_vm_templates or list_virtual_centers, though it could be more explicit about why this differs from 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?

The description implies usage for selecting base images for instant clone pools/farms, which provides context. However, it does not explicitly state when to use this tool over alternatives like list_vm_templates or list_base_vm_snapshots, nor does it mention any conditions or exclusions. The usage context is implied 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?

No annotations are provided, so the description carries the behavioral burden. It does clarify that the returned snapshots are those usable as an image for instant clones, and 'List' implies a read-only operation. However, it does not disclose whether snapshots are filtered, ordered, paginated, or whether any prerequisites beyond vcenter_id and base_vm_id apply.

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

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

Two sentences, zero filler. The first sentence defines the tool, the second states the downstream value. The most important scoping information ('instant clone pool or farm') 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 simple two-parameter list call with an output schema, the description is nearly complete: it provides identity, purpose, and downstream consumers. The only minor gap is an explicit statement about what the snapshots do or do not include, but the existing sentences plus schema are sufficient for correct invocation.

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

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

The input schema has 100% description coverage — both base_vm_id and vcenter_id have clear provenance descriptions ('obtain from list_base_vms' / 'obtain from list_virtual_centers'). The tool description adds no parameter-level meaning beyond the schema, so it hits the baseline exactly.

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 the exact action and resource: 'List snapshots of a base VM' — not base VMs, not templates, but snapshots. It also explains the downstream purpose ('can be used as the image for an instant clone pool or farm'), which clearly distinguishes this from sibling tools like 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 is explicit usage guidance: the snapshot_id returned is required by create_desktop_pool and create_rdsh_farm provisioning_settings when source is INSTANT_CLONE. This tells an agent exactly when this tool is needed, tying it to a concrete downstream workflow.

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

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

No annotations are provided, so the description must disclose behavior itself. It clearly indicates an enumeration operation with no mutation, but it does not mention authentication, failure conditions, or other runtime behavior beyond the action.

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 entire definition is a single sentence that states the action, resource, and scope. There is no filler or redundant information.

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

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

For a parameterless listing tool with an output schema, this is largely complete. The main gap is not stating authentication prerequisites, especially given sibling tools like horizon_login.

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

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

The tool has zero parameters and the input schema already covers everything with no properties, so detailed parameter documentation is unnecessary. The description also adds useful scoping with 'all ... in the pod'.

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 ('List'), a specific resource ('Horizon Connection Servers'), and a clear scope ('all ... in the pod'), making the tool easy to distinguish from siblings like get_connection_server. This is exactly what an agent needs to identify the tool at a glance.

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

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

There is no guidance on when to use this tool versus alternatives such as get_connection_server, and no mention of prerequisites like authenticating first. Any usage recommendation is only implied by the word 'List'.

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

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

No annotations are provided, so the description carries full burden. It describes the action ('List') which implies a read-only operation, but does not explicitly state side-effect-free behavior, authentication requirements, or error conditions. The description adds the practical context of result usage, but lacks the explicit safety disclosure one might expect without annotations.

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

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

The description is two sentences with zero waste. The primary action is front-loaded, and the second sentence explains the downstream relevance. No redundant phrasing or over-elaboration.

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

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

Given the presence of an output schema, the description does not need to enumerate return fields. It covers the purpose, usage context, and exactly how the result feeds into other provisioning tools (create_desktop_pool, create_rdsh_farm). An agent has all necessary information to decide when to call this tool and to interpret its role 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%: the only parameter 'vcenter_id' already has a descriptive comment in the schema ('vCenter ID — obtain from list_virtual_centers'). The tool description adds no extra meaning about this parameter beyond what the schema provides, so it stays at the baseline for full coverage.

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

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

The description clearly states the verb 'List' and the resource 'vCenter customization specifications', and adds context about their use for pool provisioning. It differentiates from sibling list tools (e.g., list_virtual_centers, list_desktop_pools) by naming the specific object type and its role in provisioning workflows.

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 explicitly connects this tool to downstream usage: 'The customization_specification_id from these results is used in create_desktop_pool and create_rdsh_farm...' This tells the agent when to call it. It does not name alternatives because none exist among siblings; it effectively implies the when-not-to-use by its specialized purpose.

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

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

No annotations exist, so the description needs to carry the behavioral load. The 'list' verb implies a read-only operation, and the dependency context adds practical value, but the description does not mention permissions, pagination, or other behavioral caveats. It is adequate but not rich.

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

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

The description is two sentences: the first front-loads the core action, and the second adds the key cross-tool context. There is no filler or redundant restating of schema details.

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

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

This is a one-parameter, read-only list operation with an output schema available. The description names the vCenter scope, explains how the input is obtained, and clarifies how the output is used downstream. Nothing critical is missing for calling 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% and the only parameter, vcenter_id, is already clearly documented in the schema with 'obtain from list_virtual_centers.' The tool description adds no extra parameter details, so the baseline score 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 action and resource: 'List datacenters in a vCenter Server.' It also distinguishes itself from siblings by explaining that the returned datacenter ID is required by list_vm_folders, list_hosts_or_clusters, and create_desktop_pool/create_rdsh_farm, making its role clear relative to other list 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 explicitly tells the agent when this tool is useful: before calling tools that require a datacenter ID. It does not provide explicit when-not/alternative guidance, but the dependency framing is enough to route correct usage.

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

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

No annotations are present, so the description carries the behavioral burden. The verb 'List' communicates a read-only intent, and the phrase 'available on a host or cluster' defines the data scope. It could add prerequisite or permission details, but for a simple list operation the description is adequate.

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

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

The description is compact and front-loaded. The first sentence states the purpose, the second explains downstream integration without repetition. Every sentence earns its place and there is no wasted information.

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

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

For a 2-parameter read-only listing tool with an output schema and full schema parameter descriptions, the description covers the relevant context: what it lists, the object type, and how the result is used. Slightly more detail about prerequisites or scope limitations could be added, but nothing critical is missing.

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

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

Schema coverage is 100% and both parameters already have descriptions pointing to their source tools (list_virtual_centers and list_hosts_or_clusters). The tool description adds context about the output rather than deepening the meaning of the parameters themselves, so it stays at the high-coverage baseline.

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

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

The description uses a specific verb ('List') and a precise resource ('datastore clusters / Storage DRS pods'), and clarifies the scope ('available on a host or cluster'). It naturally distinguishes itself from siblings like list_datastores by naming the exact resource type.

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

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

It explicitly explains why one would call this tool: to obtain a datastore_cluster_id for use in create_desktop_pool or create_rdsh_farm under Storage DRS. It does not name excluded alternatives such as list_datastores, but the intended use case is clearly communicated.

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

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

No annotations are provided, so the description should carry the full behavioral burden. It states the purpose but gives no indication of side effects (likely read-only), performance, pagination, or error conditions. Since it's a listing operation, it's probably safe, but the description does not explicitly reassure the agent about safety or other behaviors.

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

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

The description is a single sentence that is clear and to the point. It efficiently states the purpose and the context (vCenter, provisioning) without filler. It could potentially be expanded with usage guidance, but given the schema's coverage, it is appropriately concise.

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

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

Given the tool's simplicity (list operation, two parameters fully documented in schema, output schema exists), the description is sufficient for basic invocation. However, it does not mention return value structure (though output schema exists) or any specific behavior like whether it lists only datastores accessible to the given host/cluster. This is a minor gap, but the core functionality is clear enough for most use cases.

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

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

The schema descriptions are already comprehensive (100% coverage): both parameters have clear descriptions including how to obtain them via sibling tools. The tool description adds little beyond the schema, so the baseline of 3 applies. No additional meaning is provided beyond what's in the schema.

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

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

The description states a specific verb ('List') and resource ('datastores') and adds the context of vCenter and its use for desktop pool or farm provisioning. It does not explicitly distinguish from the sibling 'list_datastore_clusters', but the resource is clear enough to infer the difference.

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

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

The description implies the tool is used when datastores are needed for provisioning, and the parameter descriptions guide the user to use sibling tools (list_virtual_centers and list_hosts_or_clusters) to obtain required IDs. However, it does not explicitly state when to use this over list_datastore_clusters or other alternatives, leaving some inference to the agent.

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

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

No annotations are provided, so the description carries the full behavioral burden. It only says 'List' and does not explicitly state that the operation is read-only, nor does it clarify pagination behavior. The use of 'all' conflicts somewhat with the page/size parameters, which may mislead an agent into expecting a single uncapped response.

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

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

The description is a single sentence with no filler, and the key information is front-loaded. It communicates the tool's purpose in the most compact useful form possible.

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 list endpoint, the parameter schema and output schema cover most invocation needs. The main gap is that the description does not reconcile 'all' with the paginated page/size defaults, and it could explicitly note the read-only nature, but overall it remains sufficiently complete for a straightforward list 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%, with page, size, and filter all documented meaningfully. The description adds no additional parameter semantics, so the baseline score 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 names a specific verb ('List'), a specific resource ('desktop pools'), and a scope ('VDI and RDS' in the Horizon environment). It clearly conveys a collection endpoint and is readily separable from sibling tools like get_desktop_pool, create_desktop_pool, and list_rdsh_farms by verb and resource.

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: this tool is for enumerating desktop pools. However, the description provides no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as get_desktop_pool for a single pool or list_rdsh_farms for farms.

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

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

No annotations are provided, so the description carries the burden. 'List' implies a read-only operation with no side effects, which is useful. However, it does not mention pagination, result limits, or access requirements. For a zero-parameter list tool this is acceptable but not deeply informative.

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

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

A single, front-loaded sentence with no filler. It states the action and resource immediately and 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?

This is a simple, parameterless list operation with an output schema present. The description sufficiently defines the scope and return intent; nothing critical is missing for an agent to invoke it correctly.

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

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

The tool has zero parameters and schema coverage is 100%, so the description adds no parameter-level detail. With no parameters to document, the baseline of 4 is appropriate.

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

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

The description uses a specific verb ('List') with a specific resource ('Unified Access Gateways') and a clear scope ('all registered'). This makes it easy for an agent to distinguish it from sibling list tools that target different resources.

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

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

The description clearly identifies the context for this tool: listing registered UAGs. It does not explicitly name alternatives or exclusions, but the sibling tools target distinct resources, so the intended usage is unambiguous.

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

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

With no annotations, the description carries the behavioral disclosure burden. 'List' implies a read-only operation and the description mentions the host_or_cluster_id as a useful output, but it does not disclose auth requirements, pagination, or any limitations. Some behavior is conveyed, but not richly.

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 brief, front-loaded with the core purpose, and uses a second sentence only to add valuable downstream context. No wasted words or repetition of schema details.

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 list operation with only two fully documented parameters and an output schema present, the description is nearly complete. It also explains why the output matters by naming downstream consumers. Minor gaps such as explicit behavioral caveats are not critical for this tool.

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

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

Schema coverage is 100% and both parameters already have descriptions explaining where to obtain them (list_virtual_centers, list_datacenters). The description does not add meaningful parameter-level detail beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states the operation: 'List hosts and clusters in a vCenter datacenter.' This uses a specific verb and resource, and distinguishes it from siblings like list_datacenters and list_virtual_centers by indicating exactly what objects are returned and their scope.

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

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

The description provides explicit usage context by explaining that the returned host_or_cluster_id is required by list_datastores, list_resource_pools, list_network_labels, and provisioning_settings for create_desktop_pool/create_rdsh_farm. It does not state exclusions or name an alternative, but the downstream dependency is clear 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?

The verb 'List' implies a read-only operationchers, but there are no annotations to confirm, and the description does not state permissions, pagination, or return behavior. Since it is a simple no-parameter list and an output schema exists, the ambiguity is limited but still present.

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, focused sentence with a clear verb and resource. No filler or redundancy; it efficiently communicates what the tool does and its purpose.

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

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

For a parameterless list tool, the description names the resource and its purpose, which is largely sufficient. It does not name sibling alternatives or note the absence of filtering, but the available output schema and zero parameters make the tool simple enough for an agent to invoke 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?

The tool has zero parameters accruing to baseline 4. The description does not need to document any parameter details, though it could mention that it returns all accounts without filtering.

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 has a specific verb and object: 'List instant clone domain accounts', and it adds the purpose ('used for provisioning instant clone desktops'), which clearly distinguishes it from siblings like list_ad_domains or list_application_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 implies when the tool is relevant by naming its use case (provisioning instant clone desktops), but it does not explicitly contrast it with sibling tools like list_ad_domains or search_ad_users. Usage context is present, but no direct guidance on alternatives is given.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool lists three kinds of resources, but it doesn't describe any behavioral traits like pagination, filtering, or whether it returns all items at once. For a read-only list operation, the lack of annotations is partially mitigated by the simple scope, but more behavioral context (e.g., pagination, result limits) would be valuable.

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

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

The description is a single sentence that is concise and front-loaded with the action and resource. It wastes no words, though it could be slightly more informative about behavior. The trailing whitespace is a minor formatting issue but doesn't affect clarity.

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

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

For a simple list tool with one parameter and an output schema, the description is mostly complete. However, it doesn't mention any pagination, filtering, or result size limits, which are common for list operations. The output schema exists, so return values are covered, but behavioral context is thin.

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 documents the 'resource' parameter with an enum and descriptions for each value. The description adds minimal value beyond the schema, essentially restating the enum values. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description states a specific verb ('List') and resource ('image management streams, versions, or tags'), which clearly distinguishes it from sibling tools like list_connection_servers or list_desktop_pools. It doesn't explicitly name a sibling alternative, but the resource scope is clear enough to differentiate it from other list 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 implies usage by listing the three resource types, but it doesn't explicitly state when to use this tool versus alternatives. There are no exclusions or alternative tool references. The context is clear for a simple list operation, but no explicit guidance 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?

No annotations are provided, so the description carries the behavioral burden. It clearly indicates a read-only listing operation and the fields returned, which is transparent for a simple list tool. However, it does not disclose any potential pagination, ordering, or availability behavior, though none may be expected for this tool.

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

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

A single, front-loaded sentence with no wasted words. It names the action, resource, and specific output fields, making it efficient and easy to parse.

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 list operation with an output schema present, the description covers what an agent needs to know: what is listed and what information is returned. It is slightly light on behavioral context, but nothing critical is missing for such a simple tool.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. The description still provides value by indicating what the returned data will contain, which aligns with the baseline for parameterless tools.

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'), a clear resource ('Horizon licenses'), and the exact fields of interest (status, mode, expiry). It is immediately distinguishable from sibling list tools like list_connection_servers or list_virtual_centers, which target different resources.

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

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

The description implies the tool is used when someone needs license information, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. For a no-parameter list-all tool, the implied context is clear enough, yet there is no explicit 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?

No annotations are provided, so the description carries the full burden. It does disclose that this is a read-style list operation and shows the filtering behavior with concrete examples, but it does not mention pagination behavior, authentication requirements, or any side effects. This is adequate but leaves some behavioral context implicit.

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 compact and front-loaded: the purpose appears first, followed by two barely redundant, high-value filter examples. Every line earns its place and no fluff is present.

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 presence of an output schema and full parameter documentation, the description covers the essential call semantics: what the tool lists and how to filter the most common dimensions. Minor gaps remain around pagination defaults and any prerequisite authentication, but these are partially covered by the schema and the overall tool context.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description adds meaningful value beyond the schema by giving two ready-to-use filter strings and a concrete valid state value ('AVAILABLE'), which helps the agent construct correct filter JSON without additional inference.

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