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

now-sdk-ext-mcp

Execute Background Script

execute_script
Destructive

Runs server-side JavaScript on a ServiceNow instance through Scripts - Background, with optional app scope and parameter substitution, and captures output via gs.info().

Instructions

Execute JavaScript on a ServiceNow instance using Scripts - Background (the /sys.scripts.do endpoint). The script runs server-side with full GlideSystem API access (gs, GlideRecord, GlideAggregate, GlideDateTime, GlideUser, etc.). Use gs.info() to produce output (gs.print() also works in global, but prints nothing in a scoped app).

SCOPE BEHAVIOR: Scripts execute within the specified application scope. When running in a scoped app (e.g., scope: 'x_myapp_custom'), you can reference that scope's Script Includes and classes directly by name (e.g., MyUtil.doSomething()) without fully-qualifying them. When running in global scope, scoped classes must be fully-qualified (e.g., x_myapp_custom.MyUtil.doSomething()). Only 'global' and applications developed on the instance (sys_app) can be used; installed store apps (sys_store_app) cannot — run in global and call their APIs fully-qualified. In a scoped app, use gs.info() for output: gs.print() is global-only.

IMPORTANT: This executes code directly on the ServiceNow instance. Always review scripts before execution and prefer read-only operations unless modification is explicitly intended.

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": {
      "script": "<script>"
    },
    "name": "execute_script"
  }
}

Input Schema

NameRequiredDescriptionDefault
scopeNoThe application scope to execute the script in. Accepts: - "global" — the Global scope. - The scope of an application developed on the instance (a sys_app, e.g. "x_myapp_custom") — resolved to its sys_id via the sys_app table. Installed store apps (sys_store_app) are rejected with an explanation. - A sys_id directly (32-character hex string) if already known. Defaults to "global". Set this to the target app scope when you need to access scoped Script Includes, Business Rules, or other scoped artifacts by their unqualified names.global
paramsNoOptional key-value pairs for parameter substitution in the script. Every occurrence of {paramName} in the script text will be replaced with the corresponding value before execution. Useful for safely injecting dynamic values without string concatenation in the script. Example: { "table": "incident", "field": "priority" } replaces {table} and {field} in the script.
scriptYesThe JavaScript code to execute on the ServiceNow instance. Use gs.info() (or, in global only, gs.print()) to output results — these are the only ways to capture output from background scripts. The script runs in the server-side Rhino engine with access to all ServiceNow server-side APIs: GlideRecord, GlideAggregate, GlideDateTime, GlideUser, gs.getUser(), gs.now(), GlideSysAttachment, and more. Scripts execute with the permissions of the authenticated user.
instanceNoThe ServiceNow instance auth alias to execute the script on. This is the alias configured via `now-sdk auth --add` (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. Changed2 schema fields changedv5.5.0
    • changedInput schema / properties / scope / description
      Previous value: -"The application scope to execute the script in. Accepts either:\n- A scope name (e.g., \"global\", \"x_myapp_custom\", \"x_snc_app\") — automatically resolved to the corresponding sys_id via the sys_scope table.\n- A sys_id directly (32-character hex string) if already known.\n\nDefaults to \"global\". Set this to the target app scope when you need to access scoped Script Includes, Business Rules, or other scoped artifacts by their unqualified names."New value: +"The application scope to execute the script in. Accepts:\n- \"global\" — the Global scope.\n- The scope of an application developed on the instance (a sys_app, e.g. \"x_myapp_custom\") — resolved to its sys_id via the sys_app table. Installed store apps (sys_store_app) are rejected with an explanation.\n- A sys_id directly (32-character hex string) if already known.\n\nDefaults to \"global\". Set this to the target app scope when you need to access scoped Script Includes, Business Rules, or other scoped artifacts by their unqualified names."
    • changedInput schema / properties / script / description
      Previous value: -"The JavaScript code to execute on the ServiceNow instance. Use gs.print() or gs.info() to output results — these are the only ways to capture output from background scripts. The script runs in the server-side Rhino engine with access to all ServiceNow server-side APIs: GlideRecord, GlideAggregate, GlideDateTime, GlideUser, gs.getUser(), gs.now(), GlideSysAttachment, and more. Scripts execute with the permissions of the authenticated user."New value: +"The JavaScript code to execute on the ServiceNow instance. Use gs.info() (or, in global only, gs.print()) to output results — these are the only ways to capture output from background scripts. The script runs in the server-side Rhino engine with access to all ServiceNow server-side APIs: GlideRecord, GlideAggregate, GlideDateTime, GlideUser, gs.getUser(), gs.now(), GlideSysAttachment, and more. Scripts execute with the permissions of the authenticated user."
  2. First observedv2.5.1

TDQS

A4/5.0
Behavior5/5

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

The description adds substantial behavioral detail beyond the annotations: script execution is server-side with full GlideSystem API access, output must be captured through gs.info(), scripts run with the authenticated user's permissions, and installed store apps are rejected in scope resolution. This directly supports the destructive, open-world annotations without contradicting them.

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 purpose and organized into clear sections for scope behavior and safety. It is somewhat repetitive—the gs.print() global-only limitation is stated twice—but the structure remains efficient and readable for a complex tool.

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 dangerous, open-world execution tool with no output schema, the description covers the essential behavior: execution context, output capture, permission model, scope resolution, and safety review. It does not explain timeout limits, return shape, or failure behavior, which leaves a small but real gap.

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

Parameters4/5

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

Schema coverage is already 100%, so the schema carries most parameter documentation. The description still adds useful meaning for the scope parameter by explaining how scoped versus global execution affects class references and why store apps cannot be used, which goes beyond the schema's field-level descriptions.

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 opens with a precise verb and resource: execute JavaScript on a ServiceNow instance via the Scripts - Background /sys.scripts.do endpoint. It clearly explains the runtime and available APIs, so an agent knows exactly what the tool does. It does not explicitly differentiate itself from siblings like query_table or execute_flow, which keeps it from a 5.

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

Usage Guidelines3/5

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

The description gives safety-oriented usage guidance (review scripts, prefer read-only operations) and important output guidance (use gs.info(), not gs.print(), in scoped apps). However, it never states when to choose this tool over alternatives such as query_table, execute_flow, or push_script, leaving that comparison implicit.

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