Skip to main content
Glama
AIops-tools

fabric-aiops

remove_device_from_network

Remove devices from a network. Accepts a single serial or multiple serials, with dry-run preview. Device configuration is reset to defaults.

Instructions

[WRITE][risk=high] Remove device(s) from a network. Inverse: claim back.

The devices' current network is captured for undo, so the undo token is
genuinely applicable — but claiming a device back restores MEMBERSHIP, not
CONFIGURATION. A removed device is reset to an unconfigured state; it
returns with the network's defaults, without the name, tags, address, notes
or switch-port settings it carried before. Read those with device_status /
switch_ports first if you will need them back.

Pass dry_run=True to preview. Accepts a single ``serial`` or a ``serials``
list — the list form is how claim_devices_into_network's undo replays.

Args:
    network_id: Meraki network id the devices are bound to.
    serial: One device serial to remove (or use ``serials``).
    serials: Device serials to remove (mutually exclusive with ``serial``).
    dry_run: If True, preview without removing.
    target: Target name from config; omit for the default.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
serialNo
targetNo
dry_runNo
serialsNo
network_idYes
Behavior5/5

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

With no annotations, the description fully carries the burden of behavioral disclosure. It explicitly states that a removed device is reset to an unconfigured state, losing name/tags/address etc., and that undo restores membership but not configuration. This provides critical side-effect information for a high-risk write operation.

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 efficiently structured with a brief intro, key warnings, and a clear 'Args' section. Every sentence adds value, and there is no redundant or extraneous information.

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

Completeness4/5

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

The description covers the tool's purpose, behavioral implications, parameter usage, and prerequisites. However, it does not mention the return value or output format, which would provide full completeness given the absence of an output schema.

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

Parameters5/5

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

Given 0% schema description coverage, the description adds significant meaning to all five parameters: it explains the mutual exclusivity of 'serial' and 'serials', the purpose of 'dry_run' for preview, and 'target' as a config name. This compensates fully for the lack of schema descriptions.

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?

The description clearly states the verb 'Remove' and the resource 'device(s) from a network'. It also distinguishes itself from the sibling tool 'claim_devices_into_network' by noting it is the inverse. The purpose is specific and unambiguous.

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?

The description provides guidance on when to use this tool: it mentions using dry_run=True to preview and advises reading device_status/switch_ports first if needed later. It indirectly suggests alternatives by referencing the inverse operation and undo context, but does not explicitly state when not to use this tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AIops-tools/Fabric-AIops'

If you have feedback or need assistance with the MCP directory API, please join our Discord server