Skip to main content
Glama
Sign In
mq-bridge

mq-bridge

by marcomq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Hybrid

stop_route

Destructive

Stops a running message copy route by name, sending a shutdown signal that ends a continuous route or abandons a drain without waiting for exit. Returns total messages moved plus average throughput.

Instructions

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

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "stop_route"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesThe route name, as returned by `start_route` or listed by `list_routes`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.0
    • changedInput schema / properties / name / description
      Previous value: -"The route name."New value: +"The route name, as returned by `start_route` or listed by `list_routes`."
  2. First observedv1.0.3

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true/readOnlyHint=false, and the description adds real context beyond them: it sends the shutdown signal, returns without waiting for exit, the route disappears from `list_routes`, and unread `route_messages` are discarded with their count returned. That is a concrete statement of what is lost. It stops short of permissions or failure modes, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the verb and resource, then usage routing, then side effects and return values. No filler; the dense final sentence carries only information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by describing the return payload (total messages moved, `average_messages_per_second` over `elapsed_s`, discarded-message count) plus asynchronous exit semantics. Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents `name` as returned by `start_route` or `list_routes`. The description only restates "by `name`," adding no format, uniqueness, or matching semantics beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb plus resource ("Stop a route started by this server") with an explicit scope qualifier and the keying parameter (`name`). It is clearly distinguishable from siblings like `wait_route`, `list_routes`, and `start_route`, which are named directly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ("end a continuous route or abandon a drain") and an explicit when-not with the correct alternative ("a route started with `exit_on_empty` stops by itself, so wait for it with `wait_route` instead"). This is the strongest form: condition plus named substitute.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools