Which integrations are available for this server?

Bridges AI assistants to Telegram bots, allowing them to send messages and photos, ask questions with interactive button choices, post live status updates via checklists, and automatically transcribe voice messages.

How do I use Telegram Bridge MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Telegram Bridge MCP ask me on Telegram if I want to proceed with the database update" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Telegram Bridge MCP

by electrified-cortex

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Telegram Bridge MCP

No Claw? No Problem.

Anthropic restricted Claude Code's native instance API — but this bridge doesn't care. It's a standard Model Context Protocol server. Any IDE, any model, any agent framework that speaks MCP connects out of the box — no proprietary lock-in, no webhooks, no public URL required.

Related MCP server: mcp-telegram

What Is This?

Telegram Bridge MCP connects AI assistants to Telegram bidirectionally. It lets any MCP-compatible client send messages, ask questions, receive voice replies, and run multiple concurrent agent sessions — all through a single bot you control.

Works with: VS Code (GitHub Copilot Chat), Claude Code, Cursor, Windsurf, Copilot CLI, and any MCP-compatible host.

Highlights

Feature	Description
Two-way messaging	Text, Markdown, files, voice notes
Interactive controls	Inline buttons, confirmations, questions
Super tools	Self-pinning checklists and emoji progress bars that update in-place
Voice	Auto-transcription (bundled Whisper ONNX, no ffmpeg) + TTS (local Kokoro, OpenAI, or bundled ONNX)
Multi-session	Multiple agents share one bot with isolated queues, token auth, and color identity
Animations	Cycling status frames while your agent works
Reminders	Scheduled synthetic events delivered via dequeue
Slash commands	Dynamic bot menu; commands arrive as structured events
No webhooks	Pure long-polling — no public URL, no reverse proxy

Quick Start

Tip: If your AI has web access, paste this to get started (requires web access):
Set me up: https://github.com/electrified-cortex/Telegram-Bridge-MCP

1. Clone and build

git clone https://github.com/electrified-cortex/Telegram-Bridge-MCP.git
cd Telegram-Bridge-MCP
pnpm install && pnpm build

2. Create a bot

Message @BotFather on Telegram:

/newbot

Copy the token it gives you.

3. Pair interactively

pnpm pair

The wizard prompts for your bot token and Telegram user ID, writes a .env file, and verifies connectivity.

4. Configure your MCP host

See docs/setup.md for per-client config snippets (VS Code, Claude Code, Cursor, Docker).

Transports

Transport	Entry Point	Best For
Streamable HTTP	`pnpm start -- --http`	Multiple clients sharing one server (recommended)
stdio	`node dist/index.js`	Single client, no persistent server
Launcher bridge	`node dist/launcher.js`	Auto-starts HTTP if needed, bridges stdio ↔ HTTP

Claude Code / Cursor / other MCP hosts

{
  "mcpServers": {
    "telegram": {
      "type": "streamable-http",
      "url": "http://127.0.0.1:3099/mcp"
    }
  }
}

VS Code (.vscode/mcp.json)

{
  "servers": {
    "telegram": {
      "type": "streamable-http",
      "url": "http://127.0.0.1:3099/mcp"
    }
  }
}

Claude Code / Cursor / other MCP hosts

{
  "mcpServers": {
    "telegram": {
      "command": "node",
      "args": ["/path/to/Telegram-Bridge-MCP/dist/index.js"],
      "env": {
        "BOT_TOKEN": "your-token",
        "ALLOWED_USER_ID": "your-user-id"
      }
    }
  }
}

VS Code (.vscode/mcp.json)

{
  "servers": {
    "telegram": {
      "type": "stdio",
      "command": "node",
      "args": ["/path/to/Telegram-Bridge-MCP/dist/index.js"],
      "env": {
        "BOT_TOKEN": "your-token",
        "ALLOWED_USER_ID": "your-user-id"
      }
    }
  }
}

Tools — The v7 API

Version 7 consolidates the entire API into 4 tools with type-based routing. Call help(topic?) at any time for interactive documentation discovery.

`send` — Outbound Messaging

All outbound operations flow through a single send call. The type parameter determines behavior.

