Loading ToolBench
Telegram MCP Server - a Model Context Protocol server for interacting with Telegram
Server has 20 well-defined tools with consistent naming and basic descriptions, but falls short on schema completeness, parameter validation guidance, and error handling documentation. All tools follow verb_noun convention (auth_*, send_*, get_*, list_*, etc.), which is strong. Descriptions average ~80-100 chars, adequate but minimal for LLM reasoning. Input schemas are present for all tools and properly typed, but lack constraint guidance (ranges, enums, dependencies) in both schema and description. Output schemas are entirely undocumented, LLMs cannot infer what fields to expect from responses. No error recovery guidance, no confirmation patterns for destructive tools, and no indication of idempotency or retry safety. Composition is sound: tools are single-responsibility and chainable (e.g., auth_send_code → auth_submit_code → send_message). Field naming is consistent but sometimes ambiguous (generic 'chat' param accepts username or ID; should be 'chat_id_or_username' for clarity).
Logout from current Telegram session and clear stored credentials
Send authorization code to phone number. Returns code_hash needed for auth_submit_code.
Check Telegram authorization status
Complete authorization by submitting the code received via Telegram. If 2FA is enabled, include the password.
Create a new Telegram channel or supergroup
Delete a channel or supergroup
Delete a chat/dialog by username or ID (removes chat history)
Output schemas completely undocumented. No tool describes what fields it returns (e.g., get_messages, get_user, list_chats). LLMs cannot infer response structure and must guess what data to extract for downstream tool calls.
Destructive tools (delete_chat, delete_channel) lack confirmation/dry-run support and no error recovery guidance. Descriptions do not warn about irreversibility. No confirmation pattern documented.
Parameter descriptions lack constraint guidance. 'limit' parameters document default and max (e.g., 'limit up to 100') but do NOT state min value, behavior on invalid input, or what happens if omitted. 'chat' parameter accepts 'username or ID' but gives no hint on format (string?integer? both?string?). LLMs cannot self-validate.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Edit channel/group title and description
Forward a message from one chat to another
Get detailed information about a channel
Get all chats with their recent messages in one request. Use chats_limit (default 20, max 50) and messages_limit (default 3, max 10) to control output size.
Get chat history with pagination. Use limit (up to 1000) and offset_id for chunked loading. Returns next_offset for next chunk.
Get recent messages from a Telegram chat (up to 100)
Get user profile information by username or ID
Invite users to a channel or supergroup
Leave a channel or group by username or ID
Get list of Telegram dialogs/chats with unread counts
Reply to a specific message in a chat
Send a text message to a Telegram chat by username or ID
Set or update channel username
Generic parameter names (chat, channel, user) overload meaning. 'chat' accepts both username and ID; should be 'chat_id_or_username' for clarity. Same issue with 'channel', 'user'. LLMs will conflate string usernames with integer IDs.
No error handling or recovery guidance. Tools declare 'Risk' metadata but do not document what errors they return, what causes them, or how to recover. E.g., auth_submit_code can fail with invalid code, 2FA required, session expired, none documented.
No idempotency or retry safety documented. Agents will retry on network failures, tools like send_message and forward_message could silently duplicate messages if retried. No documentation of which tools are safe to retry.
Missing critical response fields for tool chaining. E.g., get_user does not document whether it returns user_id; if it does, is it an integer or string? How should invite_to_channel reference it? Missing chain metadata forces extra lookup calls.
Descriptions are minimal (50-80 chars). Pattern baseline is 194 chars average for A+ tools. Most tool descriptions lack context on WHEN to use them or dependencies. E.g., 'delete_chat' says nothing about permanence or what happens to message history.