telegram-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TELEGRAM_API_ID | Yes | API ID from my.telegram.org | |
| TELEGRAM_CHAT_ID | Yes | Numeric ID of the Telegram group (negative) | |
| TELEGRAM_API_HASH | Yes | API hash from my.telegram.org |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_latest_imageA | Return the most recent image posted in the configured Telegram group. Use this when the user says they have just sent a screenshot. It looks back over the last 200 messages for one carrying a photo and returns it together with the path to the full-resolution original — crop that file if you need to read fine print the downscaled copy blurred. Returns a sentence explaining what to fix if the group is unreachable, the session has expired, or no photo is in range. |
| wait_for_next_imageA | Blocks until a new image is posted to the group, then returns it. Use this when the user is about to send a screenshot. It notes the group's newest message when the call starts and returns the first photo after that, so it never hands back something you have already seen in this call. Args: timeout_seconds: how long to wait, clamped to 1-240 seconds. Waiting costs no tokens -- the process idles on a socket. If nothing arrives it returns a sentence saying so; call it again to keep waiting. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools are clearly distinct: get_latest_image retrieves a previously posted photo, while wait_for_next_image blocks for a new one. The use cases do not overlap in an ambiguous way.
Both names follow a verb-noun structure and clearly communicate function. The slight mix of 'get_' and 'wait_for_' is a minor deviation but still predictable.
Two tools is at the low end of a reasonable scope for a narrow image-receiving server. They cover the core need without bloat, but the server feels rather thin.
The pair covers the two key workflows: retrieving a previous screenshot and waiting for a new one. Missing features like explicit image search or sending could be useful, but they are not essential for the server's obvious intent.