Five tools with consistent structure but significant quality gaps. All tools have basic descriptions (60-90 chars) and complete input schemas with typed parameters. However, descriptions lack actionable context for LLM selection, they state WHAT without explaining WHEN or WHY to use each tool. Parameter descriptions are minimal (5-15 chars) and do not explain constraints, formats, or dependencies. No output schemas documented. No error handling guidance. Tools are well-named with action verbs (get_*) but lack the depth expected for production agent use.

• Expand parameter descriptions to 50-100 chars each. For start_time and end_time, specify format: 'ISO 8601 datetime string (e.g., 2024-01-15T10:30:00Z)'. For region_name, list valid values or reference enum constraint.
• Document output schema for each tool. Example: 'Returns a JSON object with fields: logs (array of {timestamp, level, message}), total_count (int), next_cursor (string or null)'. This enables LLMs to extract and chain results.
• Differentiate tool descriptions by component. Rewrite get_launcher_logs as: 'Retrieve launcher container logs for MySQL server startup and initialization events.' Rewrite get_sidecar_logs as: 'Retrieve sidecar container logs for proxy, monitoring, or auxiliary service events.' This clarifies when to use each.
• Add error handling guidance to tool descriptions. Example: 'If region_name is invalid, returns error listing supported regions. If time range is invalid, returns error with valid format. Errors are not retryable; ask user to correct input.'
• Add pagination support: accept optional limit (default 100, max 1000) and offset parameters. Return total_count and next_offset in response. Document in description: 'Results are paginated; use limit and offset to retrieve large log sets.'