Skip to main content
Glama
jseifeddine

NetBox MCP Server

by jseifeddine

netbox_get_changelogs

Retrieve and filter change history records from NetBox to track modifications, monitor user actions, and audit system activity.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filtersYes

Implementation Reference

  • The primary handler function for the 'netbox_get_changelogs' MCP tool. It queries the NetBox 'core/object-changes' endpoint using the provided filters and returns the changelog records. The @mcp.tool() decorator handles registration and schema generation from the function signature and docstring.
    @mcp.tool()
    def netbox_get_changelogs(filters: dict):
        """
        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
        """
        endpoint = "core/object-changes"
        
        # Make API call
        return netbox.get(endpoint, params=filters)
  • JSON schema definition for the 'netbox_get_changelogs' tool provided to the LLM in the chatbot application. This schema describes the expected input parameters for tool calls.
        "type": "function",
        "function": {
            "name": "netbox_get_changelogs",
            "description": "Get object change records (changelogs) from NetBox based on filters. Use this to see audit trails and recent changes.",
            "parameters": {
                "type": "object",
                "properties": {
                    "filters": {
                        "type": "object",
                        "description": "Filters to apply to the API call. Common filters include 'limit', 'time_after', 'time_before', 'action', 'user', 'changed_object_id'"
                    }
                },
                "required": []
            }
        }
    }
  • Registration of the 'netbox_get_changelogs' tool schema in the chatbot's list of available tools for the LLM to use in tool calling.
    self.tools = [
        {
            "type": "function",
            "function": {
                "name": "netbox_get_objects",
                "description": "Get objects from NetBox based on their type and filters. Use this to retrieve devices, sites, IP addresses, VLANs, etc.",
                "parameters": {
                    "type": "object",
                    "properties": {
                        "object_type": {
                            "type": "string",
                            "description": "Type of NetBox object (e.g., 'devices', 'ip-addresses', 'sites', 'vlans', 'interfaces', 'racks', 'device-types', 'manufacturers', 'tenants', 'circuits', 'virtual-machines', 'prefixes', 'services')"
                        },
                        "filters": {
                            "type": "object",
                            "description": "Filters to apply to the API call. Common filters include 'site', 'status', 'limit', 'name', etc."
                        }
                    },
                    "required": ["object_type"]
                }
            }
        },
        {
            "type": "function",
            "function": {
                "name": "netbox_get_object_by_id",
                "description": "Get detailed information about a specific NetBox object by its ID.",
                "parameters": {
                    "type": "object",
                    "properties": {
                        "object_type": {
                            "type": "string",
                            "description": "Type of NetBox object"
                        },
                        "object_id": {
                            "type": "integer",
                            "description": "The numeric ID of the object"
                        }
                    },
                    "required": ["object_type", "object_id"]
                }
            }
        },
        {
            "type": "function",
            "function": {
                "name": "netbox_get_changelogs",
                "description": "Get object change records (changelogs) from NetBox based on filters. Use this to see audit trails and recent changes.",
                "parameters": {
                    "type": "object",
                    "properties": {
                        "filters": {
                            "type": "object",
                            "description": "Filters to apply to the API call. Common filters include 'limit', 'time_after', 'time_before', 'action', 'user', 'changed_object_id'"
                        }
                    },
                    "required": []
                }
            }
        }
    ]
  • Fallback helper logic in the chatbot that automatically calls 'netbox_get_changelogs' when user input mentions 'change' or 'log' keywords if LLM doesn't invoke tools.
    tool_name = "netbox_get_changelogs"
    arguments = {"filters": {"limit": 10}}
Behavior3/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 effectively describes the tool's function and output format, including details like the structure of changelog entries and filtering options. However, it omits critical behavioral traits such as rate limits, authentication requirements, pagination handling, or error conditions, which are important for safe and effective use.

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, Each changelog entry) and uses bullet points for readability. It is appropriately sized for the tool's complexity, though some sentences could be more concise (e.g., the changelog entry list is verbose). Overall, it is efficient and front-loaded with key information.

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 (1 parameter with nested objects, no output schema, no annotations), the description is largely complete. It explains the purpose, parameters, return values, and includes examples. However, it lacks information on behavioral aspects like error handling or performance, which would enhance completeness for a tool with no structured annotations.

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?

The input schema has 0% description coverage and only defines a generic 'filters' object. The description compensates fully by detailing all filtering options (e.g., user_id, action, time_before) with explanations and examples, adding significant meaning beyond the schema. This comprehensive parameter documentation is essential given the schema's lack of detail.

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'), which is clear and specific. However, it does not explicitly differentiate from sibling tools like netbox_get_objects, which likely retrieves objects rather than their change logs.

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, such as the sibling tools netbox_get_object_by_id or netbox_get_objects. It includes examples of filter usage but does not mention prerequisites, exclusions, or contextual cues for selection. This lack of comparative guidance limits its utility in tool selection.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jseifeddine/netbox-mcp-chatbot'

If you have feedback or need assistance with the MCP directory API, please join our Discord server