Type	Description
`text`	Formatted Markdown text; pass `audio: "..."` to speak via TTS
`file`	Photo, document, video, audio, or voice note
`notification`	Status notification with severity: `info` · `success` · `warning` · `error`
`choice`	Message with inline buttons (non-blocking)
`question`	Blocking prompt — route with `ask`, `confirm`, or `choose`
`dm`	DM to another session (`target_sid` or `target` alias); `"direct"` accepted as alias
`append`	Append text to an existing message
`animation`	Start a cycling status animation
`checklist`	Create a self-pinning live checklist; requires `title`, accepts `steps` array of `{label, status}` objects
`progress`	Create an emoji progress bar (width configurable)

Update in-place with action(type: "checklist/update", message_id: ...) and action(type: "progress/update", message_id: ...) respectively. See docs/super-tools.md.

// Examples — token required for all session-scoped calls; session/start and most help topics work without a token
// token: 1234567 (required for all session-scoped calls)
send({ token: 1234567, type: "text", text: "Hello from your AI agent!" })
send({ token: 1234567, type: "notification", severity: "success", text: "Build passed." })
send({ token: 1234567, type: "question", ask: "Proceed with deployment?" })
send({ token: 1234567, type: "checklist", title: "Pipeline", steps: [{ label: "Design", status: "pending" }, { label: "Implement", status: "pending" }, { label: "Review", status: "pending" }, { label: "Deploy", status: "pending" }] })
send({ token: 1234567, type: "progress", title: "Processing files", percent: 40, subtext: "4 of 10 complete", width: 10 })

`dequeue` — Receive Inbound Events

Long-poll for the next inbound event: messages, button presses, voice notes, slash commands, reminders.

Note: token is the integer returned by action(type: "session/start").

dequeue({ token: 1234567 })              // default timeout — idles until event
dequeue({ token: 1234567, timeout: 0 }) // non-blocking drain (coordination gates)

`action` — Universal Dispatcher

RESTful path routing via type. Supports progressive discovery:

Omit type → list all categories
Pass a category → list sub-paths
Pass a full path → execute

Session

session/start · session/close · session/list · session/rename · session/idle

Profile

profile/voice · profile/topic · profile/save · profile/load · profile/import · profile/dequeue-default

Reminder

reminder/set · reminder/cancel · reminder/list

Animation

animation/default · animation/cancel

Message

message/edit · message/delete · message/pin · message/route · message/history · message/get

Chat

chat/info

Super Tools

checklist/update · progress/update

Confirm Presets

confirm/ok · confirm/ok-cancel · confirm/yn

Standalone

react · acknowledge · show-typing · commands/set · logging/toggle · transcribe · download

Governor-only

approve · shutdown · shutdown/warn · log/get · log/list · log/roll · log/delete · log/debug

`help` — Documentation Discovery

help()                    // list all topics
help({ topic: "send" })  // targeted reference for a specific tool or type

Multi-Session

Multiple agents can share one bot simultaneously without cross-talk.

session/start → token (integer) → pass on every session-scoped call

Token format: token = sid * 1_000_000 + pin — a single integer, returned by action(type: "session/start").

Capability	Description
Isolated queues	Per-session routing; no messages bleed between agents
Color identity	Outbound messages prefixed with color + name (e.g., `🟩 Worker 1`)
Governor model	First session is primary; additional sessions require operator approval via color-picker keyboard
DMs	Inter-session messaging via `send(type: "dm", target_sid: N, ...)` (alias: `"direct"`; `target_sid` alias: `target`)
Health monitoring	Unresponsive sessions trigger operator prompts to reroute or promote
Graceful teardown	Orphaned events rerouted; callback hooks replaced on close

See docs/multi-session-protocol.md for the full routing protocol.

Voice

Transcription (Inbound)

Voice messages are auto-transcribed before delivery. No external API, no ffmpeg required — the Whisper ONNX model is bundled.

WHISPER_MODEL=onnx-community/whisper-base   # default
WHISPER_CACHE_DIR=/path/to/cache            # optional

Text-to-Speech (Outbound)

Triggered by send(type: "text", audio: "..."). Provider is selected automatically:

Environment Variable	Provider
`TTS_HOST`	Any OpenAI-compatible `/v1/audio/speech` endpoint
`OPENAI_API_KEY`	api.openai.com
Neither set	Bundled ONNX model (zero config)

Kokoro (recommended local TTS)

High-quality local TTS with 25+ voices. No API key, no cost.

