Skip to main content
Glama
AIops-tools

fabric-aiops

by AIops-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

bind_network_to_template

Destructive

Bind a Meraki network to a configuration template, preview with dry_run, refuse unsafe VLAN overwrites, and capture prior binding for rollback.

Instructions

[WRITE][risk=high] Bind a network to a config template, capturing prior binding.

REFUSES when the network is unbound and carries local VLANs: the bind
overwrites them with the template's, unbinding does not put them back, and
this tool has no VLAN-create operation — so the undo would report success
having restored nothing.

Undo, precisely: rebind to the prior template when there was one (a faithful
restore — the configuration was template-derived either way); unbind when
the network was unbound with a VERIFIED empty VLAN set (restores the binding
state only, NOT firewall rules / group policies / static routes); and NO
undo at all when the prior VLAN set could not be read.

Pass dry_run=True to preview. The preview runs the same refusal check
(reads only), so it never previews green a bind the real call would refuse.

Args:
    network_id: Meraki network id to bind.
    template_id: Config template id to bind to.
    auto_bind: Auto-bind switch/AP profiles (Meraki autoBind flag).
    dry_run: If True, preview without binding.
    target: Target name from config; omit for the default.

Input Schema

NameRequiredDescriptionDefault
targetNo
dry_runNo
auto_bindNo
network_idYes
template_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With annotations only flagging destructive/non-idempotent, the description goes far beyond: it discloses the refusal trigger and why (undo would report success restoring nothing), the precise undo semantics per prior state, and the exact partial-restore scope (binding state only, NOT firewall rules / group policies / static routes). This is exactly the destructive-behavior detail an agent needs.

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?

Front-loaded with the risk tags, then refusal, undo, and preview semantics in priority order before the args list. Sentences are dense with multi-clause undo logic but every clause carries decision-relevant information; nothing is filler, though the density costs some readability.

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?

For a high-risk, no-output-schema mutation with 5 params, the description covers refusal, preview safety, and undo/partial-restore consequences thoroughly. It could still note what a successful response returns or any template-existence precondition, but the behavioral picture is essentially complete.

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 description coverage is 0%, so the description must carry all parameter meaning, and it documents all five with non-obvious detail for auto_bind (Meraki autoBind flag), dry_run, and target (omit for default). The two required IDs get only restated descriptions, but those are self-evident.

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+resource (bind a network to a config template) and immediately tags it [WRITE][risk=high], which is unambiguous. It is clearly distinguishable from the sibling unbind_network_from_template, and the refusal condition further scopes exactly what class of bind the tool will accept.

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?

Gives strong contextual guidance: it names the exact condition under which the call is refused (unbound network with local VLANs) and steers the agent to dry_run=True for previewing. It does not, however, explicitly route to related siblings (unbind_network_from_template, config_template_drift) as alternatives, leaving that to the agent.

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