Skip to main content
Glama

delete_static_route

Destructive

Remove an existing static route by specifying its destination network CIDR. Use a two-phase confirm flow to delete the route safely from the router.

Instructions

Delete the static route to a network (CIDR). Two-phase.

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": {
      "destination": "<destination>"
    },
    "name": "delete_static_route"
  }
}

Input Schema

NameRequiredDescriptionDefault
confirmNo
destinationYes
expected_etagNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.7/5.0
Behavior2/5

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

The annotations already flag destructiveHint=true and readOnlyHint=false, so the danger is known; what the description should add is what 'two-phase' actually means (e.g., first call previews, second with confirm executes) and that the route is removed from the router config. It delivers neither, and the concurrency role of expected_etag is left entirely unexplained.

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

Conciseness3/5

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

Two short sentences, front-loaded and free of filler, but the brevity is under-specification rather than efficient packing. The dangling fragment 'Two-phase.' reads as a note that was never finished.

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

Completeness3/5

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

An output schema exists, so return values need not be described, but for a destructive mutation with zero parameter documentation the description is too thin: the meaning of each phase, the effect of expected_etag, and what happens on a mismatched etag are all missing.

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

Parameters2/5

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

Schema description coverage is 0%, so the three parameters — confirm, destination, expected_etag — have no documentation anywhere. The description only loosely implies destination ('to a network (CIDR)') and hints at a confirmation step without naming the confirm flag, leaving expected_etag completely opaque.

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

Purpose4/5

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

A specific verb plus resource ('Delete the static route to a network (CIDR)') makes the target unambiguous and easy to distinguish from list_static_routes and add_static_route. The sibling differentiation is implicit in the verb rather than stated, so it falls just short of a 5.

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

Usage Guidelines2/5

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

'Two-phase' gestures at a workflow but never says when to call it, what the first phase does, or when the second phase should follow. Nothing tells the agent whether a dry-run/preview is required before the real deletion.

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