servicenow-api

Get incident

servicenow_get_incident

Read-onlyIdempotent

Fetch details for a specific ServiceNow incident by sys_id, enabling users to inspect record data and troubleshoot support issues.

Instructions

Retrieve details of a specific incident record.

:param incident_id: The sys_id of the incident record. :type incident_id: str

:return: Response containing list of parsed Pydantic models with information about the retrieved records. :rtype: Response

:raises MissingParameterError: If table is not provided. :raises ParameterError: If input parameters are invalid.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "servicenow_get_incident"
  }
}

Input Schema

Name	Required	Description	Default
`data`	No
`incident_id`	No
`sysparm_view`	No
`sysparm_limit`	No
`sysparm_query`	No
`api_parameters`	No
`sysparm_fields`	No
`sysparm_offset`	No
`name_value_pairs`	No
`sysparm_no_count`	No
`sysparm_display_value`	No
`sysparm_query_category`	No
`sysparm_query_no_domain`	No
`sysparm_exclude_reference_link`	No
`sysparm_suppress_pagination_header`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.4.0Oct 19, 2026

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds return type and two documented error paths (MissingParameterError, ParameterError), but the error text about 'table' is boilerplate that contradicts the incident-specific nature and the listed return ('list of parsed Pydantic models') is vague for a single-record fetch.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is well front-loaded, but the docstring block spends lines on a ':raises MissingParameterError: If table is not provided' clause that is irrelevant to an incident tool and doubles as noise. Mixed structured/unstructured boilerplate without clear value.

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?

A 15-parameter tool with no output schema and no parameter documentation is substantially under-described; the description covers roughly one parameter and a rough return type. It falls short of what an agent needs to invoke this correctly, especially around query/field-filtering parameters.

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

Parameters2/5

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

Schema coverage is 0% across 15 parameters, so the description must compensate and largely does not. It documents only incident_id (as the sys_id) and ignores every sysparm_* control (fields, limit, display_value, exclude_reference_link, etc.), leaving the agent to guess at pagination and shaping behavior.

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?

States a specific verb and resource: 'Retrieve details of a specific incident record.' The word 'specific' plus the singular name implicitly separates it from the sibling servicenow_get_incidents, though it never names that sibling. Clear purpose, but no explicit differentiation.

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?

No when-to-use guidance, no statement of when to prefer servicenow_get_incidents or servicenow_get_table_record instead, and no prerequisites or auth context. The agent must infer the single-record retrieval scenario entirely from the name.

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

Deploy Server