Server has 10 tools with basic descriptions and input schemas, but significant quality gaps limit production readiness. All tools have descriptions (10-50 chars, below the 50-200 char baseline for LLM optimization), and input schemas are present but minimal. Parameter descriptions are generic ('AWS region to query') and lack actionable constraints. Error handling returns raw exception strings instead of recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Output schemas are not documented, LLMs cannot predict response structure. Tools like create_experiment_template accept complex nested objects (targets, actions, stop_conditions) with no schema definition or validation guidance.

• Expand tool descriptions to 50-200 chars. Example: 'List all AWS FIS experiment templates in the specified region. Call this first to discover available templates before starting an experiment. Returns template ID, name, description, and creation time.'
• Add explicit JSON Schema definitions for complex parameters. For create_experiment_template, define targets and actions as objects with required/optional fields, enums for action types, and examples.
• Replace generic error strings with actionable recovery guidance. E.g., 'Template not found. Call list_experiment_templates() to see available templates.' or 'Invalid region. Supported regions: us-east-1, us-west-2, eu-west-1.'
• Add tool annotations: mark delete_experiment_template with destructiveHint=true, start_experiment and stop_experiment with idempotentHint=true (if client_token ensures idempotency), and all read-only tools with readOnlyHint=true.
• Document output schemas in tool descriptions or as separate schema definitions. E.g., 'Returns: {id: string, state: {status: string, reason?: string}, startTime: ISO8601, tags: object}'