Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
bridge_statusA

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.

describeA

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.

generate_cli_commandA

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_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 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).

route_messagesA

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.

route_statusA

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.

server_infoA

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.

start_routeA

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_routeA

Stop a running route by name. Returns the total messages it moved plus the rate it achieved (average_messages_per_second over elapsed_s).

wait_routeA

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.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 11 tools

Disambiguation4/5

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.

Naming Consistency3/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityActive
ResponsivenessWithin a week