mqb · mq-bridge

Report every mq-bridge process this user is running on this machine — CLI jobs (`mqb copy`, headless configs), other MCP servers, the web UI and the desktop app — with their routes and consumers: connector types, running/healthy, `outcome`, current rate (`throughput`), `average_throughput`, total messages (`message_sequence`), `pending` and `started_at_ms`. Read-only; routes of other processes cannot be stopped from here. The entry whose `pid` equals `current_pid` is this server. Error text of other processes is redacted to `error`.

Describe the endpoints and middlewares this build supports, the same data as `mqb list --json` / `mqb describe <name> --json`: each endpoint's `endpoint` type (the JSON key `publish`/`start_route` take), URI form, example and typed `params` (also its config fields), and each middleware's params. Pass `name` to narrow it to one entry. Call it before writing `publisher` or `route` JSON for a connector you have not used yet.

Generate a copyable, headless `mqb` command for a route. Accepts the same route JSON and tuning overrides as `start_route`, but does not start anything. The command embeds canonical JSON with POSIX shell quoting so fields that have no compact copy-URI representation are preserved. Credential values are replaced by environment variable placeholders and the required variable names are returned separately.

List the routes started by this server, with their live connection health, total messages moved, current message rate, and achieved average rate. For one route's full status use `route_status`; for routes of other mq-bridge processes use `bridge_status`.

Publish one message or a batch of messages to any endpoint. The endpoint is supplied inline in `publisher` as JSON keyed by type (e.g. {"kafka": {"url": "...", "topic": "..."}}); this is independent of routes. Provide either `message` or `messages`; each message has a `payload` and optional `metadata` headers (e.g. `kind` for the message type, `correlation_id`). Returns the send outcome (an acknowledgement, or the endpoint's reply for request/reply endpoints). Use it for ad-hoc sends; to move data from a source endpoint, use `start_route`. Messages are written to the external system and cannot be recalled.

Return the most recent messages captured on a route, newest last. Only routes started with `capture_last` capture anything. Reads are destructive: each message is returned once, so repeated calls yield only what arrived since the last call.

Report the live status of one route (by `name`) or all routes: connection health, whether it has finished, the total number of messages it has moved, its current rate (`messages_per_second`), and the rate it achieved overall (`average_messages_per_second` over `elapsed_s`). Quote the average for a finished job: the current rate decays to ~0 once a route stops moving data. To wait for a job to finish, call `wait_route` once instead of polling this.

Report this MCP server's build identity: crate `version`, `git_hash` (with a `-dirty` suffix if the working tree had uncommitted changes at build time), build `profile` (debug/release), and `build_time`. Use it to confirm which binary is actually running before trusting throughput numbers.

Create and run a route that moves messages from its `input` (source) endpoint to its `output` (sink) endpoint, each keyed by connector type. Supports route options like `concurrency`, `batch_size`, and `exit_on_empty` (drain the source then exit; otherwise the route runs continuously until stopped). Either endpoint may carry a `middlewares` array — `retry`, `dlq`, `deduplication`, `limiter`, `transform`, `compression`, `encryption`, `pack`/`unpack`, `buffer`, `delay`, `timeout`, `weak_join`, `cookie_jar`, `metrics` — e.g. `{"sqlx": {...}, "middlewares": [{"retry": {"max_attempts": 3}}]}`. `concurrency`/`batch_size` may be given inside `route` or as top-level arguments — the top-level argument wins, and an unset value becomes the app default (4 / 1024, or the batch size the output endpoint's schema declares). Returns the route name for use with wait_route / route_status / stop_route, plus the tuning that took effect.

Stop a route started by this server, by `name`. Use it to end a continuous route or abandon a drain; a route started with `exit_on_empty` stops by itself, so wait for it with `wait_route` instead. Sends the shutdown signal and returns without waiting for the route to exit; the route is removed from `list_routes`, and messages captured for `route_messages` but not yet read are discarded (their count is returned). Returns the total messages it moved plus the rate it achieved (`average_messages_per_second` over `elapsed_s`).

Block until a route finishes, then report how it ended. Use this instead of polling `route_status` for a job started with `exit_on_empty`: it costs one tool call regardless of how long the job runs. Returns `finished` (false if `timeout_ms` elapsed first — the route is left running), the `outcome`, the total messages moved and the rate achieved. An `outcome` of `failed` carries the cause in `error`. Default timeout 60000 ms, maximum 18000000 ms.