claude-bot-bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BOT_ID | No | Bot id used in send_message. | default |
| BOT_FROM | No | Value used as 'from' in the webhook payload. | Claude |
| BOT_NAME | No | Name shown by list_bots. Defaults to the bot id. | |
| BOT_REPLY_URL | No | Optional GET URL the bridge polls for bot replies. | |
| BOT_INBOX_HOST | No | Bind address for the local inbox server. | 127.0.0.1 |
| BOT_INBOX_PATH | No | POST path for the local inbox server. | /reply |
| BOT_INBOX_PORT | No | Set to open the local inbox server, including 0 for a free port. | |
| BOT_KEY_HEADER | No | Header name used to send BOT_WEBHOOK_KEY. | Authorization |
| BOT_KEY_PREFIX | No | Prefix prepended to BOT_WEBHOOK_KEY. Defaults to 'Bearer ' for Authorization, otherwise empty. | Bearer |
| BOT_TIMEOUT_MS | No | Webhook and poll timeout in milliseconds, from 1000 to 120000. | 30000 |
| DASHBOARD_PORT | No | Port for the local dashboard. Also enables the dashboard alongside stdio when set. | |
| MCP_HTTP_TOKEN | No | Token required when serving MCP over Streamable HTTP, including Docker mode. | |
| BOT_INBOX_TOKEN | No | Token required on inbox POSTs when set. | |
| BOT_WEBHOOK_KEY | No | Optional secret sent to the bot in the configured header. | |
| BOT_WEBHOOK_URL | Yes | Required. HTTP or HTTPS URL that the bridge POSTs messages to. | |
| BOT_ALLOWED_HOSTS | No | Comma-separated host allowlist for webhook and reply URLs. | |
| BOT_REPLY_SSE_URL | No | SSE URL hosted by the bot that the bridge connects to for replies. | |
| BOT_SIGNING_SECRET | No | Optional HMAC secret for signing outgoing webhook POSTs. | |
| BOT_INBOX_PUBLIC_URL | No | Public tunnel URL advertised to the bot for the inbox. | |
| CLAUDE_BOT_BRIDGE_BOTS | No | JSON object string defining additional bots, using the same fields as the config file. | |
| CLAUDE_BOT_BRIDGE_FROM | No | Alternative to BOT_FROM for the 'from' value in the webhook payload. | Claude |
| CLAUDE_BOT_BRIDGE_STATE | No | File used to persist reply state. | |
| BOT_INBOX_SIGNING_SECRET | No | Optional HMAC secret used by the inbox to verify signed POSTs. | |
| CLAUDE_BOT_BRIDGE_CONFIG | No | Path to the JSON config file. Can be used instead of env-only bot configuration. | |
| CLAUDE_BOT_BRIDGE_DEFAULT_BOT | No | Bot id used by send_message when bot is omitted. Defaults to the first bot. | |
| CLAUDE_BOT_BRIDGE_MAX_WAIT_MS | No | Upper bound for wait_for_reply in milliseconds, from 1000 to 600000. | 180000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| logging | {} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_botsA | List configured bots and reply channels. Secrets are not included. Call this when the bot id is unclear. |
| send_messageA | Send a message to a configured bot webhook. If the HTTP response contains a reply, it is returned here. Otherwise keep the threadId and call get_replies or wait_for_reply. Reuse threadId to continue the same conversation. |
| get_repliesA | Read replies already received, and poll each configured reply URL once. A reply URL without timestamps may still contain older text from before this conversation. Inbox posts are events that arrived at the bridge. |
| wait_for_replyA | Poll until a new reply arrives or the timeout hits. Default timeout is 120000 ms. Maximum is 180000 ms. Text already on a reply URL when the wait starts is ignored, so a stale file is not treated as a fresh answer; call get_replies to read it. Set includeExisting true to accept that current text. The bot cannot push into the chat while this tool is not running. |
| broadcast_messageA | Send the same message to several configured bots. Omit bots to send to every bot. One threadId is shared so the transcript stays together. |
| relay_conversationA | Run a multi-turn conversation between two configured bots. fromBot receives the opening message, then each reply is sent to the other bot. Stops at maxTurns (default 4, max 20) or when stop_relay is requested. The human can stop it between turns. |
| stop_relayA | Ask a running relay_conversation to stop after the current turn. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| bots | Bots this bridge can reach. Secrets are not included. |
| threads | Threads stored in this process. |
TDQS
Scored across 7 tools
Most tools have clearly distinct roles, but send_message/broadcast_message and get_replies/wait_for_reply overlap in adjacent areas. Descriptions explicitly differentiate them, so an agent can usually select correctly, though the reply-reading pair still requires care.
All tool names follow a consistent snake_case verb_noun pattern: list_bots, send_message, get_replies, broadcast_message, wait_for_reply, relay_conversation, stop_relay. No mixed conventions or vague verbs.
Seven tools are well-scoped for a bot messaging bridge: discovery, single-send, broadcast, reply reading, waiting, multi-turn relay, and stopping a relay. Each tool has a clear operational purpose.
The surface covers the core lifecycle: discover bots, send, broadcast, read replies, wait for replies, run multi-turn relays, and stop relays. Minor gaps exist around thread/history management and explicit relay status inspection, but these are workable around.