Skip to main content
Glama

delete_notification_route

Destructive

Delete a notification route. Notifications it delivered stop reaching its destination (unless another route or an alert's own channel list still covers them), and notifications it excluded start flowing again - check the blast radius with preview_notification_routing first.

Input Schema

NameRequiredDescriptionDefault
route_idYesNotification route id (UUID) from list_notification_routes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the destructiveHint annotation by explaining the actual effects: delivered notifications stop reaching their destination, excluded ones resume flowing, and it discloses the exception (another route or an alert's own channel list). That caveat is exactly the kind of behavioral detail an agent needs before a destructive call.

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

Conciseness4/5

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

Two sentences, front-loaded with the action, then the effects and the precaution. Every clause earns its place; the parenthetical caveat is dense but necessary. Slightly heavy for the payoff, keeping it just under a 5.

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?

For a destructive, non-idempotent mutation with no output schema and one fully documented parameter, the description covers consequence, exception, and prerequisite. Nothing an agent needs in order to delete safely 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 description coverage is 100% for the single route_id parameter (UUID from list_notification_routes), so the schema already carries the meaning. The description adds nothing parameter-specific, which is the baseline 3 for a fully documented schema.

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 verb and resource ("Delete a notification route") and immediately characterizes the exact consequences, distinguishing it from create/update/list/test siblings. An agent knows precisely what the tool does without opening the schema.

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

Usage Guidelines4/5

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

Provides a concrete precondition: "check the blast radius with preview_notification_routing first," which names the alternative and the situation that selects it. Clear context, though it doesn't state when deletion is inappropriate or unnecessary.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources