Windows Sandbox MCP has clear tool names and basic descriptions, but suffers from critical gaps in schema completeness, parameter documentation, and error handling. Most tools lack structured output schemas, responses are plain strings rather than typed objects. Parameter descriptions exist but are minimal (avg ~40 chars, well below the 72-char baseline). No enum constraints on constrained inputs (e.g., 'runAs' accepts free-form strings instead of an enum). Error messages are generic strings rather than actionable recovery guidance. The server exposes Windows-specific functionality with reasonable naming (StartSandbox, ExecuteInSandbox, StopSandbox), but lacks the structured, LLM-optimized definitions expected of production tools.

• Define structured output schemas for all tools. E.g., StartSandbox should return {sandboxId: string, status: 'started'|'failed', message: string} instead of a plain string.
• Convert 'runAs' parameter to an enum: enum=['ExistingLogin', 'System']. Add description: 'Execution context. ExistingLogin runs as the logged-in user; System runs with system privileges.'
• Enhance error messages with actionable recovery steps. Replace 'No running sandbox found.' with 'No running sandbox found. Call StartSandbox() to create one.'
• Rename 'OpenSandboxRemoteSessionWindowAsync' to 'open_sandbox_session' (shorter, follows verb_noun convention, removes async suffix).
• Expand parameter descriptions to 80-150 chars. Include when to use, constraints, and defaults. E.g., 'Memory size in MB (512-8192, default 4096). Higher values improve performance but consume host resources.'