Loading ToolBench
MCP server for interacting with Telegram Bot API
The server provides 4 tools with basic Zod schemas and descriptions, but falls significantly short of production-grade quality. Tool naming is acceptable (verb-noun pattern), and all tools have descriptions. However, descriptions are uniformly terse (10-50 chars), parameters lack depth, and critical domain functionality is missing. The server acts as a thin wrapper around the Telegram Bot API without abstraction for common patterns like error recovery, pagination, or natural identifiers. For a Telegram integration, the tool set is incomplete, missing critical operations like get_chat_info, list_chats, delete_message, edit_message, handle_callback_queries, and file upload. Input validation is minimal. Output schemas are not documented. The get_updates tool's parameters schema is empty in the handler definition, though properly defined in the capabilities block, a discrepancy. Error handling provides no recovery guidance.
Forward messages of any kind
Get information about the bot
Get updates from the bot
Send a message to a chat
Descriptions are uniformly terse (10-50 characters). Pattern guidelines require 10-1024 chars with explicit context on WHAT, WHEN, and PREREQUISITES. Examples: 'Get information about the bot' (32 chars) omits when/how to use it; 'Send a message to a chat' (24 chars) doesn't explain parameters, optional vs required fields, or error cases.
Input parameters lack actionable descriptions. 'params' parameter in send_message and forward_message is described only as 'Additional parameters for the message' / 'Additional parameters for the forward message'. No guidance on what keys are valid, expected format, constraints, or relationship to Telegram API. LLMs cannot infer valid options.
No output schemas documented. Tool handlers return JSON.stringify(result) wrapped in text, but expected response structure is never specified. For send_message, what fields does Telegram return? For get_updates, is it a list or object? LLMs cannot plan downstream operations without knowing output shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
No error handling or recovery guidance. The server wraps raw Telegram API responses without validation or error classification. If sendMessage fails (blocked user, chat not found, invalid text), the raw API error is returned. No suggestion for retry strategy, user-fixable actions, or compensation paths.
Incomplete tool set for domain. Telegram bots typically need edit_message, delete_message, get_chat_info, list_chats, handle_callback_queries, and file/media upload. A production Telegram integration with only send_message, forward_message, get_updates, and get_bot_info is barely functional.
get_updates tool: handler definition has empty parameter schema (no 'params' key in server.tool call), while capabilities block defines full nested structure. Mismatch between declared schema and actual handler signature.
Sensitive data exposure risk: send_message and forward_message accept chatId as union[string, number]. No guidance on whether strings are usernames, which could collide or be enumerable. No validation that chatId is the agent's own resource, enabling potential unauthorized messaging to arbitrary chats if agent is compromised.
No pagination support in get_updates. Telegram's getUpdates can return many updates; no limit enforcement (max 100 from API) is exposed to the agent. Responses could be large enough to blow context windows without warning.