MCP server for Telegram account access with OAuth 2.1 authentication and Telethon-based client management
Server has 5 tools with basic naming (verb_noun pattern) and descriptions present. All tools have input schemas with type definitions and parameter descriptions. However, descriptions are minimal (10-50 chars), lacking context on WHEN to use each tool and dependencies between them. Output schemas are not documented. Error handling is absent, no guidance on recovery, retryable vs fatal errors, or actionable error messages. The send_message tool (WRITE operation) lacks confirmation/dry-run pattern. Parameter descriptions are terse and lack format/constraint details. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications.
Get message history from a specific chat
Get information about the authenticated Telegram account
List all dialogs (chats, groups, channels) for the authenticated account
Search for messages in a chat
Send a message to a chat
Descriptions are too brief (10-50 chars). Lack context on WHEN to use each tool, dependencies, and prerequisites. LLMs cannot distinguish between list_dialogs and get_chat_history without richer descriptions.
Output schemas are not documented. LLMs cannot plan downstream calls or extract required fields (e.g., does list_dialogs return dialog_id, chat_id, or both?). Breaks tool chaining.
send_message (WRITE operation) lacks confirmation/dry-run pattern. Agents can accidentally send messages without verification. No error guidance on what happens if chat is invalid or user lacks permissions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | <=2025-11-25 | v2 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications (READ_ONLY vs WRITE). Clients cannot determine which tools are safe to retry or require user confirmation.
Parameter descriptions lack format/constraint details. 'chat' parameter accepts 'numeric id, username, phone number, or me' but no validation guidance. 'limit' has no min/max bounds. LLMs will pass invalid values.