EchoLoopMCP
This server lets an agent push messages to the user's phone and, when needed, pause to receive the user's next instruction or decision.
notify: Sends a plain-text message to the user via Telegram or Discord and returns immediately, without waiting for a reply. Useful for reporting task completion, build/test results, or other updates while the user is away from the terminal.
ask: Sends a message to the user and blocks until they reply, returning the reply text as the user's next instruction. Supports an optional custom timeout (default 240 seconds); earlier replies sent before the call are ignored.
Both tools accept only a message (and ask also accepts
timeout_seconds), and neither supports being run as a background or task-execution tool.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@EchoLoopMCPSend me a Telegram message when the task is done, then wait for my next instruction."
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.
EchoLoop
한국어 · English
Receive AI results on Telegram and reply to the notification to continue the same session.
When a result arrives, use Telegram’s Reply action on that notification to send your next instruction. EchoLoop uses the original notification to identify the AI session. With multiple sessions, reply to the notification for the intended session. A standalone message does not identify a session.
One Telegram bot can serve multiple AI sessions on the same computer. EchoLoop routes your reply using the original notification. It runs locally without a public server or inbound port.
Install
Requires Node.js 20+, npm, and Codex or Claude Code available on PATH. Windows, macOS, and Linux use the same commands.
From a checkout of this repository:
npm ci
npm pack
npm install -g ./echoloop-mcp-0.1.0.tgznpm pack builds the TypeScript output. Install the generated package globally once; other projects do not need a copy of the repository. For source development, use npm run build followed by npm link instead.
After a registry release is published, the equivalent installation is npm install -g echoloop-mcp. This repository does not itself establish that a registry release is available.
Installation prints a short setup guide. It does not prompt for credentials or change client settings. npm may hide lifecycle output; run echoloop setup directly if no guide appears. On Windows, use npm.cmd / echoloop.cmd if PowerShell blocks the npm-generated .ps1 launchers.
Related MCP server: Chat Human MCP Server
First setup
Run from the project you want to enable:
cd "path/to/your-project"
echoloop setupChoose English or 한국어. EchoLoop remembers the CLI language.
Open BotFather, send
/newbot, and choose a display name and a unique username ending inbot.Paste the API token at the hidden-input prompt. EchoLoop checks it with Telegram.
Open the generated bot link and press Start within two minutes. EchoLoop discovers and saves your private chat ID; you do not need to look it up.
EchoLoop installs integrations for detected clients, turns notifications ON for the current project, and displays command help. Restart those clients once.
Setup currently supports Telegram only. Discord onboarding and platform selection are in the backlog.
Existing credentials and language are reused on subsequent setup runs. Run setup again after installing another supported client or moving the package. Environment variables TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID can migrate an existing configuration on the first setup; saved credentials take precedence for CLI integrations.
Commands and everyday use
These are terminal commands, not messages you must prepend to every AI request.
Command | Action |
| Connect Telegram and install client hooks; enable this project |
| Enable a project; default is the current folder |
| Disable a project |
| Show Telegram connection and project settings without displaying the token |
| Switch CLI output to English |
| Switch CLI output to Korean |
| Show help; also |
Use it in another project without copying any files:
cd "path/to/another-project"
echoloop on
echoloop status
# Work normally in Codex or Claude Code.
echoloop offSubfolders inherit the nearest configured parent. An explicit OFF on a subfolder overrides its parent's ON. Projects without a matching setting are OFF. ON/OFF applies to subsequent hook invocations; it does not cancel a question already waiting for a reply.
Important: reply to the notification to continue working
Find the Telegram result notification for the session you want to continue.
Press and hold that message, then select Reply.
Type and send your next instruction, such as
Run the tests too and report the results.
Your instruction goes to the same AI session linked to that notification. No /echoloop prefix is needed. Even when notifications from several sessions share one chat, the original message identifies the destination, so always reply to the intended notification.
For a selection question, reply with an option number, comma-separated numbers for multiple choices, or a free-text instruction. An unanswered or expired question never counts as approval.
Client support and limits
Behavior | Codex | Claude Code |
Automatic completion notification | Notify hook | Stop hook |
Continue from a Telegram reply | Queues an instruction to the original task | Wakes the same active interactive session |
Ask the user to choose | MCP |
|
Native permission prompt | Remains local | PermissionRequest hook; explicit allow required |
Codex must support codex queue; setup checks availability. Codex's MCP instructions request remote questions when enabled, but do not intercept every native client dialog. Claude Code must support exec-form hooks and asyncRewake. Keep its interactive session open; noninteractive claude -p is not supported for this completion/reply loop. Completion replies wait up to about 24 hours; selection and permission hooks wait up to nine minutes, then fall back to local interaction.
Keep the computer awake and connected. EchoLoop does not install an OS boot service. Use one computer and one OS user per bot; another bot program or computer polling the same token can conflict. An existing Telegram webhook must be removed before pairing. Text replies are supported; Telegram messages longer than 4,096 characters are truncated.
Process structure
flowchart LR
A[Codex completion] --> B[Notify hook]
B --> T[Telegram bot]
T --> R[Shared receiver]
R --> Q[Codex queue: original task]
C[Claude completion or question] --> H[Claude hook waiting for reply]
H <--> T
H --> C
M[MCP ask / choose] <--> TTelegram polling state is shared across local processes using a file lock. Original message IDs select the destination session. Codex replies stay in a persistent inbox until queue submission succeeds. Queue submission and local acknowledgement are separate operations, so a crash between them can cause duplicate delivery.
Settings and troubleshooting
Settings are stored in the OS user's home directory: %USERPROFILE%/.echoloop/config.json on Windows, ~/.echoloop/config.json on macOS/Linux. This includes the language, bot token, chat ID, and project ON/OFF map. Credentials are stored locally, not encrypted. POSIX installations create the settings directory/file with permissions 700/600.
Setup updates Codex's ~/.codex/config.toml (or CODEX_HOME) and Claude's ~/.claude/settings.json (or CLAUDE_CONFIG_DIR). It preserves other settings, chains the previous Codex notify command, and registers EchoLoop's Codex MCP server if that name is unused. Existing custom MCP registrations are retained; adjust their paths yourself if necessary.
No chat ID: open the link from the current setup run and press Start, rather than sending a greeting. After timeout, rerun setup.
No notification: check
echoloop statusin the actual project folder, client availability on PATH, and restart the client after setup.No supported client found: install Codex or Claude Code and rerun setup; the saved Telegram pairing is retained.
Codex reply not delivered: inspect
~/.echoloop/codex-replies/status.json; recent send metadata is in~/.echoloop/codex-notify/last-sent.json.Reconfigure the bot: stop connected clients/receivers, remove only the
telegramentry from the settings JSON, then rerun setup. Keep project and language settings.
MCP and manual transports
Tool | Purpose |
| Check whether the current project is enabled |
| Send a message; does not attach a continuation session |
| Wait for a reply; default 240 seconds |
| Collect numbered or free-text answers |
Standalone MCP clients can launch echoloop-mcp over stdio. It reads saved Telegram credentials when channel environment variables are absent. Manual configuration supports TELEGRAM_BOT_TOKEN, TELEGRAM_CHAT_ID, ECHOLOOP_TIMEOUT, and ECHOLOOP_CHANNEL (telegram or discord). Existing Discord transports use DISCORD_BOT_TOKEN plus DISCORD_CHANNEL_ID, or DISCORD_WEBHOOK_URL for sending only. Discord does not yet route replies to multiple sessions.
Development and license
npm ci
npm test
npm pack --dry-runTests mock Telegram and launch real child processes to check pairing, settings, session routing, concurrent replies, timeouts, and client hooks. CI is configured for Windows/macOS/Linux with Node.js 20 and 22. A passing local test run does not establish live client compatibility on all three systems.
Released under Apache License 2.0.
Available Tools
2 toolsaskAsk the user and wait for a replyA
Push a message to the user's phone and then block until they reply, returning their reply text. Use it instead of ending your turn when the user is away from the terminal and you need their next instruction or a decision. Treat the returned text as the user's next instruction. Replies sent before this call are ignored.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | What to send. State what you did and what you need from the user, since they answer from a phone. | |
| timeout_seconds | No | How long to wait for a reply (default 240). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the blocking behavior, return value, and the handling of old replies. However, it does not specify what happens when the optional timeout_seconds elapses (e.g., returns null, errors, or continues waiting), which is a minor gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, providing necessary detail without redundancy. It efficiently conveys the core action, usage, and behavioral nuances in three sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description specifies the return value (reply text) and the blocking nature. It also gives usage context and a behavioral caveat, making it sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (message and timeout_seconds) are fully described in the schema, with clear explanations of their purpose and default. The description reinforces the meaning of 'message' and the timeout parameter is explained as the wait duration, so there is no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pushes a message, blocks for a reply, and returns the reply text. It differentiates from the sibling tool 'notify' by explicitly describing the blocking/reply behavior, so an agent can distinguish when to use 'ask' versus 'notify'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use it instead of ending the turn when the user is away and a decision/instruction is needed, and notes that pre-existing replies are ignored. This gives clear when-to-use and when-not-to-use guidance, fully covering usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
notifyNotify the userA
Push a message to the user's phone (Telegram or Discord) and return immediately without waiting for an answer. Use it when a long task finishes, when a build or test run ends, or to report something the user should see while away from the terminal.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The message to send. Plain text; keep it short enough to read on a phone. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having no annotations, the description discloses that the tool sends a push notification, returns immediately, and does not wait for a response. It could mention delivery reliability, but the key behavioral contract is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences: the first states purpose and behavior, the second gives usage cases. No redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter notification tool, the description covers what it does, how it behaves, when to use it, and what the message should look like. Nothing important is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already defines 'message' as a required string, and the description adds useful guidance: it should be plain text and short enough to read on a phone. This goes beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it pushes a message to the user's phone via Telegram or Discord and returns immediately. This distinguishes it from a tool like 'ask' by emphasizing that no answer is expected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use it: when a long task finishes, a build or test run ends, or to report something while away from the terminal. This gives concrete, actionable guidance for choosing the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
ask - First observed
notify
TDQS
Scored across 2 tools
The two tools, notify and ask, have clearly distinct purposes: notify is fire-and-forget, while ask blocks for a reply. There is no ambiguity in choosing between them.
Both tools use the same verb-based naming convention (notify, ask), which is concise and predictable. The names directly reflect their actions.
With only two tools, the server is minimal but perfectly scoped for its purpose—sending messages and requesting input. No redundant or missing tools are apparent.
For the domain of user notification and interaction, the two tools cover the fundamental operations: sending an unsolicited message and requesting a response. This is a complete set for the stated functionality.
Maintenance
Related MCP Connectors
Let your AI sessions talk to each other — messaging, tasks, sessions, and alerts
- call-meOAuthapp.getcallme
Calls your phone when an AI task finishes or is blocked — hear it, say what's next.
Let your AI agent notify you by email, Slack, Discord, or webhook. One tool: send_notification.
Zero-setup WhatsApp notifications + human-in-the-loop for AI agents — text 'join', send in 60s.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables bidirectional communication between AI agents and users through ntfy.sh push notifications, allowing agents to send messages and wait for user responses in asynchronous chat workflows.38 npm1MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to send messages to human users via chat platforms (currently Discord) and optionally wait for human responses, facilitating human-in-the-loop interactions.MIT
- FlicenseNot gradedqualityDmaintenanceEnables AI assistants to interact with users via Telegram to request decisions, approvals, or specific input through text and clickable buttons. This facilitates a human-in-the-loop workflow where the AI can pause for feedback or send status notifications during long-running tasks.3-
- AlicenseAqualityDmaintenanceEnables AI agents to request user decisions and send notifications via Discord when human intervention is required during autonomous tasks. It supports blocking questions with custom options, progress reporting, and persistent state for seamless remote task management.8MIT