CALM MCP server defines 17 tools with complete input schemas and basic descriptions. Naming follows verb_noun convention (list, get, create, update, delete). However, descriptions are terse (avg ~80 chars, well below the 194-char baseline for A+ tools), lack context on WHEN to use each tool, and omit recovery guidance. Parameter descriptions are sparse, many params like 'status', 'priorityId', 'responsibleId' lack detail on valid values or constraints. Output schemas are not documented, forcing LLMs to infer response structure. Error handling is absent from tool definitions. Security considerations (permission gates, audit trails) are not visible. Composition is sound, tools are single-responsibility and chainable via ID returns. Overall: functional but below production baseline.

• Add outputSchema to every tool definition documenting the response structure. Example for calm_projects_list: {type: 'object', properties: {projects: {type: 'array', items: {type: 'object', properties: {id: {type: 'string'}, name: {type: 'string'}, status: {type: 'string'}, type: {type: 'string'}, modifiedAt: {type: 'string', format: 'date-time'}}}}, totalCount: {type: 'integer'}}}
• Expand tool descriptions to 100-200 chars. Include WHEN to use, prerequisites, and what the tool returns. Example: 'List Cloud ALM projects with optional status filter. Call this first to discover available projects before creating tasks. Returns project id, name, status (ACTIVE|CLOSED), type, and modifiedAt. Supports pagination via top (1-200, default 50) and skip.'
• Add enum constraints or detailed descriptions for all status/priority/code parameters. Replace 'e.g. OPEN, IN_PROGRESS, DONE' with explicit enum: {type: 'string', enum: ['OPEN', 'IN_PROGRESS', 'DONE']} or document valid values in the description.
• Add recovery guidance to tool descriptions for common failure modes. Example for calm_tasks_create: 'If projectId is invalid, call calm_projects_list to find a valid project UUID. If title is empty, provide a non-empty string (max 255 chars).'
• Implement a dry-run or confirmation pattern for destructive tools. Add an optional 'confirm' parameter to calm_tasks_delete and calm_features_delete, or create separate preview tools (e.g., calm_tasks_preview_delete) that show what will be deleted before the actual delete is called.