Loading ToolBench
A read-only MCP server for NetBox infrastructure data
NetBox MCP server provides a single well-structured tool with clear naming and comprehensive parameter documentation. The tool name 'netbox_get_objects' follows verb_noun convention and clearly indicates a read-only GET operation. The description is detailed (412 chars) and includes extensive guidance on filter rules, lookup suffixes, and multi-step query patterns. Input schema is properly defined with type declarations and field descriptions. However, the output schema is not documented in the visible source code, which is a significant gap for agent planning. The tool lacks error handling guidance, output structure documentation, and schema validation examples. Parameter descriptions are thorough but could be formatted more accessibly for LLMs.
Get objects from NetBox based on their type and filters Args: object_type: String representing the NetBox object type (e.g. "dcim.device", "ipam.ipaddress") filters: dict of filters to apply to the API call based on the NetBox API filtering options FILTER RULES: Valid: Direct fields like {'site_id': 1, 'name': 'router', 'status': 'active'} Valid: Field-supported lookups like {'name__ic': 'switch', 'vid__gte': 100} Invalid: Multi-hop like {'device__site_id': 1} - NOT supported Lookup suffixes: n, ic, nic, isw, nisw, iew, niew, ie, nie, empty, regex, iregex, lt, lte, gt, gte Lookup support is field-specific. NetBox may silently ignore unsupported lookups and return overly broad results. The '__in' suffix is not supported and is rejected by this tool. For multiple values, pass a list as the field value directly: {'vminterface_id': [621493, 631527]} or {'id': [1, 2, 3]}. Two-step pattern for cross-relationship queries: sites = netbox_get_objects('dcim.site', {'name': 'NYC'}) netbox_get_objects('dcim.device', {'site_id': sites[0]['id']})
Output schema not documented. Tool description explains complex filter rules extensively but does not state what fields are returned or data structure of the result. LLMs cannot plan downstream calls or extract required IDs without knowing the response format.
No error handling guidance. If filters are invalid, object_type is unknown, or API connectivity fails, the tool provides no recovery hints. Error responses should guide LLMs: 'Invalid object_type. Call netbox_list_object_types() to discover available types.'
No pagination or result limit enforcement documented. Tool accepts arbitrary filters but does not state if results are capped, whether pagination is supported, or what happens if thousands of objects match. Large results risk context explosion.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 74 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Filter parameter description is verbose and mixes rules, examples, and warnings. LLMs may miss key constraints (e.g. '__in' suffix rejected) buried in paragraph text. Format as structured rules: 'Supported suffixes: [list]. Unsupported: __in (use list values instead).'
Parameter 'filters' lacks type specificity. Described as 'dict' but what are valid keys? What value types are accepted (string, int, list, bool)? LLMs need explicit constraints: 'dict[str, str | int | list[int]]' or enumerate supported field names.