docker run -d --name kokoro -p 8880:8880 ghcr.io/hexgrad/kokoro-onnx-server:latest

TTS_HOST=http://localhost:8880
TTS_FORMAT=ogg
TTS_VOICE=af_heart

Send /voice in Telegram to browse and sample voices live.

Per-session voice override: action(type: "profile/voice") or /voice in Telegram.

MCP Resources

Five resources are available to any connected client — no tool call required:

URI	Contents
`telegram-bridge-mcp://agent-guide`	Behavioral guide for AI agents
`telegram-bridge-mcp://communication-guide`	Communication patterns and loop rules
`telegram-bridge-mcp://quick-reference`	Hard rules + compact tool table
`telegram-bridge-mcp://setup-guide`	Setup walkthrough
`telegram-bridge-mcp://formatting-guide`	Markdown / MarkdownV2 / HTML reference

Docker

ghcr.io/electrified-cortex/telegram-bridge-mcp:latest

Before running Docker: Create your .env file first by running pnpm pair on a machine with Node.js, or copy .env.example and fill it in manually.

Streamable HTTP (recommended) — run as a long-lived service:

docker run -d --name telegram-mcp \
  --env-file /absolute/path/to/.env \
  -e MCP_PORT=3099 \
  -p 3099:3099 \
  -v telegram-mcp-cache:/home/node/.cache \
  ghcr.io/electrified-cortex/telegram-bridge-mcp:latest

Connect MCP hosts to http://127.0.0.1:3099/mcp.

{
  "command": "docker",
  "args": [
    "run", "--rm", "-i",
    "--env-file", "/absolute/path/to/.env",
    "-v", "telegram-mcp-cache:/home/node/.cache",
    "ghcr.io/electrified-cortex/telegram-bridge-mcp:latest"
  ]
}

The cache volume persists Whisper and TTS model weights across container restarts.

Development

pnpm build      # Compile TypeScript
pnpm dev        # Watch mode
pnpm test       # Run tests
pnpm coverage   # Coverage report
pnpm pair       # Re-run pairing wizard

Agent Setup

To keep agents reliably in the Telegram dequeue loop, install the loop-guard hook for your host. The hook prevents agents from dropping out of the loop on idle or forced stop.

See docs/agent-setup.md for installation instructions for VS Code (GitHub Copilot Chat) and Claude Code.

Documentation

Doc	Contents
`docs/setup.md`	Full setup walkthrough with per-client config
`docs/multi-session-protocol.md`	Multi-session routing and governor model
`docs/super-tools.md`	Checklist and progress bar reference
`docs/agent-setup.md`	Loop-guard hooks for VS Code and Claude Code
`docs/migration-v5-to-v6.md`	v5 → v6 tool name mapping
`docs/git-index-safety.md`	Git index safety notes for multi-agent environments

License

AGPL-3.0-only

Available Tools

4 tools

actionA

Universal action dispatcher. Omit type to list all categories. Pass a category (e.g. session) to list sub-paths. Pass a full path (e.g. session/list) to execute. Use help(topic: 'action') for full documentation.

ParametersJSON Schema

