Skip to main content
Glama

Get change request models

servicenow_get_change_request_models
Read-onlyIdempotent

Retrieve ServiceNow change request models using filters like text search, queries, and parameters to get precise results for change management tasks.

Instructions

Retrieve change request models 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

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

:raises ParameterError: If invalid parameters or responses are encountered. :raises ParameterError: If JSON deserialization fails.

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.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds modest value by noting the return is a list of parsed Pydantic models and that ParameterError is raised on invalid input or JSON deserialization failure, but says nothing about pagination or result limits.

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

Conciseness2/5

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

The purpose sentence is front-loaded, but the bulk of the text is Sphinx docstring boilerplate whose :type: lines merely restate "str or None" already visible in the schema. This adds length without adding meaning and buries the one useful fact (the ParameterError behavior).

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 retrieval tool with no output schema, the description should at minimum explain the key filters and result-shaping params. It documents under 20% of the parameters and omits any mention of pagination, limits, or the meaning of the many sys_id filters, leaving an agent unable to call it correctly.

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 names 4 params (order, name_value_pairs, sysparm_query, text_search) and gives only tautological glosses plus type restatements. The remaining 18 params — including response_length, model_sys_id, change_model_sys_id, and the various sys_id filters — are entirely undocumented.

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 states a clear verb+resource ("Retrieve change request models"), so the basic purpose is legible. However, it never clarifies what a "change request model" is or how it differs from the numerous change-request siblings such as get_change_requests or get_standard_change_request_model, leaving differentiation to inference.

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 phrase "based on specified parameters" supplies no when-to-use guidance, no prerequisites, and no alternatives despite a large set of adjacent change-request retrieval tools. An agent gets no signal for choosing this over get_change_requests or get_standard_change_request_model.

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