Loading ToolBench
MCP server for sending Telegram messages with local and remote deployment options
Single tool 'telegram' has a basic schema with two required string parameters (chatId, message), both with minimal descriptions ('Chat ID is required', 'Message is required'). Descriptions are under 20 characters and lack context about when/why to use the tool, what it returns, or error recovery. No output schema documented. No error handling guidance. Tool name lacks action verb prefix (should be 'send_telegram_message'). No parameter validation rules, format constraints, or examples of valid input. The implementation shows structured output (messageId, chatId returned), but this is not documented in the tool definition itself.
Send a Telegram message.
Tool name 'telegram' lacks action verb prefix. Should be 'send_telegram_message' or 'send_message' to clearly signal the action to LLMs.
Parameter descriptions are trivial (under 20 chars: 'Chat ID is required', 'Message is required'). LLMs cannot infer format, constraints, or valid values. Should explain: chatId format (numeric string? Telegram user ID?), message length limits, character encoding, and when to use this tool vs alternatives.
No output schema documented. Tool returns {messageId, chatId} (visible in code), but this is not declared in the tool definition. LLMs cannot plan downstream calls or extract the right fields without knowing the response structure.
No error handling guidance. Tool can fail (invalid chatId, message too long, rate limit, auth failure), but no recovery hints provided. LLMs have no way to know if they should retry, ask the user, or try a different approach.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | 2025-06-18+ | v2 |
No parameter constraints documented. chatId and message are free-form strings with no length limits, format patterns, or validation rules stated. LLMs may pass invalid values (empty strings, extremely long messages, non-numeric IDs).