Steps to Reproduce
MCP client: Claude Code (claude-opus-4-6)
-
Find a VM with multiple interfaces:
netbox_get_objects("virtualization.vminterface", {"virtual_machine_id": 306599})
# Returns 2 interfaces: eth0 (ID: 621493), eth1 (ID: 631527)
-
Query IPs using __in suffix as suggested by the tool description (Lookup suffixes: ... in):
netbox_get_objects("ipam.ipaddress", {"vminterface_id__in": [621493, 631527]}, limit=10)
-
Also tried with comma-separated string:
netbox_get_objects("ipam.ipaddress", {"vminterface_id__in": "621493,631527"}, limit=10)
Expected Behavior
Should return 5 IP addresses (3 for eth0 + 2 for eth1), same as querying each interface individually:
netbox_get_objects("ipam.ipaddress", {"vminterface_id": 621493}) # Returns 3 IPs ✅
netbox_get_objects("ipam.ipaddress", {"vminterface_id": 631527}) # Returns 2 IPs ✅
Observed Behavior
Both __in queries return >1k results — effectively every IP address in NetBox. The filter is silently ignored by NetBox/Django REST Framework (no error returned), so the LLM has no way to detect the failure and proceeds to work with incorrect data.
The tool description actively encourages this pattern:
Valid: Lookups like {'name__ic': 'switch', 'id__in': [1,2,3], 'vid__gte': 100}
Lookup suffixes: n, ic, nic, isw, nisw, iew, niew, ie, nie, empty, regex, iregex, lt, lte, gt, gte, in
This implies __in works universally on all fields, but relationship fields like vminterface_id on ipam.ipaddress only support exact match. The same issue was confirmed with assigned_object_id__in.
Suggested fix: Add a warning to the tool description that not all fields support all lookup suffixes, and that unsupported lookups are silently ignored by NetBox (returning all records). Optionally, the MCP server could detect suspiciously large result sets when restrictive filters were provided.
Steps to Reproduce
MCP client: Claude Code (claude-opus-4-6)
Find a VM with multiple interfaces:
Query IPs using
__insuffix as suggested by the tool description (Lookup suffixes: ... in):Also tried with comma-separated string:
Expected Behavior
Should return 5 IP addresses (3 for eth0 + 2 for eth1), same as querying each interface individually:
Observed Behavior
Both
__inqueries return >1k results — effectively every IP address in NetBox. The filter is silently ignored by NetBox/Django REST Framework (no error returned), so the LLM has no way to detect the failure and proceeds to work with incorrect data.The tool description actively encourages this pattern:
This implies
__inworks universally on all fields, but relationship fields likevminterface_idonipam.ipaddressonly support exact match. The same issue was confirmed withassigned_object_id__in.Suggested fix: Add a warning to the tool description that not all fields support all lookup suffixes, and that unsupported lookups are silently ignored by NetBox (returning all records). Optionally, the MCP server could detect suspiciously large result sets when restrictive filters were provided.