Skip to main content
Glama
Sign In
windows98-mcp

windows98-mcp

by ido-pluto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

qemu_media_eject

Eject the CD-ROM from the running Windows 98 VM now, and persist an empty drive so future starts boot without a disc.

Instructions

Eject the managed CD-ROM now when running and persist an empty drive for future starts.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "vm_id": "<vm_id>"
    },
    "name": "qemu_media_eject"
  }
}

Input Schema

NameRequiredDescriptionDefault
vm_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A3.6/5.0
Behavior4/5

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

With only generic annotations, the description carries the behavioral burden. It clearly discloses both key side effects: the eject happens 'now when running' and an empty drive is persisted 'for future starts.' It does not mention error cases or whether media files remain on disk, but the core behavior is transparent.

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?

One concise sentence with no filler. The operation is front-loaded, and both immediate and persisted effects earn their place in the sentence.

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?

For a single-parameter side-effect tool, the description covers what happens now and on future starts, leaving little ambiguity about the tool's effect. No output schema exists, but explaining return values is unnecessary for a simple eject action.

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

Parameters2/5

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

The sole parameter vm_id has no schema description (0% coverage), and the description does not mention the target VM or explain how vm_id relates to the eject operation. While the parameter name is fairly self-explanatory, the description adds no semantic value beyond the schema.

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 opens with a specific verb ('Eject') and resource ('managed CD-ROM'), then adds detail about immediate and future behavior. It distinguishes ejecting from deleting by noting the drive persists as empty for future starts, though it does not explicitly name sibling tools.

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 implies when to use the tool: when you need to eject the CD-ROM now and ensure the drive remains empty for future starts. It does not explicitly compare against alternatives like qemu_media_mount or qemu_media_delete, nor does it state exclusions or prerequisites.

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

Deploy Server

Other Tools