Loading ToolBench
MCP server for Telegram integration, enabling read and write operations on Telegram messages and chats
The server has well-structured tool definitions with clear naming (all action verbs: search_, get_, delete_, media_download, message_from_link) and comprehensive parameter schemas using Zod. However, several critical gaps prevent a higher score: (1) Output schemas are not formally documented, responses are JSON.stringify'd with bigint handling but no shape declarations; (2) Parameter descriptions lack actionable constraints, e.g., 'chatId' accepts both numeric and @username but the description doesn't state the format clearly; (3) Error handling is minimal, no recovery guidance or error categorization visible in code; (4) Tool descriptions are moderate length (75-150 chars) but lack WHEN and WHY context for LLM tool selection; (5) No validation of date ranges, chat permissions, or destructive operation safety documented. The Zod schemas provide type safety internally, but LLMs cannot parse .describe() calls, the rubric requires descriptions in the tool definition itself. Average per-tool score is 68.
Delete messages from a chat
Download media from a message
Get a specific message by link or by chat ID and message ID
List all available chats (users, groups, channels) with unread counts
Mark messages as read in a chat
Read message history from a chat, optionally filtered by date range
Search messages across chats by query text and optional date range
Send a file to a chat (photo, video, document, audio, or voice message)
No output schema documentation. Tool responses are JSON.stringify'd with bigint handling, but LLMs have no formal declaration of return fields (messages[], dialogs[], etc). This violates pattern:tool and prevents LLMs from planning downstream tool chains.
Parameter 'chatId' overloads numeric ID and @username into a single string param. Rubric requires separate params (chatId vs chatUsername) or explicit format guidance like '(numeric string or @username)'. Current description is ambiguous for LLM input generation.
Tool descriptions lack WHEN context. 'Get messages from a Telegram chat' does not explain when to call it vs search_messages, or that it supports unread filtering. LLMs need 50-200 char descriptions that state both WHAT and WHEN to call.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 12 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 62 | - | v1 |
Send a text message to a chat
No error guidance or recovery paths in code. If a chatId is invalid or user lacks permissions, the error response is likely a raw exception. Rubric requires 'User not found. Try search_dialogs() first.' style recovery guidance.
delete_messages is destructive (Risk: DESTRUCTIVE) but has no confirmation step or dry-run mode. Rubric pattern:confirmation-request suggests agents should preview deletions before executing. Current tool directly deletes without user approval.
Date range parameters (minDate, maxDate) lack validation constraints in descriptions. Rubric requires 'ISO 8601 format, e.g. 2024-01-15' and enforcement like parseIsoDate() is internal, LLMs don't know the format from description alone.
media_download parameter 'filename' is under-specified. No guidance on file path constraints (absolute vs relative, allowed chars, max length). Rubric requires actionable format guidance like '(relative path, 1-255 chars, no special chars)'.
Limit parameters (search_dialogs:limit=10, get_messages:limit=20, search_messages:limit=20) lack maximum bounds in schema. Rubric requires explicit min/max (e.g., 1-100) to prevent LLMs from requesting 10000 items.