Skip to main content
Glama

LastPing

by dev.lastping

set_route

Destructive

Route a monitor's alerts for one event type to a set of destinations (channels). THIS REPLACES THE WHOLE SET for that event type — every destination you leave out stops receiving that event, including ones somebody else configured. CALL get_monitor FIRST and read its routes field: that is the monitor's current routing, and adding a destination means passing the existing ids PLUS the new one. Pass an empty channel_ids to remove all routing for the event. Destinations must be verified and enabled (email destinations must be confirmed first). Use list_destinations for IDs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
event_typeYesOne of eight: down (alert opened), recovery (alert cleared), fail (explicit failure ping), every-run (one notification per completed run, success or failure), success (fires only when a run completes successfully), started (fires when a run begins), blocked (an agent reported it is waiting on a human — fires immediately, the moment the ping arrives; this is separate from the 'blocked' INCIDENT that opens later only if the wait outlives blocked_timeout_s, see create_monitor/update_monitor), note (a free-form annotation ping — never itself opens or clears an incident). Prefer down/recovery/fail: they fire only on a state change. every-run, success, started, and note are not state changes and are bounded only by how often the monitor runs (or how often the agent chooses to send them), so they can be very chatty, and none of them is flap-damped. started is the chattiest of the bunch for CI-fed monitors: GitHub maps both the workflow_run 'requested' and 'in_progress' webhook events to a start signal, so a single CI run can emit more than one started event — this was observed in production, where a real run logged two starts seconds apart. every-run, success, started, and note share one separate per-channel rate cap (60/hour by default), so together they can no longer use up the budget that down/fail/recovery/blocked need — but a chatty route on any one of the four can silently suppress its own notifications, and its sibling informational types' notifications, once it exceeds that shared cap. blocked is deliberately NOT in that shared group even though it is agent-reported rather than system-derived: a blocked agent needs a human, so it draws on the protected down/fail/recovery budget instead, precisely so it cannot be starved by chatty every-run/success/started/note traffic. Route informational types to a low-stakes destination, not to the one that pages someone.
monitor_idYesMonitor (check) UUID.
channel_idsNoComma-separated destination (channel) UUIDs to notify. Empty string clears the route.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The description goes well beyond the destructiveHint/readOnlyHint annotations: it discloses that the action overwrites the entire route set, can remove routes configured by other people, requires verified/enabled destinations, and requires reading current state before mutating. This is exactly the kind of hidden destructive behavior that could surprise an agent.

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?

The description is dense but front-loaded: purpose, destructive warning, prerequisite, clearing behavior, constraints, and ID source each get exactly one sentence. There is no filler or repetition.

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?

The tool is destructive and has nuanced routing behavior; the description supplies prerequisites, side effects, clearing semantics, and validity constraints, and the schema completes the picture with exhaustive event-type semantics. Since there is no output schema, return-value documentation is unnecessary.

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

Parameters4/5

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

Schema coverage is 100% and already documents each parameter, so baseline is 3. The description adds meaningful operational meaning beyond the schema: channel_ids should include existing ids from get_monitor plus the new destination, IDs come from list_destinations, and destinations must be verified/enabled. This justifies a 4 rather than a 3.

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?

States a specific action ('Route a monitor's alerts for one event type') with a clear resource and object, and immediately differentiates itself by explaining the whole-set replacement semantics. This distinguishes set_route from sibling create/update destination tools and from get_monitor/list_destinations.

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?

Provides explicit operational guidance: CALL get_monitor FIRST and read routes, add new destinations by passing existing ids plus the new one, pass empty channel_ids to clear, and use list_destinations for IDs. It also warns that omitted destinations stop receiving events, including ones configured by others. This leaves little ambiguity about when and how to invoke it.

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

All LastPing toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation4/5

Tools are organized by clear resource domains, and the long descriptions carefully separate similar reads. The main ambiguity is create_monitor's upsert behavior overlapping with update_monitor, and list_incidents vs list_open_incidents could be confused from names alone.

Naming Consistency4/5

Almost every tool uses verb_noun snake_case with a consistent CRUD vocabulary like create_, list_, get_, update_, and delete_. Minor deviations exist: get_alert_templates is really a list operation, and discover_monitors_reconcile is an awkward verb-object-verb construction.

Tool Count2/5

Thirty-six tools is a heavy surface for an agent to navigate, even for a full monitoring platform. Most tools are individually purposeful, but the count exceeds the range where an agent can quickly scan and select, and the set would be easier to handle if split across domains.

Completeness4/5

Coverage is strong: monitors, destinations, agents, status pages, API keys, routes, alert templates, incidents, run history, discovery, and Terraform export all have read and lifecycle operations. Minor gaps remain, such as no explicit single-incident view and no acknowledgment/resolution action beyond notes, but core workflows have no dead ends.

Resources