Skip to main content
Glama
mhajder

NetBox MCP Server

by mhajder

Netbox Allocate Available

netbox_allocate_available

Allocate the next free IP, prefix, VLAN, or ASN from a NetBox pool and create it atomically, preventing duplicate assignments by concurrent callers.

Instructions

Allocate the next free IP, prefix, VLAN or ASN from a pool and create it. NetBox picks the value atomically, so concurrent callers never get the same one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoAttributes of the new object(s). Prefixes need {'prefix_length': 24}; VLANs need {'name': 'users'}. A list allocates several at once, e.g. [{'description': 'a'}, {'description': 'b'}] for two IPs.
kindYesWhat to look for: 'ips' (prefix or IP range), 'prefixes' (prefix), 'vlans' (VLAN group), 'asns' (ASN range).
parent_idYesNumeric object ID.
parent_typeYesType of the parent object that holds the pool.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish write semantics (readOnlyHint=false, non-idempotent, non-destructive), so the bar is lower. The description adds genuinely useful context beyond them: the value is chosen atomically and concurrent callers never collide. It still omits permission/auth requirements and what gets created on failure, keeping it short of a 5.

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?

Two short sentences, front-loaded with the action and followed by the atomicity guarantee. No filler or redundant restatement; every sentence earns its place.

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 an output schema present and annotations covering the write/safety profile, the description is adequate on behavior. Its gap is routing: among 18 siblings it never tells the agent when this is the right choice versus get_available or create_object, which matters for correct selection.

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 the schema already documents all four parameters including enum meanings and the data payload examples. The tool description adds no parameter detail beyond what the schema provides, so baseline 3 is appropriate.

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?

States a specific verb and resource set ('Allocate the next free IP, prefix, VLAN or ASN from a pool and create it'), which is more than a restatement. However, it does not name or explicitly distinguish itself from siblings like netbox_get_available or netbox_create_object, so differentiation is left to inference.

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

Usage Guidelines3/5

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

The description implies the use case (allocate a fresh value from an existing pool) but never states when to prefer this over netbox_get_available or netbox_create_object, nor any exclusions. Usage is only implied.

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