Skip to main content
Glama
NetBox MCP Server

NetBox MCP Server

by mhajder

Netbox Get Objects

netbox_get_objects
Read-onlyIdempotent

List NetBox objects of one type, with filtering and pagination.

Instructions

List NetBox objects of one type, with filtering and pagination.

Returns 'results' plus 'total' (all matches) and 'has_more'/'next_offset'. Results are paginated - check 'has_more' before concluding. To count objects cheaply use fields=['id'] and limit=1 and read 'total'.

Input Schema

NameRequiredDescriptionDefault
omitNoDrop these fields from the response, e.g. ['config_context', 'custom_fields']. NetBox 4.5.2+. Ignored when 'fields' is set.
briefNoReturn the minimal representation (id, url, display, name).
limitNoPage size (1-1000).
fieldsNoOnly return these fields, e.g. ['id', 'name', 'status']. ALWAYS pass this for listings - full objects cost 10x more tokens.
offsetNoNumber of results to skip.
filtersNoNetBox filters, e.g. {'site_id': 1, 'status': 'active', 'name__ic': 'core'}. Pass a list for OR: {'id': [1, 2]}. null matches empty: {'tenant_id': None}. Lookup suffixes: n, ic, nic, isw, nisw, iew, niew, ie, nie, empty, regex, iregex, lt, lte, gt, gte. NOT supported: '__in' and multi-hop lookups like 'device__site_id' - query the related object first, then filter by its ID.
orderingNoSort field(s); prefix with '-' for descending, e.g. 'name' or ['site', '-name'].
object_typeYesNetBox object type as 'app.model' (e.g. 'dcim.device', 'ipam.ipaddress', 'virtualization.virtualmachine') or as an API path ('dcim/devices'). netbox_list_object_types lists every type.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds real behavioral context the annotations don't: the response envelope ('results', 'total', 'has_more', 'next_offset') and the warning that results are paginated and 'has_more' must be checked before concluding.

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?

Three short sentences, front-loaded with what the tool does, then the response shape, then the pagination caveat. Every sentence earns its place with no filler.

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?

With an output schema, full annotation coverage and 100% schema descriptions, the description only needs to add the pagination contract and it does. The remaining gap is routing: it doesn't tell an agent when to reach for this versus netbox_search_objects or netbox_graphql_query.

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% and the schema already carries the critical guidance (fields 'ALWAYS pass this for listings', filters lookup suffixes, omit/fields interaction). The description's mention of fields=['id'] and limit=1 is a usage pattern rather than new parameter meaning, so this lands at the baseline.

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?

Clearly states a specific verb and resource: 'List NetBox objects of one type, with filtering and pagination.' The scope 'one type' implicitly distinguishes it from the singular netbox_get_object, but it never names netbox_search_objects or netbox_graphql_query, which an agent could easily confuse it with for query-style work.

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?

Gives useful operational hints (check 'has_more' before concluding; use fields=['id'] with limit=1 to count), but these are tips on how to use it, not when to pick it over siblings like netbox_search_objects or netbox_graphql_query. Usage is implied by the word 'List' rather than argued.

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