Skip to main content
Glama

Attach private network port

attach_private_network_port
Idempotent

Attach an eligible owned service to a private network port with automatic IPv4 allocation or a fixed address; restart only after approval.

Instructions

Attach an eligible existing owned service to a private network with port_intent_ready=true; omit ipv4 for automatic allocation or pass a fixed usable address. Check list_network_attachment_candidates for this network and service first, including pagination and attachment_mode. Set restart=true only after the user approves a required restart. An accepted attach is pending: it returns the port's reserve operation (queued with private_port_apply_pending; reserve, activate and detach take 13-81 s through the host) - poll it with get_networking_operation on in_progress, read its activation_operation_id once the activation that finishes the attachment exists, and verify the final port and service attachment state. Honor this endpoint's own refusal and reason_code. Requires explicit networking:read for reads or networking:manage for changes; full/read defaults do not grant networking. The backend enforces ownership, feature availability and service 2FA locks. Read current capabilities and owned resource state first; obtain approval for the exact change. An accepted operation is pending, not proof of connectivity. Poll the returned operation/resource on its in_progress flag, waiting next_check_seconds between reads: while in_progress is true its reason_code is what is awaited (reason_kind waiting, e.g. a queued or pending reason, or a control plane that has not answered yet), never an error; only in_progress false with reason_kind failure is a failure. Preserve reason_code. On transport uncertainty inspect state and reuse only the original key and unchanged request; never automatically retry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ipv4No
restartNoOnly after the user authorizes a required restart from attachment-candidates; omit otherwise
network_idYesExact lowercase UUID returned by an owned networking resource
service_idYes
idempotencyKeyYesIdempotency-Key for this exact change; preserve it and the unchanged body on uncertain recovery

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.16

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (idempotentHint=true, destructiveHint=false), it discloses a great deal: the accepted attach is pending rather than confirmed, reserve/activate/detach take 13-81 s, the reason_code/in_progress state machine semantics, required networking:read vs networking:manage scopes, and backend ownership/2FA enforcement. Idempotency recovery behavior (reuse only the original key and unchanged body) is spelled out.

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 purpose and prerequisites are correctly front-loaded, but the polling instruction is stated twice ('poll it with get_networking_operation...' and later 'Poll the returned operation/resource on its in_progress flag...'), and the pending/reason_code guidance is repeated, making the description longer than it needs to be.

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?

For an async, world-mutating tool with no output schema and partial parameter coverage, the description covers the full lifecycle: pre-flight candidate check, auth scopes, pending semantics, poll cadence via get_networking_operation, activation_operation_id chaining, failure-vs-waiting reason interpretation, and safe recovery on transport uncertainty. An agent has everything needed to invoke and follow up correctly.

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 coverage is 60%, and the description fills the notable gap: ipv4 has no schema description, yet the description explains omitting it triggers automatic allocation while passing one requires a fixed usable address. It also reinforces the restart approval condition and idempotencyKey preservation, adding meaning beyond the schema for the parameters that matter most.

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?

The opening clause names a specific verb and resource ('Attach an eligible existing owned service to a private network') with an eligibility qualifier (port_intent_ready=true), which clearly separates it from siblings like attach_public_address_to_server or attach_network_vpn_gateway. It is slightly weakened by burying the core action under a long run-on sentence with operational detail.

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

Usage Guidelines5/5

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

It gives explicit preconditions and ordering: check list_network_attachment_candidates for pagination and attachment_mode first, set restart=true only after user approval, omit ipv4 for auto-allocation, and poll with get_networking_operation rather than retrying blindly. This is textbook when-to-use and when-not guidance with named collaborating tools.

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