All 6 tools have identical critical deficiencies: empty input schemas ({}), minimal descriptions (15-20 chars), and no parameter documentation. Tool names use verb_noun pattern (scrape_*) but descriptions are too terse to guide LLM selection. No output schemas documented. No error handling guidance. This server fails baseline requirements for production agent tooling.

• Expand each tool description to 50 - 150 characters. Example: 'scrape_eks: Fetch EKS version EOL dates from AWS DescribeClusterVersions API and write to DynamoDB. Call this to refresh the EOL schedule for Kubernetes versions.' This tells LLM WHAT, WHEN, and WHAT IT DOES.
• Add input schema with optional parameters (e.g., 'region' to limit scrape scope, 'dry_run' to preview without writing). Even if currently unused, schema enables future flexibility and guides LLM on what can be controlled.
• Document output schema for each tool. Example: '{"service": "eks", "versions_updated": 5, "last_updated": "2024-01-15T10:30:00Z", "errors": []}'. This lets LLM verify success and extract counts for reporting.
• Add explicit error handling: return structured errors like '{"error": "DynamoDB throttled", "retryable": true, "hint": "Wait 30s and retry"}' instead of raw exceptions. Per pattern:recovery-guide, LLMs need actionable guidance.
• Consider splitting scrape_all into separate tools or add a 'services' parameter (enum: ["eks", "rds", "elasticache", "opensearch", "msk"]) so agents can target specific services. Current design forces all-or-nothing scraping.

Inferred effective spec: 2026-07-28+.

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