Skip to main content
Glama
Sign In
now-sdk-ext-mcp

now-sdk-ext-mcp

by sonisoft-cnanda
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Set Current Update Set

set_current_update_set
Idempotent

Switch to an In progress, non-Default update set so later changes are captured there, and return the previous working set for later restoration.

Instructions

Make an In progress, non-Default update set the user's working set: the application (apps.current_app) and the update set, saved for every later session, as nex update-set use does. The result is read back, and it reports the previous working set: put it back with restore_update_set when the work is done. This changes what captures the user's own later changes, in the UI and elsewhere.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sys_id": "<sys_id>"
    },
    "name": "set_current_update_set"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoDeprecated and ignored: the set is identified by sys_id, and its name is read back.
sys_idYesThe sys_id of the In progress, non-Default update set to make current.
instanceNoThe ServiceNow instance auth alias to connect to. This is the alias configured via `snc configure` (e.g., "myinstance", "prod", "test"). The user will typically refer to this by name when saying things like "on my myinstance instance". If not provided, falls back to the SN_AUTH_ALIAS environment variable.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv5.5.0
    • changedInput schema / properties / name / description
      Previous value: -"The name of the update set to set as current."New value: +"Deprecated and ignored: the set is identified by sys_id, and its name is read back."
    • changedInput schema / properties / sys_id / description
      Previous value: -"The sys_id of the update set to set as current."New value: +"The sys_id of the In progress, non-Default update set to make current."
    • addedInput schema / properties / sys_id / pattern
      Added value: +"^[0-9a-f]{32}$"
    • changedInput schema / required
      Previous value: -[
-  "name",
-  "sys_id"
-]New value: +[
+  "sys_id"
+]
  2. First observedv2.5.1

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that the set must be In progress and non-Default, that the choice persists for later sessions, that the previous working set is reported, and that it changes what captures the user's later edits. These are meaningful behavioral facts not supplied by the annotations.

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 description is front-loaded with the action and uses only three sentences, each carrying relevant information. However, the phrase 'as nex update-set use does' is awkward and the second sentence packs several ideas together, slightly reducing clarity.

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

Completeness4/5

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

For a mutation tool with no output schema, the description covers the essential behavior: persistence, previous-state reporting, and how to restore. It could mention error behavior for invalid or Default update sets, but the schema already documents the required set conditions.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already explains sys_id, the deprecated name, and instance. The description reinforces the 'In progress, non-Default' condition but adds little parameter meaning beyond what the schema provides.

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

Purpose5/5

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

The description states a specific verb and resource: making an update set the user's working set. It also names restore_update_set as the way to undo it, which helps distinguish this tool from sibling update-set tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for use: set a working update set and revert with restore_update_set when done. It does not explicitly say when not to use this tool or point to get_current_update_set/list_update_sets for discovery, so it stops short of full when/when-not guidance.

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