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., "@OmniBridge MCP send a Discord alert that the nightly build failed"
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.
OmniBridge MCP is a lightweight, zero-latency Model Context Protocol server that gives AI agents (in Claude Desktop, Cursor, Windsurf, and Antigravity) direct, controlled access to send real-time alerts, operational notifications, and webhooks without exposing your primary API keys or relying on bloated middleware.
🚀 Zero Heavy Dependencies: Pure Python implementation with minimal footprint (httpx).
💬 Telegram Bot API: Send markdown-formatted alerts, silent notifications, and direct messages.
🎮 Discord Webhooks: Send rich embed cards with custom colors, titles, and timestamps.
🔌 Universal Compatibility: Works out of the box with any MCP-compliant client via standard IO (stdio).
🧪 Built-in CLI: Interactive test tool to verify credentials and channel delivery in seconds.
Related MCP server: mcp-telegram
git clone https://github.com/johannschiffer/omnibridge-mcp.git
cd omnibridge-mcp
pip install -r requirements.txtCreate a .env file or export variables in your shell:
# Telegram Bot Token (from @BotFather)
export TELEGRAM_BOT_TOKEN="123456789:ABCdefGhIJKlmNoPQRsTUVwxyZ"
# Discord Webhook URL (from Channel Settings -> Integrations -> Webhooks)
export DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/..."# Check channels configuration
python -m omnibridge.cli status
# Send a test alert to Discord
python -m omnibridge.cli test --channel discord --message "OmniBridge is live!"claude_desktop_config.json)On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%\Claude\claude_desktop_config.json
On Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"omnibridge": {
"command": "python",
"args": ["-m", "omnibridge.server"],
"cwd": "/path/to/omnibridge-mcp",
"env": {
"TELEGRAM_BOT_TOKEN": "your_bot_token_here",
"DISCORD_WEBHOOK_URL": "your_discord_webhook_url_here"
}
}
}
}.cursor/mcp.json){
"mcpServers": {
"omnibridge": {
"command": "python -m omnibridge.server",
"env": {
"TELEGRAM_BOT_TOKEN": "your_bot_token_here",
"DISCORD_WEBHOOK_URL": "your_discord_webhook_url_here"
}
}
}
}Tool | Parameters | Description |
|
| Sends Telegram notification with Markdown support |
|
| Sends Discord rich embed card |
| (none) | Returns connectivity and health of all channels |
Looking for production-grade reliability, business messaging, and fault tolerance?
Feature | Lite (Open Source) | Pro ($14.99 USD) |
Telegram Bot API | ✅ | ✅ |
Discord Webhooks | ✅ | ✅ |
WhatsApp Cloud API | ❌ | ✅ |
Slack Block Kit & Webhooks | ❌ | ✅ |
Matrix Protocol Rooms | ❌ | ✅ |
Custom Webhooks with HMAC | ❌ | ✅ |
Offline WAL Resilient Queue (Zero Message Loss) | ❌ | ✅ |
Adaptive Rate Limiting (Anti-ban protection) | ❌ | ✅ |
Production Docker & Compose | ❌ | ✅ |
Full Pytest Suite & Architecture PDF | ❌ | ✅ |
👉 Get OmniBridge Pro on Gumroad ($14.99)
MIT License. See LICENSE for details.
Check configuration and operational readiness of all connected notification channels.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. 'Check' implies a read-only inspection and 'all connected notification channels' establishes scope, but it does not explain what readiness means, whether any active testing occurs, or what kind of status information is returned.
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 definition is a single front-loaded sentence with no wasted words. It puts the scope and behavior in the most useful place immediately.
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?
This is a simple zero-parameter inspection tool, and the description gives enough context to invoke it correctly. Since there is no output schema, it could say more about the shape of the returned status, but the core purpose and scope are complete for invocation.
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 tool takes zero parameters, so the baseline is 4. No parameter semantics are needed, and the description correctly does not invent any inputs.
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 states a specific verb, 'Check,' and a specific resource, 'configuration and operational readiness of all connected notification channels.' It is clearly distinct from the sibling send_* tools, which perform outbound actions rather than status inspection.
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?
The tool's purpose implies it should be used for diagnostics or readiness checks, but the description does not explicitly say when to use it, when not to use it, or how it relates to the send_* alternatives. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a rich webhook notification or embed to a Discord channel.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Hex decimal color code (default: 3447003 / 0x3498db Blue, 0x2ecc71 Green, 0xe74c3c Red) | |
| title | No | Embed card title | |
| content | No | Optional raw text message | |
| description | No | Embed card detailed description or body | |
| webhook_url | No | Optional target Discord webhook URL if overriding default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden, yet it discloses nothing beyond the payload shape. It does not state whether this is a network write, what happens on webhook failure, whether a default webhook must be preconfigured, or any rate-limit/permission constraints.
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?
A single, front-loaded sentence with no filler; the verb and target channel lead the sentence. It is efficient, though arguably too terse given the tool's network-write nature.
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?
Five optional parameters, no annotations, and no output schema leave meaningful gaps: the description never notes that all parameters are optional, what a minimal call produces, or how a missing webhook_url is resolved. For a network-mutating tool with zero annotation support, this is under-specified.
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?
Schema description coverage is 100%, so all five parameters (color, title, content, description, webhook_url) are already documented in the schema, including the hex color values and the webhook override. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.
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?
States a specific verb and resource ("Send... to a Discord channel") and the payload type ("rich webhook notification or embed"). The Discord platform makes it distinguishable from send_telegram_message without opening a schema, though the text never explicitly contrasts the two siblings.
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?
No when-to-use guidance, no prerequisites, and no mention of when to prefer this over send_telegram_message or how it relates to get_channel_status. The only implied usage is 'to send Discord alerts,' which restates the name rather than guiding selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a real-time notification or message to a Telegram chat, user, or channel.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Message body to send (supports Markdown) | |
| chat_id | Yes | Telegram chat ID, user ID or @channelusername | |
| disable_notification | No | Send silently without sound alert (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and falls short. It claims 'real-time' delivery but says nothing about auth/permission requirements, rate limits, Markdown parsing caveats, failure behavior, or whether sending is idempotent or irreversible.
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?
A single front-loaded sentence with no filler, so every word earns its place. It is efficient, though arguably too sparse for a tool with delivery and permission implications.
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 side-effecting messaging tool with no annotations and no output schema, the definition is only minimally adequate. An agent learns what it sends but not the operational constraints, permission prerequisites, or delivery outcomes it needs to call it reliably.
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?
Schema description coverage is 100%, so the schema already documents chat_id, text, and disable_notification. The description adds no format details, ID examples, or channel-username nuances beyond what the schema provides, making the baseline of 3 correct.
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?
States a specific verb (send), resource (message/notification), and target (Telegram chat, user, or channel), so the action is unambiguous. The platform name implicitly separates it from send_discord_alert, but the description never acknowledges the sibling tools or contrasts behavior with them.
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?
No when-to-use, when-not-to-use, or alternative guidance is given. It does not mention prerequisites (bot membership, chat permissions) or address when to pick this over send_discord_alert. The 'notification or message' phrasing only loosely implies a use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_channel_statussend_discord_alertsend_telegram_messageScored across 3 tools
Each tool has a clearly distinct purpose: sending to Telegram, sending to Discord, and checking channel status. There is no overlap in the resource+action pairs, so an agent can select unambiguously.
All three follow a consistent snake_case verb_noun pattern (send_telegram_message, send_discord_alert, get_channel_status). The only minor deviation is the noun choice (message vs. alert) between the two send tools, but the structure remains predictable.
Three tools is a reasonable, well-scoped set for a notification bridge, with each tool earning its place. It is on the lean side, supporting only two channels plus a status check, but nothing is redundant.
Despite the 'OmniBridge' name implying broad multi-channel coverage, only Telegram and Discord are supported, and there is no tool to configure or add channels. Core send and status operations exist, but channel lifecycle and broader integrations are notable gaps.
Telegram bridge for your MCP-compatible agent. Bidirectional, no LLM in our stack.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
