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 links their own Telegram account once, through a self-service enrollment ceremony; from then on, every tool call their assistant makes runs in their own session and sees exactly what they see. 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, nothing shared. 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. That is the whole ceremony: 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. Tool calls execute in the enrolled person's session, so an assistant sees the chats its owner sees and nothing else, and per-user 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.
• 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.
• 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.