The server provides 13 tools with generally clear names and solid descriptions. Most tools have complete input schemas with typed parameters and descriptions. However, there are gaps in output schema documentation, limited error handling guidance, and some parameter descriptions lack specificity around constraints and formats. The tools follow verb_noun conventions well (get_*, list_*, update_*, add_*), and descriptions are in the 50-200 char range typical of good tools. All 13 tools are explicitly registered with schemas. Main weaknesses: (1) output schemas are not documented for any tool, LLMs cannot predict what fields to extract; (2) error handling lacks recovery guidance; (3) some parameter descriptions omit constraints (e.g., 'max_pages must be at least 1' is stated but not formally constrained); (4) no pagination limits are enforced or documented in output; (5) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite having clear READ_ONLY and WRITE distinctions.

• Document output schemas for all 13 tools. Specify the structure of the response object, including field names, types, and whether they are arrays, objects, or primitives. Include examples of pagination fields (if present) and timestamps. This enables LLMs to extract correct fields downstream.
• Add tool annotations to FastMCP tool definitions. Use @mcp.tool(description='...', hint={'readOnly': True}) for all READ_ONLY tools (12 tools), and @mcp.tool(..., hint={'destructive': True, 'idempotent': False}) for update_runbook to signal write/destructive intent. See FastMCP docs on hint parameter.
• Add recovery guidance to error scenarios in tool descriptions. E.g., for get_runbook_by_id: 'If runbook_id is invalid, call list_runbooks() to find the correct ID. Returns error 403 if user lacks read access, request workspace access and retry.' For update_runbook: 'Invalid field values (e.g. status not in {off,red,amber,green}) return 400 with actionable error; fix and retry.'
• Enforce and document pagination limits in output schemas. For tools like get_action_logs and list_runbooks, add 'returns an array of up to N items per page; response includes next_cursor for pagination' in description. Document actual response structure with fields like items[], total_count, next_cursor, or page_info{}.
• Formalize parameter constraints in JSON Schema. Add 'minimum': 1, 'maximum': <reasonable limit> to max_pages. Use 'enum' for stage, completion_type, and status fields instead of informal 'Allowed: X, Y, Z' strings in descriptions. Use 'pattern' or 'format' for ISO 8601 dates and IANA timezone names.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry