Skip to main content
Glama

Update change request first available

servicenow_update_change_request_first_available

Update a change request schedule to its first available slot by Sys ID to resolve ServiceNow scheduling conflicts.

Instructions

Update the schedule of a change request to the first available slot.

:param change_request_sys_id: Sys ID of the change request. :type change_request_sys_id: str or None

:return: Response containing parsed Pydantic model with information about the updated schedule. :rtype: Response

:raises MissingParameterError: If change_request_sys_id is not provided. :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.9/5.0
Behavior3/5

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true) with no contradiction. The description adds useful behavior beyond this — the mutation target (schedule), the return payload, and three error conditions. However it does not address the non-idempotent implication (repeated calls may reschedule to a different slot) or auth/permission needs, so it only partially carries the burden.

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 core purpose is front-loaded in the first sentence, and the Sphinx-style param/return/raises blocks are compact and scannable. The boilerplate directives (:type:, :rtype:) add minor noise but the whole definition stays appropriately sized.

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 mutation tool with 0% schema coverage and no output schema, the description is far too thin: it explains one parameter and a few error cases while leaving the schema's bulk undocumented. Annotations cover the safety profile, but the parameter-level completeness needed to actually invoke this tool is missing.

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 is the only source of parameter meaning — yet it documents just change_request_sys_id (and its missing-parameter error). The other 21 parameters, including ambiguous ones like data, association_type, and name_value_pairs, are left entirely unexplained.

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 states a specific verb+resource+behavior: updating a change request's schedule to the first available slot. This is clearer than a generic 'update' and hints at the auto-scheduling semantic. It does not explicitly contrast with sibling servicenow_update_change_request, but the scope is unambiguous.

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 guidance on when to use this tool versus servicenow_update_change_request or servicenow_get_change_request_schedule, nor any prerequisites or exclusions. The description only states what it does, leaving the agent to infer the routing decision.

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