Loading ToolBench
An MCP server that enables interaction with Telegram through Model Context Protocol, allowing sending messages and requesting user input via Telegram chat
Two tools are present with minimal definition quality. Both have action-verb names (send_message, request_user_input) but suffer from extremely sparse descriptions (8-12 words, well under the 10-character minimum usable length), missing parameter descriptions entirely, and incomplete schema documentation. The descriptions do not explain WHEN to use each tool, what preconditions exist (chat ID must be allowed?), or what the tool returns beyond a vague 'success' message. Parameter schemas lack descriptions, a critical gap per the rubric (100% of A+ tools have parameter descriptions). Error handling is absent from the tool definitions. No input validation guidance, no recovery hints, and no documentation of return structure. This server reads as a skeleton implementation rather than a production-ready tool.
Request user input through Telegram
Send a message through Telegram
Missing parameter descriptions on all parameters (chatId, message, prompt). Rubric requires every parameter to have a non-empty description explaining its role. Example: chatId has no explanation of what values are accepted, whether it must be in ALLOWED_CHAT_IDS, or what happens if an invalid ID is passed.
Tool descriptions are 8 - 12 words and provide minimal context. Rubric baseline for tool descriptions is 194 characters (p10=34, p90=392); these are 50 - 60 characters. Descriptions should state WHAT the tool does, WHEN to use it, and any prerequisites. Current descriptions ('Send a message through Telegram', 'Request user input through Telegram') lack state-change declaration, dependency hints, and action guidance for LLMs.
No return value documentation. Tools return 'content: [{type: text, text: Message sent successfully}]' but the schema does not document what fields the LLM should expect or how to interpret the response. LLMs cannot plan follow-up actions without knowing the response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
No error handling guidance in tool definitions. If a message send fails (invalid chat ID, network error, bot permissions), the LLM receives a raw error with no recovery hint. Rubric requires error responses to tell the LLM what to do next ('Try search_users() with a partial name').
request_user_input tool design is incomplete. The implementation maps pending requests by chatId and sets a 5-minute timeout, but the tool definition does not document: (1) how long the agent will wait for a response, (2) what happens on timeout, (3) how the agent retrieves the response. This is a multi-round-trip pattern that requires explicit documentation.
No mention of permission or authorization checks in tool descriptions. The code enforces ALLOWED_CHAT_IDS at the bot message handler level, but the send_message and request_user_input tools do not document this constraint. An LLM might try to send to any chatId without understanding the access control.