mq-bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| bridge_statusA | Report every mq-bridge process this user is running on this machine — CLI jobs ( |
| describeA | Describe the endpoints and middlewares this build supports, the same data as |
| generate_cli_commandA | Generate a copyable, headless |
| list_routesA | List the routes started by this server, with their live connection health, total messages moved, current message rate, and achieved average rate. |
| publishA | Publish one message or a batch of messages to any endpoint. The endpoint is supplied inline in |
| route_messagesA | Return the most recent messages captured on a route, newest last. Only routes started with |
| route_statusA | Report the live status of one route (by |
| server_infoA | Report this MCP server's build identity: crate |
| start_routeA | Create and run a route that moves messages from its |
| stop_routeA | Stop a running route by |
| wait_routeA | Block until a route finishes, then report how it ended. Use this instead of polling |
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 11 tools
Most tools target clearly distinct actions (start/stop/wait routes, publish, describe, generate_cli_command). However list_routes, route_status, and bridge_status all overlap on reporting route health/throughput, differing mainly in scope (this server vs. all processes, one vs. all routes), which could cause misselection.
Conventions are mixed: verb_noun appears in list_routes, start_route, stop_route, wait_route, generate_cli_command, while noun_verb forms appear in route_status, route_messages, server_info, bridge_status, plus bare verbs like publish and describe. It's still readable but not a single predictable pattern.
11 tools is well-scoped for a message-bridge server: route lifecycle, message inspection, publishing, and introspection each earn their place without bloat or redundancy.
Route lifecycle is well covered (start, stop, wait, status, message capture, list, CLI generation) plus publish, describe, and identity info. Minor gaps exist, e.g. no explicit route teardown/purge beyond stop_route, but core workflows are complete.