Server exposes 30 tools with consistent verb_noun naming (get_, create_, update_, delete_, send_, list_, search_). All tools have descriptions (10-50 chars, baseline 194 chars). Input schemas are present with type definitions and parameter descriptions. However, descriptions are uniformly terse (e.g., 'Retrieve a user by ID', 'Send a message to a channel'), lacking context on WHEN to use each tool, dependencies, or recovery guidance. Output schemas are not documented in visible code. Error handling is minimal, no recovery guidance, no categorization of retryable vs fatal errors. Destructive operations (delete_message, delete_channel, delete_file) accept a 'confirm' boolean but lack explicit dry-run or pre-execution warnings in descriptions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) detected. Pagination is present (page, perPage) but no total count or next_cursor documented. Response field naming is consistent but not validated against parameter naming (e.g., tools accept 'userId' but return field names not visible).

• Expand tool descriptions to 100-200 chars. Include WHEN to use (e.g., 'Use get_user when you have a user ID; use search_users when you only have a partial name or email'), dependencies, and expected output structure.
• Add tool annotations: mark read-only tools with readOnlyHint=true, destructive tools with destructiveHint=true, and idempotent tools with idempotentHint=true. This enables LLMs to reason about retry safety.
• Document output schemas for all tools, especially paginated results. Include total_count, next_cursor, and per-item field names so LLMs can plan multi-page fetches and extract chaining IDs (e.g., channel_id for downstream send_message calls).
• Enhance error handling: categorize errors as retryable (network timeout, rate limit) vs user-fixable (invalid input, not found) vs fatal (permission denied). Return actionable recovery guidance, e.g., 'Channel not found. Available channels: discuss-project, project-updates.'
• For destructive operations, add explicit warnings in descriptions: 'This permanently deletes the message. Confirm with confirm=true.' Consider offering a dry-run mode or requiring a second confirmation parameter for high-risk operations.