Four tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. All tools have descriptions (10-80 chars, below the 194-char baseline), and input schemas are present but sparse. No tool annotations (readOnlyHint/destructiveHint). Error handling and recovery guidance absent. Naming is verb-forward (create_, request_, lookup_, search_) but descriptions lack WHEN/WHY context and output structure documentation. No evidence of pagination, result limits, or chaining IDs in responses.

• Document output schema for each tool. Example: 'Returns {ticket_id: string (TCK-*), status: string, created_at: ISO8601, team: string}'. This enables LLMs to chain calls and extract required fields.
• Expand tool descriptions to 100-200 chars. Include WHEN to use, WHAT it returns, and any prerequisites. Example: 'Create a support ticket for CloudOps incidents. Returns ticket_id and status. Use when reporting infrastructure issues that require team action.'
• Add destructiveHint and idempotentHint annotations to all tools. Mark create_ticket and request_temporary_read_only_access as destructiveHint=true so LLMs know to confirm before executing.
• Enhance parameter descriptions with valid values, format constraints, and discovery hints. Example for 'team': 'The team to assign the ticket to (e.g. CloudOps, Security, Platform). Call list_teams() to discover available teams.'
• Implement error handling with recovery guidance. Return structured errors like {error: 'invalid_team', message: 'Team "CloudOps" not found. Available teams: CloudOps, Security, Platform', retryable: false}.