OmniBridge MCP is a multi-channel notification gateway that lets AI agents push alerts to chat platforms and inspect channel/queue health.
Send Telegram messages (Markdown, optional silent mode) to a chat ID, user, or @channel.
Send Discord webhook messages or rich embeds (title, description, color) with an optional per-call webhook override.
Check configuration and readiness of all connected notification channels via get_channel_status.
Per README, also supports Slack, WhatsApp Cloud API, Matrix, and HMAC-SHA256 signed custom webhooks, plus a persistent SQLite WAL retry queue with stats and flush tools.
Includes SSRF/prefix guards, rate limiting, and token redaction for safe outbound delivery.
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 Model Context Protocol (2024-11-05) notification and webhook gateway that lets AI agents send alerts across Telegram, Discord, Slack, WhatsApp Cloud API, Matrix, and HMAC-signed webhooks with per-channel rate limiting and a persistent SQLite WAL retry queue.
6 Outbound Channels: Telegram Bot API, Discord Webhooks, Slack Block Kit Webhooks, WhatsApp Cloud API, Matrix rooms, and HMAC-SHA256 custom webhooks.
Outbound SSRF & Prefix Guards: Enforces official https://discord.com/api/webhooks/ and https://hooks.slack.com/ prefixes even on per-call overrides, blocks loopback/RFC1918/link-local (169.254.169.254) webhook targets, URL-encodes Matrix room IDs, and redacts bot tokens from transport errors.
Persistent SQLite WAL Queue & Flush Worker: Rate-limited and transient 5xx/network failures are stored in ~/.omnibridge/queue.db (0600 permissions) and retried with exponential backoff via flush_queue or omnibridge-cli flush.
Related MCP server: mcp-telegram
uvxuvx omnibridge-mcp{
"mcpServers": {
"omnibridge-mcp": {
"command": "uvx",
"args": ["omnibridge-mcp"],
"env": {
"TELEGRAM_BOT_TOKEN": "your_bot_token_here",
"DISCORD_WEBHOOK_URL": "https://discord.com/api/webhooks/..."
}
}
}
}omnibridge-cli status
omnibridge-cli flush
omnibridge-cli test --channel discord --message "OmniBridge test alert"Tool | Parameters | Description |
|
| Send a Telegram notification with Markdown formatting |
|
| Send a Discord webhook message or rich embed |
|
| Send a WhatsApp Cloud API text message |
|
| Send a Slack Block Kit webhook notification |
|
| Send a Matrix room event ( |
|
| Deliver a JSON webhook signed with |
| (none) | Return pending, retrying, delivered, and failed counts in the SQLite WAL queue |
|
| Process due messages in the SQLite WAL retry queue |
| (none) | Return configuration status for all 6 channels and current queue counts |
Module | Description | Repository |
CrawlEngine MCP | HTTP web extraction to clean Markdown, JSON-LD parsing, and proxy rotation | |
BrowserBridge MCP | Lightweight HTTP/DOM session automation with SHA-256 action receipts | |
PgSafe MCP | Read-only PostgreSQL/SQLite query guard, PII masking, and dry-run mutations | |
OmniBridge MCP | Multi-channel notification bus with SQLite retry queue | |
SysFlow MCP | Linux systemd inspection, confined log tailing, and port auditing | |
FastMCP Forge | Zero-dependency FastMCP framework, CLI scaffolder, and SSE middleware |
If you find this project useful, you can support maintenance on Ko-fi.
MIT (c) 2026 Johann Schiffer
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
