Telegram MCP Server

Overview

I built a multiuser MCP server that connects AI assistants to Telegram — not as a bot with an identity of its own, but as the person using the assistant. Each employee builds a roster of the Telegram accounts and bots they control, each one named and one set as the default, through a self-service enrollment ceremony; from then on, every tool call their assistant makes runs through whichever of those accounts it names, in that account's own session, and sees exactly what it sees. It is live in production behind the corporate MCP Gateway.

The Problem

Plenty of real coordination happens in Telegram: decisions in group chats, requests in direct messages, announcements in channels. An assistant that cannot see any of it answers with half the context. The two obvious routes in are both wrong. A bot account sees only the chats it was explicitly added to and speaks as nobody in particular. Handing an assistant a person's raw session credentials — the other common pattern — is standing, unaudited access that no security review should pass. What a company needs is a third route: each person's assistant reads Telegram as that person, under that person's control, through infrastructure the company governs.

The Design

• Self-service enrollment, a roster of the person's own accounts. An employee signs in with their corporate account, scans a QR code from their own Telegram app, and, where their account requires it, enters a one-time second-factor password that is never persisted. The same self-service page lets them add a bot they control as a named account, from its own token rather than a scan, alongside any personal account, with one account set as the default; they manage that roster themselves, adding, renaming, relinking, or unlinking an account whenever they choose. No administrator hand-edits a configuration, no credential changes hands, and no account is ever shared.
• Every session is the caller's own, encrypted at rest. A tool call runs through whichever of the person's own accounts it names, their default account when none is named, in that account's own session, so an assistant sees exactly what that account sees and nothing else. Every account's session data is encrypted at rest.
• A sensitivity-tiered registry, read-only by default. Every tool declares its tier where it is registered. The default surface is a small set of read tools; write tools — send, edit, delete, forward, react, pin — exist only behind an explicit operator opt-in, and destructive operations demand a further confirmation before they run.
• Reading reaches the content of what a message carries. Beyond images, the read surface extracts the text of a PDF, a Word, Excel, or PowerPoint file, an OpenDocument file, an EPUB, or a plain-text file a message carries. Parsing happens in a sandboxed pass with no file-write permission of its own, time-capped and size-capped so an oversized or malformed attachment cannot run away with the call.
• A third permission axis, next to read, write, and destructive. An admin can grant a person the right to have their voice and round-video messages read back as text. The grant travels with the person across every account in their roster, not just one, usage is tracked per person, and the capability stays off until an admin turns it on.
• An audited settings page for admins. Operators manage these person-level grants, the voice and video transcription grant among them, from an admin-only page: every change is logged by who made it, when, and what the new value was. The page is built to grow, since a new setting is declared once and the page renders it, so later grants follow the same audited pattern.
• Write tools, and a bot's own inbox, follow the account too. Each write tool declares which kinds of account it can act through, a personal account, a linked bot, or both, and refuses cleanly when a call names a kind it does not support. A bot account in a person's roster also gets its own inbox of new and edited messages that an assistant can poll.
• Bulk identity disclosure is its own risk class. Listing a chat's whole membership is a different act from reading its messages, so the member-listing tool is excluded from the default set and never returns phone numbers even when enabled.
• A person's own session list, visible to their own assistant once allowed. The same person's assistant can ask which of their Telegram sessions are active, each shown with its device and an approximate location derived from its IP address. This stays off until an operator turns it on, the same way bulk membership listing does.
• Two doors, one identity. The server serves two independent access paths, and both resolve the caller to the same corporate identity without knowing about each other — hardened against the one mistake that could not be walked back: an account enrolled under the wrong person.
• Behind the gateway. It runs behind the corporate MCP Gateway, which owns sign-in and per-user, per-tool authorization — the same governed entrance the YouTrack MCP Server and the PeopleForce MCP Server stand behind, inheriting the security model instead of re-inventing it.

Engineering Discipline

The bar matches the sensitivity of what the server touches: a high coverage gate with zero-tolerance linting and typing on every change, structured logs that redact secrets recursively, outbound message text sanitized before it reaches a client, and a security pass over the whole surface — identity binding, session storage, tool exposure, logging — with every finding closed.

Status

Live in production behind the MCP Gateway, serving read access by default with the write surface behind an explicit opt-in. Its governance model deliberately rhymes with the PeopleForce MCP Server's: sensitivity declared at registration, exposure that can only narrow, fail-closed defaults.

My Role

I designed and built the server end to end — the enrollment ceremony, the session and identity model, the tiered tool registry, and the deployment — and shipped it to production behind the gateway. For the broader role context, see AI Product Manager at Spotware.