Skip to main content
Glama

Get change requests

servicenow_get_change_requests
Read-onlyIdempotent

Retrieve and filter ServiceNow change requests by type, state, text search, or query parameters to support change management tracking.

Instructions

Retrieve change requests based on specified parameters.

:param order: Ordering parameter for sorting results. :type order: str or None :param name_value_pairs: Additional name-value pairs for filtering. :type name_value_pairs: str or None :param sysparm_query: Query parameter for filtering results. :type sysparm_query: str or None :param text_search: Text search parameter for searching results. :type text_search: str or None :param change_type: Type of change (emergency, normal, standard, model). :type change_type: str or None

:return: Response containing list of parsed Pydantic models with information about change requests. :rtype: Response

:raises ParameterError: If invalid parameters or responses are encountered. :raises ParameterError: If change_type is specified but not valid. :raises ParameterError: If JSON serialization or deserialization fails. :raises ParameterError: If unexpected response format is encountered.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
stateNo
change_typeNo
task_sys_idNo
text_searchNo
model_sys_idNo
sysparm_limitNo
sysparm_queryNo
worker_sys_idNo
api_parametersNo
cmdb_ci_sys_idNo
sysparm_offsetNo
cmdb_ci_sys_idsNo
response_lengthNo
template_sys_idNo
association_typeNo
name_value_pairsNo
change_model_sys_idNo
change_request_sys_idNo
refresh_impacted_servicesNo
change_request_task_sys_idNo
standard_change_template_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.4.0

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description usefully adds that removal/validation failures surface as ParameterError, and that change_type is validated against emergency/normal/standard/model, which is genuine context beyond the annotations, though return/pagination behavior remains unaddressed.

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 leading sentence is front-loaded and the Sphinx docstring is orderly, but a large share of the text is boilerplate or restates parameter names without adding meaning. It is adequately sized rather than wasteful, yet much of the content does not earn its place.

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?

For a 22-parameter list tool with no output schema and 0% schema coverage, the description is far too thin: it omits pagination behavior (sysparm_limit/sysparm_offset/response_length), most identifiers, and any detail on the returned model collection. An agent cannot call this correctly on the strength of this text alone.

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 description coverage is 0% across 22 parameters, so the description carries the full burden, yet it only touches 5 of them and does so tautologically ("Query parameter for filtering results," "Ordering parameter for sorting results"). No syntax, accepted values, or format details are provided for sysparm_query, name_value_pairs, or the many sys_id filters.

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 names a specific verb and resource ("Retrieve change requests") and adds a filtering qualifier, so the agent knows this is a list/search operation. However, it offers no distinction from the sibling servicenow_get_change_request (singular), which is a critical ambiguity in a set with many overlapping change-request tools.

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?

There is no when-to-use guidance and no mention of alternatives such as servicenow_get_change_request for a single record or servicenow_get_change_request_tasks. The only usage signal is "based on specified parameters," which is generic filler rather than a selection condition.

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

Deploy Server

Other Tools