Telegram Bot MCP server: send messages and manage a Telegram bot from MCP clients. Includes a launch-gate service for approval workflows and a Smithery-deployed send-only server.
Server has 7 tools with mixed quality. Two tools share the same name (send_telegram_message), creating ambiguity. Descriptions are present but vary in quality, some are detailed (request_launch_approval: 280 chars), others minimal (get_bot_info: 31 chars, below 20-char threshold). All tools have input schemas with types, but parameter descriptions are sparse or missing. Output schemas are not documented. Error handling exists in code but is not reflected in tool descriptions. No tool annotations (readOnlyHint/destructiveHint) despite clear WRITE/READ_ONLY risk classifications in metadata.
Broadcast a message to all known users. Note: user sessions live in this process's in-memory store. If the MCP server runs as a separate process from the bot (combined mode), it only sees users that talked to this process. Back the store with a shared database for cross-process broadcasts.
Get information about the bot.
Get information about a Telegram chat.
Ask the operator to approve a launch, showing the SIGNED scope. The message displays the engagement's signed company + scope hosts (from the verified record, not these arguments) with inline Approve / Cancel buttons, and flags any mismatch with what the routine requested. This only REQUESTS the gate; it authorizes nothing. The button callback carries the engagement id and a random nonce — never a token. Returns {"sent": true, "messageId": <id>} or {"sent": false, "error": <reason>}.
Send a plain notification to the operator's Telegram chat. Use for status pings (lead replied, run complete, needs attention). Sends to the configured operator chat only; it cannot target arbitrary chats.
Duplicate tool name 'send_telegram_message' in two files (mcp/tools.py and scripts/client.py) with different signatures. LLMs cannot disambiguate; one will be silently shadowed at registration.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields. E.g., get_chat_info returns JSON but structure is not declared in tool definition.
No tool annotations (readOnlyHint/destructiveHint) despite clear WRITE vs READ_ONLY risk classifications in metadata. Agents cannot infer safety/idempotency from tool definitions alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Send a message to a Telegram chat.
Send a message to the configured Telegram chat.
broadcast_message description warns about in-memory store limitations but does not document expected output format, pagination, or how many users will receive the message.