boot-device

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

With no annotations present, the description carries the full behavioral burden and does so thoroughly. It discloses that the tool waits until the target is ready, returns a tagged payload, can take 2–10 minutes on Android, hot-boots from snapshots with cold-boot fallback, and terminates spawned devices on Android/Electron boot failure. This is unusually rich operational 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?

Although long, the description is dense and well structured: core action first, then platform selection, usage timing, return shapes, and operational caveats. Every sentence carries information needed to invoke the tool correctly, and the critical selector rule 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 complex four-platform tool with 10 parameters, no annotations, and no output schema, the description is complete. It explains return payloads for every platform, mutual exclusivity of platform-selector parameters, boot durations, snapshot behavior, and failure cleanup. The schema handles remaining platform-specific parameter details.

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 cross-parameter meaning by explaining that the passed argument selects the platform, that Android assigns a serial automatically, and that a CDP port is auto-picked unless electronPort is supplied. This is more than a per-field schema listing provides centrally.

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: start an iOS simulator, launch an Android emulator, start a Vega VVD, or spawn an Electron app. It also explains that each platform is selected by a specific argument, which makes the tool's purpose distinct from siblings like list-devices and launch-app.

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 clear usage context: 'Use at the start of a session once you have picked a target.' It also explains that the choice of platform is determined by which argument is passed. However, it does not explicitly name when-not-to-use cases or contrast with post-boot tools like launch-app or restart-app.

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