33 tools with consistent naming (verb_noun pattern) and basic descriptions, but critical gaps in schema completeness and parameter documentation. All tools have descriptions (10-50 chars, below the 50-200 char baseline for LLM optimization). Input schemas present but parameters lack type definitions in many cases, e.g., get_dialogs has 'limit' with type 'integer' but no min/max constraints; send_message has 'chat_id' accepting ['integer','string'] but no guidance on when to use which. No output schemas documented. Error handling absent, tools return raw API responses without recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification (READ_ONLY, WRITE, DESTRUCTIVE). Parameter descriptions are minimal (avg ~30 chars vs 72 char baseline). No pagination guidance for list tools (get_dialogs, get_chat_members, get_blocked_users). Security concern: no evidence of secret injection for Telegram credentials.

• Add output schemas to all tools. Document return fields, types, and which IDs/references downstream tools need. E.g., get_dialogs should return [{ dialog_id, chat_id, title, last_message_id }] so send_message can chain.
• Expand parameter descriptions to 50-100 chars with constraints. E.g., 'limit: Maximum number of dialogs (1-100, default 10)' instead of 'Maximum number of dialogs to retrieve (default: 10)'.
• Add tool annotations: mark get_* tools with readOnlyHint=true; mark delete_*, ban_*, block_* with destructiveHint=true; mark idempotent tools with idempotentHint=true.
• Document pagination for list tools: specify limit range (1-100), return total_count or next_cursor, and explain when to paginate. Cap default results at 20-50 items.
• Add error recovery guidance to tool descriptions. E.g., send_message: 'If chat_id is invalid, call search_users() or get_entity() first to resolve the ID.'

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

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