Skip to main content
Glama
Sign In
pt-mcp

pt-mcp

by kiskander
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Delete a Device from the Network

delete_device_from_network
Destructive

Removes a device and all its network links from a Packet Tracer topology. Use only after explicit confirmation because deletion is irreversible and device configuration is lost.

Instructions

Delete a device and all of its links from the network.

CRITICAL: Destructive and irreversible (the device's configuration is lost). Always ask "Confirm deletion of [device]?" and wait for the user's "yes" before invoking this tool.

Examples:

  • "Delete R2"

  • "Remove the extra switch"

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": "delete_device_from_network"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesDevice display name as shown in Packet Tracer (e.g. 'Router0', 'PC1')

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true; the description goes well beyond by stating irreversibility, the specific loss (device configuration), the cascading link removal, and the required user confirmation gate. This is exactly the extra behavioral context the annotations cannot carry.

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?

The destructive warning is front-loaded and the examples are short and functional, so every section earns its place. The ALL-CAPS "CRITICAL" block is slightly heavy-handed for a description but is justified by irreversibility.

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?

An output schema exists, so return values need no explanation here. Combined with the disclosed irreversibility, cascade behavior, and confirmation protocol, an agent has everything needed to invoke this correctly and safely.

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% and the single `name` parameter is fully documented in the schema, so the baseline of 3 applies. The examples ("Delete R2", "Remove the extra switch") loosely illustrate the name format but add no semantics beyond the schema's own description of display names.

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+resource ("Delete a device") with an explicit scope qualifier: "and all of its links" — which distinguishes it from the sibling delete_link and from erase_device_configuration. An agent can tell exactly what this removes 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?

It prescribes a concrete pre-invocation protocol: ask "Confirm deletion of [device]?" and wait for "yes". Examples map user utterances to the tool. It stops short of naming when a different tool is the right choice (e.g. delete_link vs erase_device_configuration), so it is not a full when/when-not treatment.

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