Server has 4 tools with minimal documentation. Tool names follow verb_noun pattern (getAvailableBuckets, getBucketObjects, getCsvObjects, readCsvObject), which is acceptable. However, descriptions are extremely brief (10-30 chars), well below the 50-200 char baseline for LLM-optimized descriptions. Three tools (getAvailableBuckets, getBucketObjects, getCsvObjects) have EMPTY input schemas ({}), violating the critical requirement that parameters must have type definitions and descriptions. Only readCsvObject has a proper schema with typed parameters and descriptions. Error handling is generic ('Error: {str(e)}') with no recovery guidance. No output schemas documented. No parameter constraints, enums, or validation rules visible.

• Expand all tool descriptions to 50-200 characters. Example: 'getAvailableBuckets: Lists all S3 buckets accessible with current AWS credentials. Returns bucket names as a list. Call this first to discover available buckets before listing objects.'
• Add input schemas to getAvailableBuckets, getBucketObjects, getCsvObjects. Even if no parameters are required, declare an empty object with proper JSON Schema. Better: add optional parameters like 'limit' (int, 1-100, default 20) and 'region' (string) to getBucketObjects.
• Document output schemas for all tools. Example for getAvailableBuckets: 'Returns: {type: array, items: {type: string}, description: List of bucket names}'. For readCsvObject: 'Returns: {type: string, description: CSV file contents as UTF-8 text}'.
• Replace generic error handling with actionable messages. Example: 'Failed to list buckets: {error}. Check AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are set and have s3:ListAllMyBuckets permission.' Use error classification (retryable vs user-fixable).
• Add pagination to getBucketObjects and getCsvObjects. Accept 'limit' (default 20, max 100) and 'offset' parameters. Return {buckets: [...], total: N, offset: M, limit: L} so agents can iterate without fetching all objects at once.