Loading ToolBench
MCP server for communicating with users through Telegram bots
This server has significant definition quality gaps. All four tools have basic schemas and descriptions, but lack the depth, clarity, and error guidance expected of production-grade tools. Naming is reasonable but descriptions are terse (10-67 chars, well below the 194-char baseline for A+ tools). No parameter constraints (enums, ranges), no output schemas documented, and error handling is minimal. The zip_project tool mixes responsibilities (create archive + respect .gitignore) and lacks parameter validation. The ask_user tool has no timeout guidance, risking indefinite hangs. Security concerns exist: ask_user returns untrusted user input directly; sendFile does not validate the filePath parameter, exposing potential path traversal. Overall, these are basic tool stubs rather than production-hardened tools.
Ask the user a question via Telegram and wait for their response
Send a notification message to the user via Telegram
Send a file to the user via Telegram
Create a zip archive of the current project, respecting .gitignore rules
ask_user has no timeout or retry guidance. The tool waits indefinitely for user input with no documented timeout, risking indefinite agent hangs. Error messages do not guide recovery (e.g., 'Bot not initialized' gives no path forward).
send_file does not validate filePath input. No check for path traversal, file existence, size limits, or readable format. An LLM could be tricked into passing '../../../etc/passwd' or a non-existent path, causing cryptic failures.
zip_project combines two responsibilities: creating a zip archive AND parsing .gitignore rules. This violates single-responsibility principle. Additionally, the 'directory' parameter lacks validation (no check for existence, permissions, or size) and has no description of default behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 17 | - | v1 |
No output schemas documented for any tool. ask_user returns a string, but its type and constraints are not formalized. notify_user, send_file, and zip_project return void with no documented error structure. LLMs cannot reliably parse responses or plan downstream calls.
Descriptions are too terse (10 - 67 chars vs. 194-char baseline for A+ tools). ask_user: 'Ask the user a question via Telegram and wait for their response' (67 chars) lacks guidance on when to use it, expected response format, or timeout behavior. notify_user: 'Send a notification message to the user via Telegram' (51 chars) does not distinguish it from ask_user. send_file: 'Send a file to the user via Telegram' (36 chars) does not explain file size limits or supported formats.
ask_user has no idempotency or retry semantics. If an agent retries due to transient failure, it will ask the user twice, causing confusion. No mention of idempotentHint or confirmation step.
No parameter constraints or enums. All parameters are free-form strings. The 'directory' param in zip_project could be any string; no min/max length, no regex pattern, no validation hint. The 'question' and 'message' params lack length limits, allowing LLMs to pass unbounded strings that exceed Telegram's 4096-char message limit.
Error messages are generic and non-actionable. 'Bot not initialized' (notify_user, ask_user, send_file) tells the LLM nothing, it cannot retry or self-correct. No guidance on root cause (missing TELEGRAM_TOKEN env var?) or recovery steps.
ask_user response is untrusted user input with no sanitization. If the LLM echoes the response to another user or logs it, malicious input could cause injection attacks or trigger unintended behavior downstream.
zip_project description does not explain the output file location or format. Users do not know where the zip archive is created or what it is named. No mention of success criteria or error conditions.