Horizon MCP Server

update_desktop_pool

DestructiveIdempotent

Modify an existing desktop pool's configuration by passing a cleaned pool specification; first fetch current config with get_desktop_pool, remove read-only fields, then apply changes.

Instructions

Update an existing desktop pool's configuration.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`spec`	Yes	Updated pool specification. Retrieve the current config with get_desktop_pool, strip the read-only/immutable fields listed below, modify what you intend to change, and pass the rest through unchanged — verified live against a real server to require no guessing. Fields to remove from get_desktop_pool's response before sending (present there but rejected or meaningless here): id, name, type, source, naming_method, vcenter_id, vcenter_name, farm_id, user_assignment, created_at, updated_at, delete_in_progress, and the num_machines/num_sessions/num_application_sessions/user_group_count/application_count counters. Everything else from get_desktop_pool — including display_assigned_machine_name, display_machine_alias, access_group_id, enable_provisioning, stop_provisioning_on_error, transparent_page_sharing_scope, session_type, and pattern_naming_settings, none of which earlier versions of get_desktop_pool used to return — can be passed straight through.
`pool_id`	Yes	Desktop pool ID — obtain from list_desktop_pools

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.0Sep 30, 2026

changedInput schema / properties / spec / description

Previous value: -"Updated pool specification. Retrieve the current config with get_desktop_pool, modify the relevant fields, and pass the result here. Omit read-only fields such as id, type, and source."New value: +"Updated pool specification. Retrieve the current config with get_desktop_pool, strip the read-only/immutable fields listed below, modify what you intend to change, and pass the rest through unchanged — verified live against a real server to require no guessing. Fields to remove from get_desktop_pool's response before sending (present there but rejected or meaningless here): id, name, type, source, naming_method, vcenter_id, vcenter_name, farm_id, user_assignment, created_at, updated_at, delete_in_progress, and the num_machines/num_sessions/num_application_sessions/user_group_count/application_count counters. Everything else from get_desktop_pool — including display_assigned_machine_name, display_machine_alias, access_group_id, enable_provisioning, stop_provisioning_on_error, transparent_page_sharing_scope, session_type, and pattern_naming_settings, none of which earlier versions of get_desktop_pool used to return — can be passed straight through."

First observedv0.1.0Sep 10, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The schema's spec description adds valuable behavioral context: the tool requires fetching the current config and stripping specific immutable/counter fields, with a verified list of fields to remove. This goes beyond the annotations by explaining the required preparation workflow and the consequences of sending immutable fields, though it omits permission requirements and exact update semantics.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a tool whose detailed parameter semantics are delegated to the schema.

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

Completeness4/5

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

Given the rich input schema (detailed spec construction), the presence of an output schema, and annotations covering safety/intent, the one-sentence description is largely sufficient. The main gap is the lack of any usage context (when to choose update over create/delete or other pool actions), but the schema's guidance compensates for most of the mechanical completeness.

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

Parameters3/5

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 tool description itself adds no parameter details beyond the schema, which already fully documents both parameters (including the extensive spec construction guidance). While the schema is rich, the description does not supplement it.

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

Purpose4/5

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

The description states a specific verb ('Update') and resource ('existing desktop pool's configuration'), clearly distinguishing it from create/delete/get siblings by implication. However, it does not explicitly name alternative tools or scope the update (e.g., full replacement vs. partial), leaving some ambiguity in differentiation.

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

Usage Guidelines3/5

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

The description itself provides no when-to-use or when-not-to-use guidance. The detailed workflow for constructing the spec (retrieve with get_desktop_pool, strip fields, modify, pass through) is embedded in the schema property description, not the tool description, so usage is only implied via the 'Update' verb and the sibling set.

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

Deploy Server