The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Telegram MCP listing page.
A Telegram integration for Claude, Cursor, and other MCP-compatible clients. It exposes Telegram account, chat, message, contact, media, folder, and admin operations through the Model Context Protocol using Telethon.
Basic Telegram MCP usage in Claude:

Asking Claude to analyze chat history and send a response:

Message sent successfully:

The server currently includes 80+ MCP tools grouped into these areas:
send_message, reply_to_message, and edit_message support classic formatting (parse_mode='md'/'html') and server-side rich formatting (parse_mode='rich'/'rich_markdown'/'rich_html' — full Markdown/HTML with tables, headings, formulas, and collapsible sections). Rich modes require Telegram Premium on the account; Premium is re-checked on every call, and without it nothing is sent — the tool returns a structured telegram_premium_required result so the agent can reformat with classic modes and retry. send_message, reply_to_message, and edit_message also accept format_date to render a date as a tappable chip.set_contact_alias teaches the server what you call someone, and every tool that takes a chat_id understands it from then on — send_message("андрей бекендер", ...) just works. A contact can carry any number of aliases, which is how tags work: save both андрей бекендер and бекендер for the same person and either resolves.
Only an exact saved wording ever sends. Similar wording (Андрею бекендеру for a saved андрей бекендер) is matched too, but only to suggest: the tool sends nothing and asks you to confirm the contact by name. This is deliberate — Лена/Леня and Иван/Иванов differ exactly as much as a case ending does, so a matcher confident enough to handle declensions is also confident enough to message the wrong person whenever the one you meant is not saved yet. Confirming saves that wording as its own alias, so each new phrasing costs one yes/no the first time and nothing ever again. Set TELEGRAM_CONTACT_FUZZY=0 to drop the suggestions too.
When a reference is unknown, resembles one contact, matches several, or points at a contact that no longer resolves, tools send nothing and return a structured instruction telling the agent exactly what to ask you, to save the answer with set_contact_alias, and to retry once. list_contact_aliases shows one row per person with all their aliases (use it to spot a wrong memory), delete_contact_alias forgets one, and repointing an alias at someone else requires replace=True. The save path itself refuses a target it would have to guess at: contacts are saved by @username, phone, numeric ID, or an alias already confirmed for them.
Aliases live in ${XDG_STATE_HOME:-~/.local/state}/telegram-mcp/aliases.json (owner-only, written atomically); TELEGRAM_ALIASES_FILE overrides the path, and a pre-existing aliases.json next to the code is still read as a fallback.
transcribe_voice(chat_id, message_id, engine=None) turns a voice message or video note into text. Two engines are available:
groq (default): uploads the recording to Groq's hosted whisper-large-v3-turbo. Leaves the server and costs a download+upload per call, but doesn't drop the recording's last few words the way native transcription does. Requires GROQ_API_KEY. Groq caps the size of a single upload, so a recording above TELEGRAM_TRANSCRIBE_GROQ_MAX_MB (default 25, the free-tier limit) is refused locally with a too_large error naming its size instead of being downloaded and rejected by the API. Raise the limit if your Groq tier allows bigger files, or transcribe that message with engine='telegram', which has no such cap.telegram: native Telegram Premium transcription (messages.TranscribeAudioRequest). Free and never leaves Telegram, but empirically drops the last speech segment in roughly 2 of 3 recordings and requires Telegram Premium on the account. Long recordings come back pending and are polled automatically.The engine is chosen per call via the engine argument, or otherwise defaults to TELEGRAM_TRANSCRIBE_ENGINE (groq or telegram). Results are cached by (chat_id, message_id, engine) in a local SQLite file so repeat reads and repeat listings never re-transcribe the same message. Concurrent requests for the same uncached recording are collapsed too: the second one waits for the first and returns its transcript, so a burst of callers costs one paid call, not one per caller. Every transcript is returned with a note marking it as a machine transcript, not a verbatim quote — treat it as a paraphrase, not exact wording.
get_history, get_messages, and list_messages fill in already-cached transcripts for voice messages instead of leaving the text empty, controlled by TELEGRAM_TRANSCRIBE:
off: transcription is disabled at runtime. The transcribe_voice tool stays registered and returns {"transcribed": false, "reason": "transcription_disabled"} instead of transcribing, and listings never show transcripts. Use TELEGRAM_EXPOSED_TOOLS to hide the tool itself.on-demand (default): listings show cached transcripts but never spend an API call fetching a new one.auto: listings also prefetch missing transcripts, bounded per call by TELEGRAM_TRANSCRIBE_MAX_VOICES/TELEGRAM_TRANSCRIBE_MAX_SECONDS (Groq isn't free, so this prefetch is budgeted rather than unbounded).The cache lives in TELEGRAM_TRANSCRIPT_CACHE_DIR (default data/transcripts), written as a 700 directory / 600 file since it holds personal-chat text in plaintext — see Docker for why this needs its own volume mount in a container.
wait_for_new_message, wait_for_settled_message), optionally for one chat only via chat_id — without it any unrelated conversation wakes the wait — or enable the opt-in incoming event feed for callback-style delivery (see below).All tool results that include Telegram user-controlled content are sanitized and, where practical, returned as structured JSON.
get_history, list_messages, search_messages, search_global,
get_message_context (including replied_message), get_pinned_messages, and
get_drafts include custom_emojis when the message contains custom emoji.
get_messages and get_scheduled_messages include the same metadata as a JSON
list in their text output. Ordinary messages keep their existing output.
Each entry contains the fallback emoji and its Telegram document ID as a string.
Repeated IDs appear once per message; different IDs remain separate even when
their fallback emoji looks identical. This is a list of reusable emoji variants,
not a map of their positions or a copy of all message formatting. Extraction uses
the original Telegram entities, including TextCustomEmoji nodes in block-format
rich_message content, and makes no additional API requests. Emoji
joiners and flag tag characters are preserved in the fallback text.
To reuse an entry, set parse_mode="html" in send_message, reply_to_message,
or edit_message, and insert <tg-emoji emoji-id="ID">EMOJI</tg-emoji> using its
id and emoji. HTML-escape the fallback and other literal text. For example,
the entry above becomes <tg-emoji emoji-id="5368324170671202286">🍷</tg-emoji>.
Telegram's account restrictions still apply to sending custom emoji.
Passing format_date to send_message, reply_to_message, or edit_message
renders a tappable date/time chip — the same entity Telegram's apps attach when
you type a recognizable date. Give the date text exactly as it appears in the
message: '13/09', '13/09/2026', or '13/09 17:00'. The chip opens
copy-date / add-to-calendar / reminder actions. Plain-text messages only —
omit parse_mode. For example, send_message(chat_id, "Lunch 13/09 13:00", format_date="13/09 13:00") sends a message whose date opens that menu.
By default, an agent waits for replies by calling wait_for_settled_message, which blocks up to the MCP tool timeout and must be re-called — that works everywhere (Codex, Cursor, etc.) and is unchanged.
Clients that can wake an agent on external output (Claude Code's persistent Monitor on tail -f) can switch to callback mode instead:
enable_incoming_feed (or set TELEGRAM_EVENT_FEED=1 in the environment to auto-enable). Each settled incoming burst is appended as one JSON line to ${XDG_STATE_HOME:-~/.local/state}/telegram-mcp/incoming_feed.jsonl, created owner-only (0600). Override the path with TELEGRAM_EVENT_FEED_FILE — an explicit path's directory must already exist. incoming_feed_status reports the effective path and a ready-to-use watch command.watch_command returned by the tool. Every new line re-invokes the agent with the burst summary; no blocking tool call is held open, and the chat stays free.disable_incoming_feed switches back; incoming_feed_status reports the current mode. While the feed is enabled it consumes settled bursts, so don't combine it with wait_for_settled_message. Feed lines contain user-generated name fields — treat them as untrusted data.
Do not install this server with
uvx telegram-mcp,uvx --from telegram-mcp, orpip install telegram-mcp. Thetelegram-mcpname on PyPI is currently owned by a different project and does not install this repository. PassingTELEGRAM_API_ID,TELEGRAM_API_HASH, orTELEGRAM_SESSION_STRINGto that package can expose Telegram account credentials to unrelated third-party code.
Follow the prompts. Save the generated session string securely.
For scripted setup or operational runbooks, choose the login method explicitly:
Without a flag, the generator keeps the interactive method prompt.
Copy the example file and fill in your real values:
Single-account setup:
By default, all Telegram MCP tools are exposed. If you want to prevent MCP
clients from sending messages or performing chat/account mutations, set
TELEGRAM_EXPOSED_TOOLS=read-only to expose only tools annotated with
readOnlyHint=True:
If read-only is too strict but all is too broad, append + and a
comma-separated list of tool names to also expose those specific write tools.
Every other write tool stays unregistered:
An unknown name in the allowlist aborts startup, so a typo cannot silently degrade into a narrower surface that looks like it worked.
This is an MCP tool-surface restriction, not a Telegram session sandbox or
reduced Telegram account permission. The Telegram session string still has its
normal authority inside the server process; read-only mode only prevents
non-read-only tools from being registered and exposed through MCP. Accepted
values are all (the default), read-only, and read-only+<tool>,<tool>.
Voice transcription (see Voice transcription above) is
off by default in the sense that no transcript is ever fetched unless you ask
for one — transcribe_voice is always available, and listings only pick up
already-cached transcripts. Enable prefetching or pick an engine explicitly:
engine=groq requires GROQ_API_KEY; engine=telegram requires Telegram
Premium on the account. TELEGRAM_TRANSCRIBE_MAX_VOICES (default 5) and
TELEGRAM_TRANSCRIBE_MAX_SECONDS (default 300) bound how much auto mode
prefetches per listing call; TELEGRAM_TRANSCRIPT_CACHE_DIR (default
data/transcripts) sets where the SQLite cache is written; TELEGRAM_TRANSCRIBE_GROQ_MAX_MB
(default 25) is the largest recording the groq engine will upload.
Telegram rate limits (FloodWaitError) are surfaced transparently to MCP clients and LLM agents with the exact wait duration and an explicit instruction not to retry immediately.
Use TELEGRAM_FLOOD_SLEEP_THRESHOLD to configure Telethon's internal silent-sleep threshold (default: 60 seconds). Set to 0 to disable silent sleeping and let the agent manage all backoff pacing:
Run the server locally:
For Claude Desktop or Cursor, point the MCP server at a cloned checkout of this project:
To expose only read-only tools in Claude Desktop or Cursor, add this to the
server env block:
Or keep read-only as the baseline and allow a few write tools on top:
Alternatively, install this repository directly from GitHub into a virtual environment using a specific release tag or commit:
Then configure your MCP client to run the installed console script:
Generate a session string without cloning the repo by sourcing this repository from GitHub explicitly:
The server speaks three MCP transports, selected with MCP_TRANSPORT:
| Value | Transport | Use case |
|---|---|---|
stdio | stdio (default) | One dedicated server process per MCP client |
http | streamable HTTP | One shared server for many clients (Claude Code, Codex, Cursor) |
sse | SSE (legacy HTTP) | Clients that only support the deprecated SSE transport |
For http and sse, the server binds MCP_HOST:MCP_PORT (default
127.0.0.1:8765); the streamable HTTP endpoint is /mcp, the SSE endpoint is
/sse.
If the server is reachable via a domain (e.g. behind a reverse proxy) rather
than only 127.0.0.1/localhost, set MCP_ALLOWED_HOSTS (and optionally
MCP_ALLOWED_ORIGINS) to enable DNS-rebinding protection and allow that Host
header, e.g. MCP_ALLOWED_HOSTS=mcp.example.com. Comma-separated; supports a
:* suffix to allow any port. Left unset, DNS-rebinding protection stays off
(the historical default).
Prefer http when more than one MCP client (or many coding-agent sessions)
will use the server: a single long-lived process holds one Telegram
connection, instead of every client spawning its own Telethon session —
Telegram throttles and may flag accounts that open many parallel sessions.
Register the shared server with clients:
For stdio-only clients, bridge with mcp-remote:
Use suffixed session variables to configure multiple Telegram accounts:
Labels are lowercased and become the account parameter value in tools.
account is optional.account.account is omitted.Example prompts:
To run several MCP clients against the same Telegram account at once (for
example the desktop app and a terminal CLI), give each client its own
authorized session. Telegram forbids one session (auth key) being used from two
IPs simultaneously, so on a VPN or dual-stack host two local clients can collide
with AuthKeyDuplicatedError. List several interchangeable session strings in
TELEGRAM_SESSION_STRINGS (separated by whitespace, comma or semicolon); each
process claims a free one via an advisory file lock, so clients deterministically
pick distinct sessions:
Generate extra sessions with uv run session_string_generator.py. The pool
takes precedence over TELEGRAM_SESSION_STRING for the default account. As an
extra safety net, a transient AuthKeyDuplicatedError at connect time (e.g.
during a VPN reconnect) is retried with backoff before the server gives up.
Size the pool to the number of clients you actually run concurrently. If every slot is already claimed, the server refuses to start with an explicit error rather than reusing a session another client holds — reuse would make Telegram permanently invalidate that session for both clients.
Before connecting, every server process takes a per-session lock (see the
AuthKeyDuplicatedError entry under Troubleshooting). By default it is
exclusive: a second instance for the same session waits briefly for the first
to exit and otherwise refuses to start. That lock can only see processes on the
same host, and Telegram's rule is about IPs, not processes: instances on one
host only collide when they reach Telegram from different IPs (dual-stack or
split-tunnel VPN hosts). When they all share one egress IP — a laptop running
several MCP clients — you can let them share the session instead of pooling:
Shared instances coexist with each other but never overlap an exclusive one (except on Windows, where a shared instance takes no lock). If you are not sure every client egresses from the same IP, use the pool.
These optional variables control how the client appears in Telegram under Settings > Devices (the active-sessions list):
If left unset, Telethon falls back to the host platform (for example arm64).
Because these values are re-sent on every connection, a long-running server
would otherwise overwrite the name chosen during login on each reconnect, so
set them to keep a stable, recognisable device name. The same variables are
read both by the session string generator (at login) and by the server (on
every connect), so set them in the same place as your other credentials.
Route Telegram traffic through a proxy by setting the TELEGRAM_PROXY_*
environment variables. Supported types are socks5, socks4, http, and
mtproxy.
SOCKS and HTTP proxies require the optional python-socks package:
Single-account configuration:
MTProxy:
Per-account overrides use the same _<LABEL> suffix as session variables and
take precedence over the unsuffixed defaults:
Misconfigured proxy settings (unknown type, missing host/port, invalid port,
missing MTProxy secret, or a missing python-socks package) cause the server
to fail fast at startup with a clear error message instead of silently
bypassing the proxy.
File-path tools are disabled until allowed roots are configured. This affects tools such as send_file, download_media, upload_file, send_voice, send_sticker, set_profile_photo, and edit_chat_photo.
Allowed roots can come from:
Security behavior:
file:// URIs. That breaks MCP SDK validation of list_roots;
the server recovers those absolute paths from the validation error so
file-path tools keep working.TELEGRAM_ALLOW_SERVER_ROOTS_FALLBACK=1 to fall back to the server CLI roots
in that case (opt-in; the default stays deny-all). The same opt-in also applies
when list_roots fails unexpectedly and no client paths could be recovered.<first_root>/downloads/.Run with allowed roots:
From an MCP client configuration, pass the same roots after main.py:
Build the image:
Run one long-lived container serving streamable HTTP, and point every MCP client at it (see Transports for client registration):
MCP_HOST=0.0.0.0 binds inside the container so the published port works;
-p 127.0.0.1:8765:8765 keeps the server reachable only from the local
machine — the endpoint is unauthenticated, so never publish it on a public
interface.
The bundled Compose file runs the same setup:
It also mounts ./transcript_cache into the container at
/app/data/transcripts so the voice-transcription SQLite cache (see
Voice transcription) survives a rebuild instead of
living in the container's writable layer. Create it once, owned by the
container's appuser (uid 1000), before starting:
Alternatively, an MCP client can spawn a dedicated container itself:
This is fine for a single client, but with several clients (or coding agents that spawn subagent sessions) each one starts its own container and its own Telegram session, which Telegram throttles; a client that exits uncleanly can also leave its container running. Prefer the shared server above in those setups.
For multiple accounts, pass variables such as TELEGRAM_SESSION_STRING_WORK and TELEGRAM_SESSION_STRING_PERSONAL.
The implementation is split into a small compatibility entrypoint and modular package code:
Run tests:
Run tests with coverage:
Coverage is configured in pyproject.toml with an 80% minimum gate for deterministic unit-testable core modules. GitHub Actions runs the same coverage command and uploads coverage.xml.
Run formatting checks:
.env, session strings, or .session files.telegram-mcp package name on PyPI is not controlled by this project.
Avoid PyPI-based telegram-mcp install commands unless ownership changes and
the package is verified.telegram-mcp distributions without a source checkout or direct git/file
install record. That guard cannot run when the unrelated PyPI package itself
is launched, so use clone-based or explicit git installs.TELEGRAM_PROXY_* is configured, Telegram traffic is routed through the
configured SOCKS/HTTP/MTProxy proxy instead.Telegram messages, display names, chat titles, and button labels are untrusted content. The server mitigates prompt-injection risk with:
sanitize_user_content(), sanitize_name(), and sanitize_dict() for control-character stripping, invisible-character stripping, and length limits.TELEGRAM_SESSION_STRING, TELEGRAM_SESSION_NAME, or suffixed multi-account variants.uv run session_string_generator.py --qr outside
the MCP server when you can scan from an existing Telegram app, or
uv run session_string_generator.py --phone when you need phone-code login.
Then set TELEGRAM_SESSION_STRING in .env. The MCP server does not perform
interactive phone-code login over stdio.TELEGRAM_API_ID and TELEGRAM_API_HASH at my.telegram.org/apps.AuthKeyDuplicatedError / "Another telegram-mcp process is already connected with this session": two processes tried to connect the same Telegram session at once (e.g. an MCP client restarted the connector before the old process exited), which Telegram rejects and can invalidate the session for both. The server now takes an exclusive lock per session before connecting; a second concurrent launch waits briefly (default 20s, override with TELEGRAM_LOCK_GRACE_SECONDS) for the first to release it and otherwise exits without ever calling connect(), instead of racing into a duplicate connection. Retry once only one instance is running — the refusal names the PID holding the lock. If several instances on this host are meant to share one session (all reaching Telegram from the same IP), set TELEGRAM_SESSION_LOCK=shared; see Sharing one session from one host.mcp_errors.log.uv syncuv run pre-commit install --hook-type pre-commit --hook-type pre-pushuv run pre-commit run --all-filesuv run pre-commit run --hook-stage pre-push --all-filesThis project is licensed under the Apache 2.0 License.
Maintained by @chigwell and @l1v0n1. PRs welcome.