Name	Required	Description	Default
`type`	No	Action path to dispatch (e.g. 'session/list', 'profile/voice'). Omit to list all categories. Pass a category name to list sub-paths.
`token`	No	Session token from action(type: 'session/start'). Token-optional paths: `session/start`, `session/reconnect`, and `session/list` (unauthenticated probe returns SIDs only). Omitting `type` (discovery/category listing) also requires no token. All other paths require a valid token.
`name`	No	session/start, session/reconnect: Human-friendly session name.
`color`	No	session/start: Preferred color square emoji hint. session/rename: Color to apply (must be a valid palette emoji).
`refresh`	No	session/start: When true, collapses first-boot, reconnect-of-live, and re-establish-after-drop into a single call. Pass alongside token to reclaim a live session (returns reused: true). When no session exists for the name, creates a new one (returns reused: false). Omit or false for strict first-boot semantics (current default). activity/file/create: When true, wipes any existing registration for this session (deletes file if TMCP-owned) then proceeds with a fresh create. Response includes replaced: true when a prior registration was wiped, replaced: false when there was none. Omit or false to preserve existing ALREADY_REGISTERED behavior.
`new_name`	No	session/rename: New alphanumeric name for the session.
`voice`	No	profile/voice: Voice name to set. Pass empty string to clear.
`speed`	No	profile/voice: TTS speed multiplier (0.25–4.0).
`message_id`	No	message/edit, message/delete, message/pin, react, message/get, checklist/update, progress/update, acknowledge: Target message ID.
`text`	No	message/edit: New text content. reminder/set: Reminder message text. animation/cancel: Replacement text. confirm/*: Prompt shown to user.
`keyboard`	No	message/edit: Inline keyboard rows. Pass null to remove all buttons.
`parse_mode`	No	message/edit, animation/cancel: Parse mode for text. 'Markdown' (default) — standard markdown auto-converted; 'MarkdownV2' — raw Telegram MarkdownV2 pass-through (special chars must be manually escaped); 'HTML' — HTML tags.	Markdown
`disable_notification`	No	message/pin: Pin without notifying members.
`unpin`	No	message/pin: If true, unpin instead of pin.
`emoji`	No	react: Emoji or semantic alias (e.g. 'thinking', 'done'). Omit to remove reaction.
`is_big`	No	react: Use big animation (permanent reactions only).
`temporary`	No	react: Auto-reverts reaction on next outbound action or timeout.
`restore_emoji`	No	react: Emoji/alias to revert to when temporary reaction expires.
`timeout_seconds`	No	react: Deadline before auto-restore fires. show-typing: Duration (1–300s, default 20). confirm/*: Seconds to wait for user response before timing out (default 600).
`ignore_pending`	No	confirm/*: Proceed even if there are unread pending updates (skips the pending check).
`callback_query_id`	No	acknowledge: ID from the callback_query update.
`show_alert`	No	acknowledge: Show as dialog alert instead of toast.
`url`	No	acknowledge: URL to open in the user's browser (for games).
`cache_time`	No	acknowledge: Seconds the result may be cached client-side.
`remove_keyboard`	No	acknowledge: Clear the inline keyboard on message_id after answering. Returns MISSING_MESSAGE_ID error if message_id is absent.
`target_sid`	No	message/route: Session ID to route the message to. session/rename: SID of session to rename (governor only).
`topic`	No	profile/topic: Short label to prepend to all outbound messages. Pass empty string to clear.
`key`	No	profile/save, profile/load: Profile key (bare name e.g. 'Overseer').
`voice_speed`	No	profile/import: TTS playback speed multiplier (0.25–4.0).
`animation_default`	No	profile/import: Default animation frame sequence.
`animation_presets`	No	profile/import: Named animation presets.
`reminders`	No	profile/import: Reminders to register for this session. Supports time, startup, last_sent, last_received, and schedule (cron-based) triggers.
`name_tag`	No	name-tag/set or profile/import: Custom name tag string. Replaces the auto-default (<color> <name>). No newlines. Max 64 chars.
`cron`	No	reminder/schedule: 5-field cron expression (minute hour day month weekday). Example: "0 9 * * *" fires at 9am daily. 6-field expressions are rejected.
`tz`	No	reminder/schedule: Timezone for the cron expression. Accepts IANA names (e.g. "America/New_York") or aliases: PST/PDT→America/Los_Angeles, MST/MDT→America/Denver, CST/CDT→America/Chicago, EST/EDT→America/New_York, UTC→UTC, GMT→Etc/GMT. Default: "UTC".
`trigger`	No	reminder/set: When to fire: 'time' (default), 'startup', 'last_sent' (fires after last send), or 'last_received' (fires after last inbound).
`mode`	No	reminder/set (last_received only): which inbound events reset the clock. "all" (default) = operator + DMs; "operator" = operator only.
`only_if_silent`	No	reminder/set (last_received only): when true, suppresses the reminder if the agent has already replied since the last qualifying inbound.
`delay_seconds`	No	reminder/set: Seconds to wait before reminder becomes active (default 0).
`recurring`	No	reminder/set: Re-arm after firing (default false).
`id`	No	reminder/set: Optional ID for dedup. reminder/cancel, reminder/disable, reminder/enable, reminder/sleep: Reminder ID to operate on.
`until`	No	reminder/sleep: ISO-8601 datetime after which the reminder resumes firing (e.g. "2026-06-01T09:00:00Z").
`timeout`	No	profile/dequeue-default: Default dequeue timeout in seconds (0–3600).
`ms`	No	profile/kick-lockout: Post-kick lockout window in milliseconds (1000–3600000). Omit to get current value. profile/kick-debounce (deprecated): Accepted range 1000–600000; use profile/kick-lockout instead.
`frames`	No	animation/default: Animation frames to set as default or register as preset.
`preset`	No	react: Named reaction preset (e.g. "processing"). animation/default: Named preset key for registration or recall.
`reset`	No	animation/default: Reset to built-in default animation.
`enabled`	No	logging/toggle: true to enable logging, false to disable.
`count`	No	message/history: Number of events to return (default 20, max 50).
`before_id`	No	message/history: Return events older than this event ID (page backwards).
`version`	No	message/get: Version (-1 = current, 0 = original, 1+ = edit history).
`filename`	No	log/get: Log filename to read. log/delete: Log filename to delete. Omit log/get to list files.
`category`	No	log/debug: Filter to a single debug category. Valid values: session, route, queue, cascade, dm, animation, tool, health.
`since`	No	log/debug: Only return entries with id > since (cursor-based pagination).
`enable`	No	log/debug: Toggle debug logging on/off.
`session_id`	No	log/trace: Filter to a specific session ID (governor-only for other sessions).
`tool`	No	log/trace: Filter trace entries to a specific tool name.
`since_ts`	No	log/trace: Only return trace entries at or after this ISO timestamp.
`cancel`	No	show-typing: If true, immediately stop the typing indicator.
`ticket`	No	approve: One-time approval ticket delivered to the governor via dequeue when the session requested approval.
`force`	No	shutdown: Bypass the pending-message safety guard. session/close: Force-close the last remaining session (bypasses the last-session guard).
`reason`	No	shutdown/warn: Optional reason for the restart.
`wait_seconds`	No	shutdown/warn: Optional estimated wait time in seconds before restart.
`file_id`	No	transcribe: Telegram file_id of voice message. download: Telegram file_id to download.
`file_name`	No	download: Suggested file name.
`mime_type`	No	download: MIME type hint from the message.
`title`	No	checklist/update: Bold heading for the status block.
`steps`	No	checklist/update: Ordered list of steps with their current statuses.
`percent`	No	progress/update: Progress percentage (0–100).
`subtext`	No	progress/update: Optional italicized detail line below the bar.
`width`	No	progress/update: Bar width in characters (default 10).
`commands`	No	commands/set: Slash commands to register. Pass [] to clear the menu.
`scope`	No	commands/set: "chat" scopes commands to active chat (default). "default" sets globally.
`file_path`	No	activity/file/create, activity/file/edit: Absolute path to the activity file. Omit to let TMCP generate one in data/activity/.
`child_token`	No	session/revoke-child: Dispatch token of the child session to revoke (the `token` field returned by session/spawn-child). Either the spawning parent OR the child itself may call this. Self-revocation is the preferred exit path: sub-agent emits EXIT_STATUS: then calls this with its own dispatch token.
`child_sid`	No	child/forward: SID of the target child session to forward a message to.
`message`	No	child/forward: Text message to inject into the child session's dequeue queue as an operator-forwarded message.
`event_type`	No	child/notify: Caller-defined event type (max 64 chars, alphanumeric + '/' + '_').
`payload`	No	child/notify: Optional JSON-serializable object delivered verbatim to the parent session.
`child_capability`	No	session/spawn-child: Capability level for the spawned child session (default: 'gather').

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries full burden. It explains the three modes and token requirements but does not disclose error handling, rate limits, side effects (e.g., destructive actions like shutdown), or return value structure. This limits transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (two sentences plus a reference) and front-loaded with the core concept. No wasted words, making it efficient for agent parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (80 parameters, no output schema, no annotations), the description provides sufficient context for basic usage but relies on 'help(topic: action)' for full documentation. It lacks details on output, error cases, and state changes, making it somewhat incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are already described. The description adds a high-level structure (modes) but does not elaborate on individual parameters beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the tool as a universal action dispatcher with three distinct modes: listing all categories (omit type), listing sub-paths (pass category), and executing actions (pass full path). This specificity differentiates it from sibling tools like dequeue, help, and send.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use each mode and references help(topic: 'action') for full documentation, providing a clear alternative. It also implicitly excludes other tools by focusing on action dispatching.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

dequeueA

Consume queued updates. Non-content events drain first, then up to one content event (text, media, voice) is appended. Returns: { updates, pending? } with data; { timed_out: true } on blocking-wait expiry (call again immediately); { pending? } for instant polls (max_wait: 0); { error: "session_closed", message } (isError: false) when the session queue is gone — stop looping. pending > 0 → call again. Omit max_wait to use session default (action(type: 'profile/dequeue-default'), fallback 300 s); max explicit: 300 s. Pass connection_token (from session/start) to enable duplicate-session detection — the bridge alerts the governor if two callers share the same identity. Call help(topic: 'dequeue') for details.

ParametersJSON Schema

Name	Required	Description
`max_wait`	No	Seconds to block when queue is empty. Omit to use your session default (fallback 300 s). Pass 0 for an instant non-blocking poll (drain loops). Values above the session default require force: true. Use action(type: 'profile/dequeue-default') to raise your default.
`timeout`	No	Deprecated alias for max_wait. Use max_wait instead.
`force`	No	Pass true to allow a one-time override when max_wait exceeds your current session default. Only applies to values ≤ 300 s (the hard cap on max_wait). To wait longer than 300 s by default, use action(type: 'profile/dequeue-default') instead.
`token`	No	Session token from action(type: 'session/start'). Required for all paths except session/start, session/reconnect, and unauthenticated `session/list` probe — pass your token on every other tool call.
`connection_token`	No	UUID returned by session/start. Pass on every dequeue call to enable duplicate-session detection. The bridge alerts the governor (without rejecting the call) if two agents share the same SID but present different connection tokens.
`response_format`	No	Response format. "compact" only suppresses `empty: true` (inferrable from the caller's use of `max_wait: 0`); `timed_out: true` is always emitted regardless of compact mode. Defaults to "default".

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the burden of behavioral disclosure. It details the order of event draining, all possible return shapes (updates, pending, timed_out, error), default wait behavior, hard cap, force override, and duplicate-session detection. No contradictions with annotations (none exist).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and return types, followed by detailed but necessary behavioral notes. It is dense with information yet remains clear. Minor redundancy (e.g., mentioning 'call again' multiple times) could be trimmed, but overall it is well-structured and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, no output schema, no annotations), the description covers all aspects: return types, error handling, default values, alternative actions, and optional features. It is comprehensive enough for an AI agent to understand and invoke the tool correctly without needing external references.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already has 100% coverage, the description adds significant context beyond the schema: the meaning of max_wait omission (session default), the fallback value, the force parameter's relationship to the default, the purpose of connection_token for duplicate detection, and the effect of response_format. This extra value justifies a score above the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Consume queued updates') and the resource ('queued updates'), with specific detail on event processing order (non-content events first, then up to one content event). It is easily distinguished from sibling tools like action, help, and send.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to call again (pending > 0), when to stop (session_closed error), and how to raise the default wait via action(type: 'profile/dequeue-default'). It also directs users to call help(topic: 'dequeue') for more details, covering both usage and alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

helpA

Discovery for this MCP server. No args -> overview. topic: 'index' -> topic menu. topic: 'guide' -> comms guide. topic: '<tool/topic>' -> detailed help.

ParametersJSON Schema

Name	Required	Description	Default
`topic`	No	Omit for overview. Pass 'index' for a categorized skill index. Pass 'guide' for full communication guide. Pass 'identity' for bot info + server version. Pass a tool name for detailed docs on that tool.
`token`	No	Session token — required only for topic: 'identity'. Omit for all other topics.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains the different behaviors based on topic, but does not explicitly state that the tool is read-only or has no side effects. The schema mentions an 'identity' topic not covered in the description, creating a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, using two sentences to convey all necessary information. It front-loads the purpose and uses bullet-like notation for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the help tool, the description covers most usage scenarios. It lacks mention of the 'identity' topic (present in schema), and does not describe return format, but for a help tool this is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides detailed descriptions for both parameters (topic and token) with 100% coverage. The description adds little beyond restating the options; it does not provide additional parameter semantics that the schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as 'Discovery for this MCP server' and specifies distinct behaviors for different inputs (no args, 'index', 'guide', tool name). This clearly distinguishes it from siblings (action, dequeue, send) which are likely operational tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use each variant (overview, index, guide, detailed help). While it does not explicitly mention when not to use it, the context makes it obvious that help is for information and not for performing actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sendA

Send a message as text, audio (TTS), or both. text only → text message with auto-split and Markdown. audio only → TTS voice note (spoken content). Both → voice note with text as caption (keep brief — topic context before playback). At least one of text or audio is required. For structured status, use notify. For file attachments, use send_file. For interactive prompts, use ask, choose, or confirm. Pass type: "" to route to a specific mode. Call with no args to see available types.

ParametersJSON Schema

Name	Required	Description	Default
`type`	No	Emission mode: "text" (default), "file", "notification", "choice", "dm", "append", "animation", "checklist", "progress", "question". Optional — omit to default to "text". The "text" type handles text-only, audio-only, and audio+text (voice note with caption) automatically.
`text`	No	Text message OR caption when audio is also provided. At least one of text/audio required.
`audio`	No	Spoken TTS content. When present, sends a voice note. Requires TTS to be configured.
`parse_mode`	No	For text content only. Default Markdown (auto-converted).	Markdown
`disable_notification`	No	Send silently (no sound/notification)
`reply_to`	No	Reply to this message ID
`async`	No	Applies to audio sends only. Defaults to async when audio is present — returns message_id_pending immediately; pass false to block until TTS completes and receive real message_id. Has no effect on non-audio sends.
`file`	No	Local path, HTTPS URL, or file_id (for type: "file")
`file_type`	No	Media type for file upload (default: auto-detect by extension)	auto
`caption`	No	File caption (for type: "file")
`title`	No	Heading (for type: "notification", "checklist", "progress"). For checklist/progress, `text` is accepted as an alias.
`severity`	No	Severity level for notifications	info
`message`	No	Alias for text in all modes. When provided and text is absent, resolves to text. Canonical parameter: 'text'.
`target_sid`	No	Target session ID (for type: "dm")
`target`	No	Alias for target_sid (for type: "dm"). Use either target or target_sid, not both.
`message_id`	No	Message ID to append to (for type: "append")
`separator`	No	Separator for append mode
`stream_id`	No	Active stream ID (for type: "stream/chunk" and "stream/flush")
`options`	No	Button options (for type: "choice"; also accepted as alias for "choose" in type: "question")
`choose`	No	Button options for type: "question" choose mode (alias: "options")
`columns`	No	Buttons per row (default 2)
`ignore_parity`	No	Bypass button emoji parity check
`preset`	No	Animation preset name
`frames`	No	Animation frame strings
`interval`	No	Frame interval ms
`timeout`	No	Animation auto-cleanup timeout in seconds (min 5, max 600, default 60). Pass a low value (e.g. 5) to auto-cancel after N seconds.
`persistent`	No	Keep animation running after messages
`allow_breaking_spaces`	No	Allow breaking spaces in animation
`notify_animation`	No	Notify on animation start
`priority`	No	Animation priority level
`steps`	No	Checklist steps (for type: "checklist")
`percent`	No	Progress percentage 0–100 (for type: "progress")
`width`	No	Progress bar width (default 10)
`subtext`	No	Progress bar subtext
`ask`	No	Free-text question for type: "question" ask mode
`confirm`	No	Confirmation text for type: "question" confirm mode
`timeout_seconds`	No	Timeout for interactive question types (seconds). Omit to use the server maximum (24 h).
`ignore_pending`	No	Skip pending-updates check for interactive types
`yes_text`	No	Affirmative button label (for confirm)	OK
`no_text`	No	Negative button label (for confirm)	Cancel
`yes_data`	No	Affirmative callback data	confirm_yes
`no_data`	No	Negative callback data	confirm_no
`yes_style`	No	Affirmative button color	primary
`no_style`	No	Negative button color
`topic`	No	Per-message topic override. When provided, uses this string as the topic header for THIS message only — overrides the profile-level topic without mutating it. Pass an empty string to suppress the topic for this one message.
`token`	No	Session token from action(type: 'session/start') (sid * 1_000_000 + suffix). Required for all send paths.
`response_format`	No	Response format. "compact" omits inferrable fields (split: true, split_count, timed_out: false, voice: true) to reduce token usage. Defaults to "default".

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behaviors. It explains auto-split, Markdown, TTS configuration requirement, and captioning for voice notes. However, it omits details like error handling, side effects (message sent), and permission requirements, leaving some gaps for a complex tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with core purpose and uses a clear arrow-format for modes. It is concise but covers essential guidance. A slightly more structured layout could improve readability, but currently it is efficient with no wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (47 params, no output schema, no annotations), the description covers main modes and sibling differentiation. It misses some context like default behaviors for complex interactions, but overall provides sufficient context for an AI agent to understand primary usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each parameter has a description in the schema. The tool description adds value for key params (text, audio) but does not elaborate on many others. Baseline of 3 is appropriate as the schema already handles parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's core function: sending messages as text, audio, or both. It details the three modes (text-only, audio-only, both) and distinguishes from sibling tools like notify, send_file, and interactive prompts, providing a specific verb+resource description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance on when to use this tool vs alternatives: 'For structured status, use notify. For file attachments, use send_file. For interactive prompts, use ask, choose, or confirm.' Also advises to call with no args to see available types, covering both when to use and how to explore.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation4/5

Most tools have distinct purposes: action dispatches commands, dequeue consumes updates, help provides documentation, send transmits messages. However, send overloads multiple sending modes (notify, send_file, etc.) which could cause confusion.

Naming Consistency2/5

Tool names are inconsistent: two verbs (dequeue, send), one noun (action), and one ambiguous (help). No consistent pattern like verb_noun or camelCase.

Tool Count3/5

Four tools is minimal but acceptable for a simple bridge. The scope seems intentionally limited, but more tools might be expected for a full-featured bridge.

Completeness3/5

Core send and receive operations are covered via send and dequeue. Session management is handled through action. However, missing editing, deleting, or searching messages leaves notable gaps.

Maintenance

ActivityActive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

telegram-mcp
io.github.Shreyas-Profile
Telegram bridge for your MCP-compatible agent. Bidirectional, no LLM in our stack.
Communication App Automation
2
gainium-mcp
io.gainium
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
Cryptocurrency Finance
22
Zapier
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297
Superforms B
co.superforms
Human-input bridge for AI agents with voice-first answer links, MCP tools, and HTTP APIs.
Agent Orchestration Speech Processing App Automation
112

Related MCP Servers

Telegram Bot MCP
Communication App Automation Autonomous Agents
SmartManoj
F
license
Not graded
quality
D
maintenance
Enables AI assistants to send messages and interact with Telegram chats through MCP tools, with support for user management, conversation history, and bot command handling.
Updated 10 months ago (2025-11-11 03:48 UTC)
1
mcp-telegram
Communication App Automation
Prgebish
A
license
Not graded
quality
D
maintenance
MCP server that connects AI assistants to your real Telegram account via User API (MTProto). Features default-deny ACL with per-chat permissions, message search, file sending, forwarding, media downloads, and rate limiting.
Updated 5 months ago (2026-04-08 11:49 UTC)
3
MIT
tgbot-mcp
Communication Autonomous Agents
TGLEEEE
A
license
A
quality
D
maintenance
A trusted, open-source MCP server for Telegram that enables LLMs to send messages, structured notifications with buttons, and wait for user replies using only bot token authentication.
Updated 6 months ago (2026-03-12 01:12 UTC)
4
MIT
MCP AgentChat
Communication App Automation
Lynricsy
A
license
Not graded
quality
D
maintenance
An MCP server enabling AI agents to interact with users via Telegram, supporting message and image sending, inline quick replies, and waiting for user responses.
Updated 7 months ago (2026-01-19 09:21 UTC)
13
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/electrified-cortex/Telegram-Bridge-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Telegram Bridge MCP

No Claw? No Problem.

What Is This?

Highlights

Quick Start

1. Clone and build

2. Create a bot

3. Pair interactively

4. Configure your MCP host

Transports

Tools — The v7 API

send — Outbound Messaging

dequeue — Receive Inbound Events

action — Universal Dispatcher

Session

Profile

Reminder

Animation

Message

Chat

Super Tools

Confirm Presets

Standalone

Governor-only

help — Documentation Discovery

Multi-Session

Voice

Transcription (Inbound)

Text-to-Speech (Outbound)

Kokoro (recommended local TTS)

MCP Resources

Docker

Development

Agent Setup

Documentation

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`send` — Outbound Messaging

`dequeue` — Receive Inbound Events

`action` — Universal Dispatcher

`help` — Documentation Discovery