Skip to main content
Glama

unassign_instance_private_network

DestructiveIdempotent

Remove an instance from a specified Private Network by providing the Private Network ID and instance ID.

Instructions

Remove instance from a Private Network [DELETE /v1/private-networks/{privateNetworkId}/instances/{instanceId}] Remove a specific instance from a Private Network

Input Schema

NameRequiredDescriptionDefault
instanceIdYesThe identifier of the instance
x-trace-idNoIdentifier to trace group of requests.
privateNetworkIdYesThe identifier of the Private Network

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the risk profile is known. The description adds only the HTTP verb/path, which hints at the concrete effect (removing a membership link rather than deleting the instance), but says nothing about side effects such as losing connectivity to the network.

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?

The endpoint is front-loaded and useful, but the second sentence restates the first almost verbatim, so roughly half the text is redundant.

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?

With rich annotations and a fully documented schema, the description only needs to confirm effect and prerequisites. It conveys the detach semantics implicitly via the path but omits any note about what the instance loses or whether the network must exist, leaving a small gap for a destructive operation.

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%, so both IDs and the trace header are already documented. The path template loosely maps privateNetworkId and instanceId to URL segments but adds no format or constraint detail beyond the schema.

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?

Names a specific verb and resource ('Remove instance from a Private Network') and the endpoint template pins the exact scope. It is distinguishable from the inverse sibling assign_instance_private_network, though the description never names that sibling to make the pairing explicit.

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?

No when-to-use, prerequisites, or alternatives are stated. The agent must infer from the inverse tool name that assign_instance_private_network is the counterpart and that this is the detach operation.

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