Skip to main content
Glama
echelon-ai-labs

ServiceNow MCP Server

list_incidents

Retrieve and filter ServiceNow incidents by assigned user, category, state, or search query. Manage pagination with limit and offset parameters for efficient incident tracking.

Instructions

List incidents from ServiceNow

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Implementation Reference

  • The core handler function for the 'list_incidents' tool. Queries the ServiceNow 'incident' table API with pagination and optional filters (state, assigned_to, category, query), processes the response to handle reference fields, and returns a structured dictionary of incidents.
    def list_incidents(
        config: ServerConfig,
        auth_manager: AuthManager,
        params: ListIncidentsParams,
    ) -> dict:
        """
        List incidents from ServiceNow.
    
        Args:
            config: Server configuration.
            auth_manager: Authentication manager.
            params: Parameters for listing incidents.
    
        Returns:
            Dictionary with list of incidents.
        """
        api_url = f"{config.api_url}/table/incident"
    
        # Build query parameters
        query_params = {
            "sysparm_limit": params.limit,
            "sysparm_offset": params.offset,
            "sysparm_display_value": "true",
            "sysparm_exclude_reference_link": "true",
        }
        
        # Add filters
        filters = []
        if params.state:
            filters.append(f"state={params.state}")
        if params.assigned_to:
            filters.append(f"assigned_to={params.assigned_to}")
        if params.category:
            filters.append(f"category={params.category}")
        if params.query:
            filters.append(f"short_descriptionLIKE{params.query}^ORdescriptionLIKE{params.query}")
        
        if filters:
            query_params["sysparm_query"] = "^".join(filters)
        
        # Make request
        try:
            response = requests.get(
                api_url,
                params=query_params,
                headers=auth_manager.get_headers(),
                timeout=config.timeout,
            )
            response.raise_for_status()
            
            data = response.json()
            incidents = []
            
            for incident_data in data.get("result", []):
                # Handle assigned_to field which could be a string or a dictionary
                assigned_to = incident_data.get("assigned_to")
                if isinstance(assigned_to, dict):
                    assigned_to = assigned_to.get("display_value")
                
                incident = {
                    "sys_id": incident_data.get("sys_id"),
                    "number": incident_data.get("number"),
                    "short_description": incident_data.get("short_description"),
                    "description": incident_data.get("description"),
                    "state": incident_data.get("state"),
                    "priority": incident_data.get("priority"),
                    "assigned_to": assigned_to,
                    "category": incident_data.get("category"),
                    "subcategory": incident_data.get("subcategory"),
                    "created_on": incident_data.get("sys_created_on"),
                    "updated_on": incident_data.get("sys_updated_on"),
                }
                incidents.append(incident)
            
            return {
                "success": True,
                "message": f"Found {len(incidents)} incidents",
                "incidents": incidents
            }
            
        except requests.RequestException as e:
            logger.error(f"Failed to list incidents: {e}")
            return {
                "success": False,
                "message": f"Failed to list incidents: {str(e)}",
                "incidents": []
            }
  • Pydantic model defining the input schema for the list_incidents tool, including pagination (limit, offset) and optional filters.
    class ListIncidentsParams(BaseModel):
        """Parameters for listing incidents."""
        
        limit: int = Field(10, description="Maximum number of incidents to return")
        offset: int = Field(0, description="Offset for pagination")
        state: Optional[str] = Field(None, description="Filter by incident state")
        assigned_to: Optional[str] = Field(None, description="Filter by assigned user")
        category: Optional[str] = Field(None, description="Filter by category")
        query: Optional[str] = Field(None, description="Search query for incidents")
  • Registers the 'list_incidents' tool in the central get_tool_definitions() function's dictionary, specifying the handler function alias, input schema, return type hint, description, and serialization method ('json').
    "list_incidents": (
        list_incidents_tool,
        ListIncidentsParams,
        str,  # Expects JSON string
        "List incidents from ServiceNow",
        "json",  # Tool returns list/dict, needs JSON dump
    ),
  • Imports list_incidents from incident_tools.py into the tools package namespace, making it available for export via __all__.
    from servicenow_mcp.tools.incident_tools import (
        add_comment,
        create_incident,
        list_incidents,
        resolve_incident,
        update_incident,
        get_incident_by_number,
    )
  • Imports the list_incidents handler as list_incidents_tool alias for use in tool definitions.
        list_incidents as list_incidents_tool,
    )
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only states the action without details on permissions, rate limits, pagination, or output format. 'List incidents' implies a read-only operation, but it doesn't confirm safety or describe what data is returned. This is insufficient for a tool with no annotation support.

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?

The description is extremely concise with a single sentence, 'List incidents from ServiceNow', which is front-loaded and wastes no words. It efficiently communicates the core purpose without redundancy, earning full marks for brevity and clarity in structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (6 sub-parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the tool's behavior, parameters, or output, leaving significant gaps. For a list operation with filtering capabilities, more context is needed to guide effective use, making this inadequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, meaning parameters are undocumented in the schema. The description adds no information about parameters, failing to compensate for this gap. With 1 parameter (a nested object with 6 sub-parameters), the description should at least hint at filtering options or usage, but it does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List incidents from ServiceNow' states the basic action (list) and resource (incidents) with the source (ServiceNow), which is clear but minimal. It doesn't distinguish this from other list tools like list_change_requests or list_articles, nor does it specify scope (e.g., all incidents, filtered). This is vague but not tautological, placing it at the minimum viable level.

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. With sibling tools like list_change_requests and list_articles, there's no indication of how incidents differ or when to prefer this tool. It also lacks prerequisites or context for usage, such as authentication or permissions, leaving the agent without direction.

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

Related 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/echelon-ai-labs/servicenow-mcp'

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