Telebrief
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENAI_API_KEY | No | API key for the OpenAI AI provider (one of OpenAI, Anthropic, or Ollama) | |
| TELEGRAM_API_ID | Yes | Telegram App api_id obtained from my.telegram.org | |
| ANTHROPIC_API_KEY | No | API key for the Anthropic AI provider (one of OpenAI, Anthropic, or Ollama) | |
| TELEGRAM_API_HASH | Yes | Telegram App api_hash obtained from my.telegram.org | |
| TELEGRAM_BOT_TOKEN | Yes | Telegram bot token created via @BotFather |
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_digestA | Generate a fresh digest of the configured Telegram channels. Collects messages, summarizes them with AI and formats the result exactly as the digest delivered to Telegram. Takes roughly 20-90 seconds and costs AI provider tokens, so prefer get_last_digest when recent data is enough. Use hours=168 for a weekly digest. Args: hours: How many hours back to look, 1 to 168 (default 24) |
| get_last_digestA | Return the most recently generated digest without regenerating it. Instant and free. The digest may be stale — its generation time is included in the response, so check whether it is recent enough before relying on it. |
| get_channel_messagesA | Return the individual messages of one configured channel, unsummarized. Reads from Telebrief's message store when it holds the requested window, and falls back to a live Telegram read otherwise. Free and instant on the stored path; the fallback takes a few seconds. The response header says which was used. Args: channel: Channel name or id as configured under channels[*] in config.yaml hours: How many hours back to look, 1 to 168 (default 24) limit: Maximum messages to return, 1 to 500, newest kept (default 200) |
| search_messagesA | Find messages mentioning something across the configured Telegram channels. Uses Telegram's own search, so it covers each channel's full history, not only what digests collected, and it matches words, not substrings or regexes. No AI tokens spent. Makes one Telegram request per channel: pass channel when you know where to look. Channel filters from config.yaml are not applied. Args: query: Words to search for channel: Channel name or id as configured under channels[*]; all channels if omitted days: How many days back to search, 1 to 365 (default 30) limit: Maximum matches to return, 1 to 100, newest kept (default 30) |
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 4 tools
Each tool has a clearly distinct purpose, and the descriptions explicitly differentiate them: get_digest generates fresh summaries, get_last_digest returns cached output, search_messages searches across channels, and get_channel_messages returns raw per-channel messages. No overlap or ambiguity.
All tool names use a consistent snake_case verb_noun pattern (get_digest, search_messages, get_channel_messages, get_last_digest). The verbs are predictable and the names directly reflect their actions.
Four tools is a well-scoped set for a Telegram digest server. Each tool covers a distinct operation (fresh digest, cached digest, search, raw messages) and none feels redundant or missing for the core purpose.
The surface covers the main lifecycle: generating a digest, retrieving the latest digest, searching messages, and reading channel messages. A minor gap is the lack of a tool to list configured channels, which would help agents discover valid channel names without reading config.yaml.