Claude Bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLAUDE_BRIDGE_DB | No | Path to the SQLite database file. Overrides default ./claude-bridge.db. | |
| CLAUDE_BRIDGE_MAX_SSE | No | Maximum total concurrent SSE subscribers across all channels. Default '100'. | |
| CLAUDE_BRIDGE_AUDIT_LOG | No | Set to '1' to enable the audit log, which records security-relevant events. | |
| CLAUDE_BRIDGE_AUTH_TOKEN | No | Bearer token for HTTP authentication (opt-in). Set to enable auth on all endpoints except /status. | |
| CLAUDE_BRIDGE_RETENTION_DAYS | No | Number of days to retain messages. If set, a background sweep deletes older messages. (e.g., '30') | |
| CLAUDE_BRIDGE_SSE_REPLAY_LIMIT | No | Backlog rows replayed on SSE reconnect. Default '500'. | |
| CLAUDE_BRIDGE_MAX_SSE_PER_CHANNEL | No | Maximum subscribers per channel. Default '25'. | |
| CLAUDE_BRIDGE_RETENTION_SWEEP_SECONDS | No | Interval in seconds for the retention sweep background task. Default '3600'. |
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| bridge_sendA | Publish a durable message. Use content for legacy text/JSON, or message for the versioned structured envelope. Supply idempotency_key when a retry must not create a duplicate. |
| bridge_receiveA | Read durable messages. Pass since_id for an explicit cursor or consumer_id to resume from that consumer's last acknowledged message. |
| bridge_waitA | Wait efficiently for new messages after since_id or a durable consumer cursor. Use this instead of repeated polling; timeout is capped at 55 seconds. |
| bridge_ackA | Acknowledge a message for a named consumer. The durable cursor advances monotonically and is scoped to this channel. |
| bridge_channelsA | List all active channels and their message counts. |
| bridge_pingA | Check if the bridge server is alive and get a status summary. |
| bridge_clearA | Clear all messages from a specific channel. Useful for resetting state. |
| bridge_statusA | Get the last N messages from ALL channels at once. Useful for getting a full picture of what's happening across agents. |
| bridge_enqueueA | Add a task to a channel's work queue for a worker to claim. Give payload (structured JSON) or content (a string). Pass idempotency_key so a retried enqueue does not create a duplicate. |
| bridge_claimA | Atomically claim the next task from a channel's queue — no two workers ever get the same task. The claim holds a lease for lease_seconds; complete or fail it before the lease expires or it is requeued to another worker. Set wait_seconds to long-poll. |
| bridge_completeA | Mark a claimed task completed. Requires the lease_token returned by bridge_claim; a task whose lease expired and was reclaimed cannot be completed by the previous holder. |
| bridge_failA | Mark a claimed task failed. By default it is requeued (after retry_delay_seconds) until max_attempts is exhausted, then dead-lettered; set requeue=false to dead-letter immediately. Requires the lease_token from bridge_claim. |
| bridge_tasksB | Inspect a channel's task queue: per-status counts plus a recent task list. Read-only. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
The message and work-queue tools are mostly clearly separated, but a few pairs have fuzzy boundaries: bridge_receive/bridge_wait and bridge_send/bridge_enqueue could easily be selected incorrectly before reading the full descriptions. The lease-token and consumer-cursor mechanisms do, however, keep the intended workflows distinct.
All tools consistently share the bridge_ prefix and use lowercase_snake_case, making the family predictable and discoverable. However, the naming is not uniformly verb_noun: some tools are bare verbs (bridge_send, bridge_receive, bridge_fail), while others are nouns (bridge_channels, bridge_status, bridge_tasks).
Thirteen tools is reasonable for a combined durable-message bus and task-queue server, and each tool covers a distinct lifecycle step or inspection need. The count stays within the sweet spot and does not feel padded.
The overall surface is functionally strong: messaging covers send, consume, wait, acknowledge, clear, and inspect, while the queue side claims, completes, fails, and reviews tasks. Minor gaps remain around single-message deletion, task-queue clearing, and direct dead-letter replay, but they are likely workable via the existing inspect/enqueue operations.