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. 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) |
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 3 tools
get_digest and get_last_digest are the closest pair, but the descriptions clearly frame one as cached/free/possibly-stale and the other as fresh/slow/costly, which makes the tradeoff easy to reason about. get_channel_messages is clearly distinct as raw per-channel data versus the summarized whole-digest view.
All three tools use a consistent snake_case verb_noun pattern (get_last_digest, get_digest, get_channel_messages), with the get_ prefix and the digest/channel noun matching the returned resource. No mixed conventions or vague verbs.
Three tools is lean but defensible for a focused read-only digest service: cached read, fresh generation, and drill-down into source messages. It errs slightly thin, as there is no discovery or configuration surface, but nothing feels redundant.
The core lifecycle (view last digest, generate new digest, inspect raw messages) is covered, but get_channel_messages requires a channel name 'as configured' with no tool to list configured channels, creating a discoverability dead end. No way to check freshness windows or configuration also limits self-service.