qemu_change_media

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

Even though annotations already declare destructiveHint and idempotentHint, the description adds real behavior: force=True ejects despite a guest tray lock while the default refuses, format defaults to auto-probing, and the call wraps QMP blockdev-change-medium. It does not explain what happens to the previously attached medium or the failure mode if path is invalid.

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?

Purpose is front-loaded in one sentence, then parameter guidance follows in a logical order. Some phrasing is conversational and slightly padded ('qemu-mcp can't guess it for you, since it depends on the machine type/QEMU version'), but each clause still conveys actionable 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 QMP wrapper with an output schema already documenting return values, the description covers what the agent needs: device identification, path precondition, format default, and the safety-relevant force behavior. The unexplained 'name' parameter is the sole omission and is likely a cross-tool convention.

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 0%, so the description carries the burden, and it does well for four of five params: device sourcing, path existence requirement, format auto-probe default, and force semantics. The required 'name' parameter is never explained, which is the only notable gap.

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 opening sentence states a specific verb and resource ('swap the medium in a removable drive') plus an example and the key benefit ('without rebooting'). The parenthetical mention of qemu_boot's iso/disk params makes the distinction from the boot-time media path explicit, so an agent can separate this from qemu_boot or qemu_qmp without reading 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?

It gives concrete preconditions (path must already exist), tells the agent where to obtain the device value (query-block's 'qdev' field) and why it can't be guessed, and states the default vs forced behavior on guest-locked drives. What's missing is a crisp statement of when not to use this tool versus alternatives such as qemu_qmp blockdev-change-medium or rebooting via qemu_boot.

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