Server has 6 tools with mixed quality. Strengths: all tools have descriptions (10-50 chars each); input schemas present with types and constraints (minLength, enums, defaults); clear naming (verb_noun pattern: s3_upload, dynamo_read, etc.); rate limiting and auth middleware. Weaknesses: descriptions are terse (avg 35 chars, below 72-char baseline); s3_upload and slack_notify lack visible descriptions in source; no output schemas documented; error handling returns only error codes + requestId, not recovery guidance; no tool annotations (readOnlyHint/destructiveHint); composition risk: annotation_status combines read+write+notify in one tool.

• Add descriptions and input schemas to s3_upload and slack_notify. Minimum 20 chars, ideally 50-200 chars per pattern:tool-description baseline.
• Document output schemas for all 6 tools. Include field names, types, and whether results are paginated. Example: s3_download returns {data: string (base64), contentType: string, size: number}.
• Enhance error messages with recovery guidance. Instead of {error: 'INVALID_PARAMS', requestId: '...'}, return {error: 'INVALID_PARAMS', requestId: '...', hint: 'id must be a non-empty string. Example: "task-123"'}.
• Split annotation_status into three tools: annotation_status_get (read-only), annotation_status_update (write), and optionally annotation_notify_slack (side-effect). Follows pattern:tool (single responsibility).
• Add tool annotations to tool definitions. Mark s3_upload, dynamo_write, slack_notify, annotation_status (update path) with destructiveHint: true. Mark s3_download, dynamo_read, annotation_status (read path) with readOnlyHint: true.

Inferred effective spec: <=2025-11-25.

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