MS Project MCP has basic tool definitions but significant quality gaps. All 4 tools have descriptions and input schemas, but descriptions are minimal (10-50 chars), parameter descriptions are sparse or missing, and output schemas are not documented. No error handling guidance, no parameter validation hints, and no security considerations. Tool names follow verb_noun convention (open_project, new_project, get_project_info, set_project_properties) which is good, but descriptions lack context on when to use each tool or what to expect. The server exposes Windows COM automation directly without abstraction, creating platform-specific brittleness.

• Document output schemas for all tools. E.g., open_project returns {status, name, full_path, task_count, start, finish}. Include field types and descriptions so LLMs know what to extract.
• Expand tool descriptions to 100-200 chars. Add context: 'Open a Microsoft Project file (.mpp or .xml). Requires MS Project to be running on the local machine. Returns project metadata including task count, start/finish dates, and file path. Use this to load an existing project before querying or modifying tasks.'
• Add parameter validation hints. E.g., file_path: 'Absolute or relative path to .mpp or .xml file. File must exist and be readable. Returns error if file is locked or corrupted.'
• Implement structured error responses with recovery guidance. Instead of raising RuntimeError, return {error: 'MS_PROJECT_NOT_RUNNING', message: '...', recovery: 'Ensure MS Project is installed and running, then retry.'}
• Add per-parameter descriptions for all inputs. E.g., properties_json: 'JSON string with optional fields: title (string), manager (string), company (string), author (string), subject (string), status_date (YYYY-MM-DD), start (YYYY-MM-DD). Invalid JSON or unknown fields return error.'