How do I use NetBox MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@NetBox MCP Server show me all Cisco devices in the Equinix DC14 site" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

NetBox MCP Server

by jseifeddine

Overview Schema Source Related Servers Discussions Admin

Python

Remote

NetBox MCP Server

This is a simple read-only Model Context Protocol server for NetBox. It enables you to interact with your data in NetBox directly via LLMs that support MCP.

Tools

Tool	Description
get_objects	Retrieves NetBox core objects based on their type and filters
get_object_by_id	Gets detailed information about a specific NetBox object by its ID
get_changelogs	Retrieves change history records (audit trail) based on filters

Note: the set of supported object types is explicitly defined and limited to the core NetBox objects for now, and won't work with object types from plugins.

Related MCP server: NetBox MCP Server - Read & Write Edition

Usage

Create a read-only API token in NetBox with sufficient permissions for the tool to access the data you want to make available via MCP.
Install dependencies:

# Using UV (recommended)
uv sync

# Or using pip
pip install -e .

Verify the server can run: NETBOX_URL=https://netbox.example.com/ NETBOX_TOKEN=<your-api-token> uv run server.py
Add the MCP server configuration to your LLM client. For example, in Claude Desktop (Mac):

{
  "mcpServers": {
        "netbox": {
            "command": "uv",
            "args": [
                "--directory",
                "/path/to/netbox-mcp-server",
                "run",
                "server.py"
            ],
            "env": {
                "NETBOX_URL": "https://netbox.example.com/",
                "NETBOX_TOKEN": "<your-api-token>"
            }
        }
}

On Windows, use full, escaped path to your instance, such as C:\\Users\\myuser\\.local\\bin\\uv and C:\\Users\\myuser\\netbox-mcp-server. For detailed troubleshooting, consult the MCP quickstart.

Use the tools in your LLM client. For example:

> Get all devices in the 'Equinix DC14' site
...
> Tell me about my IPAM utilization
...
> What Cisco devices are in my network?
...
> Who made changes to the NYC site in the last week?
...
> Show me all configuration changes to the core router in the last month

Development

Contributions are welcome! Please open an issue or submit a PR.

License

This project is licensed under the Apache 2.0 license. See the LICENSE file for details.

Available Tools

3 tools

netbox_get_changelogsA

Get object change records (changelogs) from NetBox based on filters.

Args: filters: dict of filters to apply to the API call based on the NetBox API filtering options

Returns: List of changelog objects matching the specified filters

Filtering options include:

user_id: Filter by user ID who made the change
user: Filter by username who made the change
changed_object_type_id: Filter by ContentType ID of the changed object
changed_object_id: Filter by ID of the changed object
object_repr: Filter by object representation (usually contains object name)
action: Filter by action type (created, updated, deleted)
time_before: Filter for changes made before a given time (ISO 8601 format)
time_after: Filter for changes made after a given time (ISO 8601 format)
q: Search term to filter by object representation

Example: To find all changes made to a specific device with ID 123: {"changed_object_type_id": "dcim.device", "changed_object_id": 123}

To find all deletions in the last 24 hours: {"action": "delete", "time_after": "2023-01-01T00:00:00Z"}

Each changelog entry contains:

id: The unique identifier of the changelog entry
user: The user who made the change
user_name: The username of the user who made the change
request_id: The unique identifier of the request that made the change
action: The type of action performed (created, updated, deleted)
changed_object_type: The type of object that was changed
changed_object_id: The ID of the object that was changed
object_repr: String representation of the changed object
object_data: The object's data after the change (null for deletions)
object_data_v2: Enhanced data representation
prechange_data: The object's data before the change (null for creations)
postchange_data: The object's data after the change (null for deletions)
time: The timestamp when the change was made

ParametersJSON Schema

Name	Required	Description	Default
`filters`	Yes

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It effectively discloses behavioral traits: it's a read operation (implied by 'Get'), returns a list of changelog objects, details the structure of each entry (e.g., id, user, action, time), and includes filtering capabilities. However, it does not mention potential limitations like rate limits, authentication needs, or pagination, which are relevant for API tools.

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?

The description is well-structured with clear sections (Args, Returns, Filtering options, Example, entry details) and front-loaded purpose. It is appropriately sized for the complexity, but could be slightly more concise by integrating some details (e.g., entry fields) into a more streamlined format without losing clarity.

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?

Given the tool's complexity (filtering changelogs), no annotations, no output schema, and 0% schema coverage, the description is largely complete. It covers purpose, parameters with examples, return format, and entry details. However, it lacks information on error handling, pagination, or authentication, which are common in API contexts, leaving minor gaps.

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?

Schema description coverage is 0%, with only one parameter ('filters') documented minimally in the schema. The description compensates fully by detailing filtering options (e.g., user_id, action, time_before), providing examples of filter usage, and explaining the parameter's role in the API call. This adds significant meaning beyond the basic 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?

The description clearly states the tool's purpose: 'Get object change records (changelogs) from NetBox based on filters.' It specifies the verb ('Get'), resource ('object change records'), and scope ('from NetBox based on filters'), but does not explicitly differentiate it from sibling tools like 'netbox_get_objects' or 'netbox_get_object_by_id' beyond the changelog focus.

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 usage for retrieving changelogs with filtering, but does not explicitly state when to use this tool versus alternatives like 'netbox_get_objects' for current data. It provides example use cases (e.g., finding changes to a device or deletions in a time range), which offer some contextual guidance, but lacks direct comparisons or exclusions.

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

netbox_get_object_by_idC

Get detailed information about a specific NetBox object by its ID.

Args: object_type: String representing the NetBox object type (e.g. "devices", "ip-addresses") object_id: The numeric ID of the object

Returns: Complete object details

ParametersJSON Schema

Name	Required	Description	Default
`object_type`	Yes
`object_id`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what 'Complete object details' entails (e.g., format, depth). For a tool with no annotations, this leaves significant gaps in understanding how it behaves.

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?

The description is appropriately sized and front-loaded: the first sentence states the core purpose clearly. The 'Args' and 'Returns' sections are structured but slightly verbose for such a simple tool. Every sentence adds value, though it could be more concise by integrating the parameter details into the main text.

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?

Given the tool's low complexity (2 parameters, no nested objects) but lack of annotations and output schema, the description is minimally adequate. It covers the basic what and how but misses context like error cases, performance, or integration with siblings. For a read-only tool, this is passable but leaves the agent to guess about behavioral nuances.

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?

The description adds basic meaning for both parameters: 'object_type' is described as 'String representing the NetBox object type (e.g. "devices", "ip-addresses")' and 'object_id' as 'The numeric ID of the object.' With schema description coverage at 0%, this compensates somewhat by providing examples and clarifications. However, it doesn't detail constraints (e.g., valid object types, ID ranges) or advanced usage, keeping it at a baseline level.

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 description clearly states the tool's purpose: 'Get detailed information about a specific NetBox object by its ID.' It specifies the verb ('Get'), resource ('NetBox object'), and key constraint ('by its ID'). However, it doesn't explicitly distinguish this from sibling tools like 'netbox_get_objects' (which likely lists objects rather than fetching a specific one).

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'netbox_get_objects' (for listing) or 'netbox_get_changelogs' (for history), nor does it specify prerequisites or contexts where this tool is preferred. The agent must infer usage from the name and description alone.

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

netbox_get_objectsB

Get objects from NetBox based on their type and filters Args: object_type: String representing the NetBox object type (e.g. "devices", "ip-addresses") filters: dict of filters to apply to the API call based on the NetBox API filtering options

Valid object_type values:

DCIM (Device and Infrastructure):

cables
console-ports
console-server-ports
devices
device-bays
device-roles
device-types
front-ports
interfaces
inventory-items
locations
manufacturers
modules
module-bays
module-types
platforms
power-feeds
power-outlets
power-panels
power-ports
racks
rack-reservations
rack-roles
regions
sites
site-groups
virtual-chassis

IPAM (IP Address Management):

asns
asn-ranges
aggregates
fhrp-groups
ip-addresses
ip-ranges
prefixes
rirs
roles
route-targets
services
vlans
vlan-groups
vrfs

Circuits:

circuits
circuit-types
circuit-terminations
providers
provider-networks

Virtualization:

clusters
cluster-groups
cluster-types
virtual-machines
vm-interfaces

Tenancy:

tenants
tenant-groups
contacts
contact-groups
contact-roles

VPN:

ike-policies
ike-proposals
ipsec-policies
ipsec-profiles
ipsec-proposals
l2vpns
tunnels
tunnel-groups

Wireless:

wireless-lans
wireless-lan-groups
wireless-links

See NetBox API documentation for filtering options for each object type.

ParametersJSON Schema

Name	Required	Description	Default
`object_type`	Yes
`filters`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering based on NetBox API options, hinting at read-only behavior, but doesn't explicitly state whether this is a safe read operation, its pagination or rate limits, error handling, or output format. For a tool with two parameters and no annotation coverage, this leaves significant gaps in understanding its behavior.

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 description is front-loaded with the core purpose and args, but the lengthy list of object types (over 60 items) dominates the text, making it verbose. While the list is informative, it could be summarized or referenced externally to improve conciseness. The structure is logical but not optimally sized for quick scanning.

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?

Given 2 parameters, no annotations, no output schema, and 0% schema coverage, the description does well by detailing parameter semantics and object types. However, it lacks information on behavioral aspects (e.g., read-only nature, pagination) and output format, which are critical for a retrieval tool. It's partially complete but misses key contextual elements for full agent understanding.

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 compensate. It provides extensive context: 'object_type' is explained with a string example and a comprehensive list of valid values across categories (DCIM, IPAM, etc.), and 'filters' is described as a dict for API filtering with a reference to NetBox documentation. This adds substantial meaning beyond the bare schema, though it doesn't detail filter syntax or examples.

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 description clearly states the tool's purpose: 'Get objects from NetBox based on their type and filters.' It specifies the verb ('Get') and resource ('objects from NetBox'), and distinguishes it from siblings like 'netbox_get_object_by_id' by implying bulk retrieval with filters. However, it doesn't explicitly differentiate from other read operations like 'netbox_get_changelogs' beyond the object focus.

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 usage for retrieving multiple objects with filtering, as opposed to 'netbox_get_object_by_id' for single objects by ID. It lists valid object types, suggesting when to use it for specific data categories. However, it lacks explicit guidance on when not to use it (e.g., vs. bulk operations or changelogs) or clear alternatives beyond the implied sibling distinction.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv1.0.0Jan 3, 2026
- Changednetbox_get_changelogs1 field changed
  - addedInput schema / title
```
Added value: +"netbox_get_changelogsArguments"
```
- Changednetbox_get_object_by_id1 field changed
  - addedInput schema / title
```
Added value: +"netbox_get_object_by_idArguments"
```
- Changednetbox_get_objects1 field changed
  - addedInput schema / title
```
Added value: +"netbox_get_objectsArguments"
```
3 tool updatesSep 29, 2025
- First observednetbox_get_changelogs
- First observednetbox_get_object_by_id
- First observednetbox_get_objects

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored 2026-04-18 08:35 across 3 tools

Disambiguation5/5

The three tools have clearly distinct purposes: netbox_get_changelogs retrieves audit logs of changes, netbox_get_object_by_id fetches a single object by ID, and netbox_get_objects lists objects by type with filtering. There is no overlap in functionality, making it easy for an agent to select the right tool for each task.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with the prefix 'netbox_' and a descriptive verb_noun structure: get_changelogs, get_object_by_id, get_objects. This uniformity makes the tool set predictable and easy to understand at a glance.

Tool Count3/5

With only three tools, the server feels thin for the broad domain of NetBox, which includes many object types across DCIM, IPAM, circuits, virtualization, tenancy, VPN, and wireless. While the tools cover basic read operations, the count is borderline low given the extensive scope implied by the object_type list.

Completeness2/5

The tool set is severely incomplete for a NetBox server, as it only provides read operations (get) with no support for create, update, or delete. This leaves significant gaps in CRUD/lifecycle coverage, which will likely cause agent failures when trying to perform common administrative tasks like adding devices or modifying IP addresses.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

Dataassist-IOOAuth
io.github.DataAssistIO
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Search Databases
2
HAVNOAuth
app.havnre
Read-only AI access to HAVN properties, leads, tasks, files, media, and analytics.
Real Estate CRM
2
onelens-mcpOAuth
io.github.astuto-ai
Query OneLens cloud-cost data in natural language: breakdowns, trends, cost centers. Read-only.
Search Cloud Platforms Finance
2
QueryBearOAuth
io.github.spencerpauly
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Databases RAG Systems
2

Related MCP Servers

NetBox MCP Server
Search Databases
chadkunsman
A
license
Not graded
quality
D
maintenance
A read-only FastMCP server that enables AI assistants to query and retrieve network infrastructure information from NetBox using natural language.
Updated 3 months ago (2026-06-03 23:59 UTC)
MIT
NetBox MCP Server - Read &
Developer Tools Databases App Automation
alexkiwi1
A
license
A
quality
F
maintenance
Enables comprehensive interaction with NetBox infrastructure management through both read and write operations. Supports full CRUD operations for devices, IP addresses, sites, racks, and other NetBox objects through natural language commands.
Updated a year ago (2025-09-14 05:11 UTC)
9
17
Apache 2.0
NetBox MCP Serverofficial
Networking & Infrastructure Databases
netboxlabs
A
license
A
quality
C
maintenance
Read-only MCP server for NetBox that enables LLMs to query NetBox objects (devices, IPAM, etc.) and change logs through natural language, with field filtering for token optimization.
Updated 3 days ago (2026-09-10 18:26 UTC)
4
225
Apache 2.0
phpIPAM MCP Server
Networking & Infrastructure Security
alsamasu
A
license
A
quality
C
maintenance
Enables LLMs to manage IP addresses, subnets, and network sections through natural language, with security features like read-only by default.
Updated 8 months ago (2026-01-05 08:07 UTC)
13
MIT

NetBox MCP Server

Tools

Usage

Development

License

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

NetBox MCP Server

NetBox MCP Server - Read &

NetBox MCP Serverofficial

phpIPAM MCP Server