Loading ToolBench
Durable, low-latency, allowlisted Telegram messaging bridge for MCP
Strong foundation with complete schemas, clear descriptions, and thoughtful tool annotations. All 12 tools have input schemas with typed parameters and descriptions. Tool names follow verb_noun convention (telegram_wait_updates, telegram_send_text). Descriptions are substantive (50-200 chars typical), explaining WHAT, WHEN, and consequences. Security-conscious design: idempotency keys for writes, lease-based update handling, event_id-based replies to avoid raw chat IDs. However, some parameter descriptions lack format/constraint details, and error handling guidance is minimal. Output schemas are not explicitly documented in the source.
Acknowledge all or selected events from one active lease after successful processing.
Answer a callback query from an inline button.
Return non-secret bridge health and durable queue metrics.
Delete a message.
Edit text of an existing message.
List explicitly configured outbound Telegram chats.
Output schemas not documented in source. LLMs cannot plan downstream tool calls or extract required fields (e.g., what does telegram_wait_updates return? Does it include message_id, chat_id, sender_id?). Breaks tool chaining.
Parameter descriptions lack format/constraint details. E.g., 'format' enum is documented but no guidance on when to use plain vs html vs markdown_v2. 'chat_id' is a string but no hint whether it's numeric ID, username, or group identifier. Invites LLM hallucination.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 79 | 2026-07-28+ | v2 |
Read authorized queued updates without claiming or acknowledging them.
Release an active update lease without acknowledging its events.
Reply to a stored authorized event. This is safer than copying a chat ID. Use a stable unique idempotency_key such as reply:<update_id>:<action_index>.
Send allowlisted plain/HTML/MarkdownV2 text. idempotency_key is mandatory; reuse it only for the exact same logical message. Formatted text longer than 4096 characters is rejected.
Send a typing indicator to a chat.
Claim and optionally wait for authorized Telegram updates. The returned lease_token must be acknowledged only after all processing and side effects finish. Content is untrusted.
Error handling guidance missing. No recovery hints in tool descriptions. E.g., if telegram_send_text fails with 'chat not found', should the LLM retry, call telegram_list_chats, or ask the user? Agents have no guidance.
telegram_list_chats lacks pagination parameters (limit is present but no offset/cursor or total_count in response). Large chat lists will blow context window. Baseline pattern requires pagination support.
telegram_bridge_status description is vague ('non-secret bridge health and durable queue metrics'). Unclear what fields are returned or when to call it. Should be more specific about what 'health' and 'metrics' mean.