Ultimate Telegram Bot API v10.2 MCP Server — 185 methods incl. rich messages, meta-mode, rate limiting, circuit breaker
The server registers 25 tools across three categories (meta-mode discovery tools, standard Telegram API methods, and utility tools). Strengths: explicit tool annotations present; descriptions provided for most tools; good use of categories and risk classifications. Weaknesses: Many tool descriptions lack actionable context about WHEN to use them vs. alternatives; parameter descriptions vary in specificity; output schemas are not explicitly documented in the visible code; no error recovery guidance in descriptions; some parameter naming inconsistencies (e.g., 'params' as generic object in telegram_call). The code shows well-structured Zod schema building and method organization, but the tool definitions themselves lack the specificity and LLM-optimization patterns recommended for A-grade servers.
Close the bot instance. Use before moving between local servers.
Delete the bot's command list for a given scope and language.
Get file info for downloading. Returns file_path — use https://api.telegram.org/file/bot<token>/<file_path> to download.
Get basic information about the bot (id, name, username, etc).
Get the bot's current command list.
Get default admin rights.
Generic 'params' parameter in telegram_call lacks actionable guidance. Tool accepts an unstructured object, forcing the LLM to construct JSON without schema hints. Should either register all 185 methods explicitly (current 'standard mode' strategy) or provide richer discovery/validation.
Many tool descriptions are too brief (30-50 chars) and lack context on WHEN to use them or what the return value looks like. E.g., 'Get the bot's name for a given language.' does not explain the response structure or when this differs from get_me.
Output schemas are not documented in the tool definitions. The code builds Zod schemas internally but does not expose the return structure to the LLM. An LLM cannot plan downstream calls or extract required fields (e.g., chat_id from sendMessage response) without documented response types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Get the bot's description.
Get the bot's name for a given language.
Get the bot's short description.
Query the TRAIL content log. Check what content was posted, failed, or skipped across pipelines.
Get a user's profile audio tracks (v9.4).
Get a user's profile photos.
Log out from the cloud Bot API server. Use before moving to a local server.
Write an entry to the TRAIL content log. Use to explicitly record content actions.
Remove the bot's profile photo (v9.4).
Set the bot's command list shown in the menu.
Set default admin rights requested when adding bot to groups/channels.
Set the bot's description (shown in empty chat).
Set the bot's name.
Set the bot's profile photo (v9.4).
Set the bot's short description (shown on profile page).
Call any Telegram Bot API method. Use telegram_find first to discover method names and required parameters.
Download a file from Telegram by file_id or from any public URL.
Search Telegram Bot API methods by keyword. Returns matching methods with their parameters. Use this to discover available methods before calling them.
Ask what shape a structured Telegram parameter must have BEFORE sending. Call this whenever you are about to build a rich post, an album, a keyboard, or a poll and are not certain of the exact syntax. Topics: rich_message, caption, media, reply_markup, poll, checklist, paid_media, business_connection, live_photo, reply_parameters, link_preview_options. Omit the topic to list them all. For a post longer than a 1024-character caption, ask for 'rich_message'.
No error recovery guidance in tool descriptions. When a tool fails (e.g., 'User not found', 'Invalid parameter'), the error response should guide the LLM to a recovery action. Current descriptions do not anticipate or explain failure modes.
Parameter descriptions in some tools lack format/constraint details. E.g., 'Language code' does not specify ISO 639-1 format, length, or valid examples. 'BotCommandScope' refers to an external type without explaining structure.
Pagination is missing from list-like tools. E.g., get_user_profile_photos accepts offset/limit but no documentation of total count or next_cursor. Large result sets could exhaust context windows.
Tool composition risk: telegram_find and telegram_call together provide a workaround for the full 185-method API, but the meta-mode discovery is clunky. LLMs may not reliably use telegram_find before telegram_call, leading to failed calls with opaque 'unknown method' errors.
TRAIL tools (get_trail, mark_trail) use custom domain concepts (content_id format 'source:type:id', action enums) that are not self-documenting. Descriptions should include examples and explain the intended use case (audit logging for a content pipeline).