Add a column to a table, as the Columns related list does, with its Field Label and form layout captured and verified. The update set must be the working set (set_current_update_set): the platform captures schema changes only into the current set. The platform's prefix (u_ in Global, _ on another application's table) is added when missing.

Delete application metadata through the platform's own Delete, captured as a DELETE in the named update set and read back. Only when the user asked for the delete; deleting a record that other instances already have removes it there too when the set is committed. Writes through the record's form in the named application and update set, then reads back the record and its capture. Refuses protected files, the platform's own schema tables, and access controls (use the ACL tools). Writing code (a script, a server condition, Jelly, a javascript: value, or switching such a record on) is refused when the session does not permit running scripts.

Read a column's choice list in one language, with the list's application (the one to write it in) and capture name.

Read one form section's layout (sys_ui_section) in order: field names, .begin_split / .split / .end_split, and .formatter.<sys_id>. Find sections with query_table on sys_ui_section (name = table, view).

Read a table's list columns (sys_ui_list) for a view, in order; dot-walked columns as field.field.

Insert application metadata (a script include, business rule, UI action, property, ...). Writes through the record's form in the named application and update set, then reads back the record and its capture. Refuses protected files, the platform's own schema tables, and access controls (use the ACL tools). Writing code (a script, a server condition, Jelly, a javascript: value, or switching such a record on) is refused when the session does not permit running scripts.

Remove a choice from a column's list, captured in the named update set. Refused while records hold the value: prefer set_choice with inactive, and remove anyway only when the user asked.

Remove a column from a table (the platform's Delete on its dictionary record), with every DELETE capture verified in the named update set. It deletes the column's data here and wherever the set is committed: only when the user asked. Refused while rows hold values, or while client scripts or UI policy actions name it, unless those are acknowledged.

Add a choice to a column's list, or change one (label, sequence, hint, inactive), in the list's application and the named update set; the list's capture is verified there. Inactivating keeps the label and hides it from new selections.

Replace one form section's layout with the whole new element list, as the Form Layout page saves it, captured and read back. Read it first with get_form_layout and send every element to keep. The update set must be the working set. Refused for sections holding annotations, charts or embedded lists.

Replace a table's list columns for a view with the whole new column list, as the List Layout page saves it, captured and read back. Read it first with get_list_layout. The update set must be the working set.

Change fields of application metadata. Writes through the record's form in the named application and update set, then reads back the record and its capture. Refuses protected files, the platform's own schema tables, and access controls (use the ACL tools). Writing code (a script, a server condition, Jelly, a javascript: value, or switching such a record on) is refused when the session does not permit running scripts.

Plan the move of a legacy workflow to Flow Designer: how each activity maps to a flow step, what has to stay a script, and a Fluent (now-sdk) skeleton for the flow, returned as text. Read-only: nothing is written to the instance or to disk.

Export a legacy workflow version as one complete JSON document (now-sdk-ext/legacy-workflow@1): every activity with its variables, the transitions and conditions. Read-only.

Read one legacy workflow version's definition as JSON: its activities with their exits (and variable values), transitions, stages and editor status. For a readable view use outline_workflow.

List legacy workflow activity types, or describe one as this instance defines it (its variables, default conditions, and optionally its implementation script or how published workflows configure it).

List legacy Workflow Editor workflows with the state of their published and checked-out versions.

Show a legacy workflow as a readable outline (default), a node list (every activity with its exits and where it is reached from), a structural analysis, or a Mermaid flowchart.

Run the Workflow Editor's Validate Workflow on a version (by default your draft if you have one, else the published version) and return its report, without publishing anything. The platform saves the report over that version's previous one; the workflow itself is unchanged.

Repair an installed Store or company application (the platform's Repair Application): reinstall its installed version from the application repository, without uninstalling it, and wait for the result. Files that were customized on the instance are kept (listed as skipped). Trust only a result that says Repaired: it requires the tracker to succeed and a new upgrade history to be written. Refused for an application developed on this instance, an inactive one, or one that contains plugins. Only when the user asked for a repair; it runs whatever the application's install runs.

Read the design-time definition of a Flow Designer flow, subflow or action as Workflow Studio stores it: its trigger, steps, flow logic, inputs and outputs. What the artifact IS, not what a run of it did (for that, use get_flow_execution_details). Nothing is run, published or changed. The type is never inferred: a sys_id of another type fails with type_mismatch.

Send a message to a paused flow execution (one waiting in a Wait For Message step), which resumes it: the flow then runs whatever comes next. Sent from a server-side script (sn_fd.FlowAPI.sendMessage). Only when the user asked; the message must be the one the step waits for. The platform accepts a message even when nothing is waiting for it, so check get_flow_context_status afterwards to see whether the flow resumed.

Mint a verified Playwright browser session for an instance alias, as nex auth browser-session does: log in with the alias's stored credential, prove the cookies work on their own, and save them as a Playwright storage-state file (owner-only, 0600) in this server's session directory. Returns the file's path, never the cookies. The session has the user's full rights in the UI, outside this server's change policy, so it is refused when changes are not permitted. Never print, read out or commit the file, and delete it with delete_browser_session when the browser work is done.

Delete a browser session file that create_browser_session wrote, once the browser work is done. Only a .json file in this server's session directory is deleted. The instance's UI session itself ends at its idle timeout.

Change a debug run's breakpoints, by the step numbers Workflow Studio shows: replace them (set), add or remove some, or clear them all. Each step is looked up in the debugger's own list of places it can stop; one it cannot stop at is refused with the valid steps. remove matches by step number, so a breakpoint on an inner action step (which has none) is only removed by set or clear. While the run is in a subflow, this applies to the subflow. To list them, use debug_flow_inspect with view breakpoints.

End a debug run, and any subflow it stepped into, then read it back. Safe to repeat. It refuses a flow context the debugger did not start, so it cannot end a real flow run. Needs only write, so it works under NEX_POLICY_DENY=execute.

Show a debug run without moving it: where it is (default), every step's runtime inputs and outputs (steps), where it can stop (locations), or its breakpoints. Values are the run's real data; long ones are cut unless full.

Debug a flow or subflow to a breakpoint in one call: start it, run to the first of the breakpoints, report every step's inputs and outputs there, then (by default) cancel it so nothing is left open. after resume lets it run on to the end, ignoring the other breakpoints; after stay leaves it paused for debug_flow_step. The run is real: records it creates or changes are kept. Only when the user asked to debug.

Start a Workflow Studio debug run (Test > Debug) of a flow or subflow and leave it paused before its first step. The flow's current draft runs, for real: records it creates or changes are kept, so debug a copy (copy_flow) in a scratch app. Returns the run's root context id, the steps it can stop at, and where it is. Continue with debug_flow_step, and always end it: run it to the end, or debug_flow_cancel. debug_flow_run_to does all of this in one call. Only when the user asked to debug.

Move a paused debug run and report where it is: over (run the paused step, stop at the next; default), into (enter a subflow call, which runs in a child context that later calls apply to), out (run the rest of the current subflow; at the top level, the rest of the run), resume (to the next breakpoint or the end), or skip_all (to the end, ignoring breakpoints). The steps run for real.

List debug runs still open on the instance (paused, waiting or running), newest first. A run left paused holds a flow context open: find it here and end it with debug_flow_cancel.

Ask the platform to cancel one active transaction (the Kill action on Active Transactions). The work it was doing stops part way and is not undone, and the user who started it gets an error. Only when the user asked, for a transaction found with list_transactions; never one of your own requests.

List the transactions running now on every responding cluster node (Active Transactions, All Nodes): user, age, type, state and URL (query values removed). For finding a stuck or runaway request. The nodes are asked to report and polled, so this can take some seconds.

Add a role to an access control: users with that role then pass its role check (roles are alternatives), and reach any script the ACL has. This is a security change: before calling it, tell the user who gains or loses access and get their go-ahead. It elevates its own session to security_admin (only for ACL tools; other tools stay unelevated) and writes into the named update set, verifying each write by reading it back. To swap a role, add the new one before removing the old.

Create an access control. This is a security change: before calling it, tell the user who gains or loses access and get their go-ahead. It elevates its own session to security_admin (only for ACL tools; other tools stay unelevated) and writes into the named update set, verifying each write by reading it back. With roles, the ACL is inserted inactive, given its roles, cleared of the snc_internal role the platform adds to a role-less ACL, checked, and only then activated. Without roles, snc_internal stays and every internal user who meets the condition or script passes. Put an ACL in its table's application: the platform's documented limits allow only role-based field ACLs on another application's table.

Delete an access control and its role rows. This is a security change: before calling it, tell the user who gains or loses access and get their go-ahead. It elevates its own session to security_admin (only for ACL tools; other tools stay unelevated) and writes into the named update set, verifying each write by reading it back. Prefer update_acl with active=false, which is reversible, unless the user asked to delete. An active record ACL is deactivated first (the platform deletes only inactive ones) and reactivated if the delete fails.

Read one access control with its roles, condition and script.

The elevated privilege roles (e.g. security_admin) this user may elevate to, as the Elevate Role dialog offers them. With elevate, also elevates a session to security_admin and proves it holds. Elevating changes no instance data.

List access controls (sys_security_acl) with their roles. Needs at least one of table, name, scope or scope_id. table returns the table's own ACLs: table, table.* and table.<field> (not the parent tables'; list those too). Roles on one ACL are alternatives; snc_internal among them lets every internal user pass.

Remove a role from an access control. This is a security change: before calling it, tell the user who gains or loses access and get their go-ahead. It elevates its own session to security_admin (only for ACL tools; other tools stay unelevated) and writes into the named update set, verifying each write by reading it back. Removing the last role makes the platform put snc_internal back, which lets every internal user past the role check, so any script on the ACL then runs for them: add the intended role first. Never remove a role shown only as a sys_id (hidden): its name is unknown to this session.

Change an access control's fields (roles: add_acl_role / remove_acl_role). This is a security change: before calling it, tell the user who gains or loses access and get their go-ahead. It elevates its own session to security_admin (only for ACL tools; other tools stay unelevated) and writes into the named update set, verifying each write by reading it back. On an ACL that already has code (a script or javascript: condition), switching it on, changing its operation or turning admin overrides off also needs permission to run code. Deactivating (active=false) is a security change too: other ACLs, the parent table's, or the default then decide, and switching off a Deny-Unless ACL can only widen access.

Run aggregate functions (COUNT, AVG, MIN, MAX, SUM) grouped by a field on any ServiceNow table. Returns per-group statistics — ideal for breakdowns and dashboards.

Examples: count of incidents grouped by priority, average resolution time grouped by category, sum of story points grouped by assignee.

Run aggregate functions (COUNT, AVG, MIN, MAX, SUM) on any ServiceNow table using the Stats API. Returns computed statistics without returning individual records.

Examples: average resolution time for incidents, max priority across open changes, sum of story points in a sprint, count of active users.

Count records on any ServiceNow table, optionally filtered by an encoded query. Uses the Stats API for efficient server-side counting — much faster than querying all records and counting client-side.

Use this to quickly gauge data volumes (e.g., how many open P1 incidents, how many users in a group, how many CIs of a given class).

Get detailed information about a ServiceNow application by its sys_id. Returns version, install status, update availability, scope, vendor, dependencies, store link, and other metadata.

Use lookup_app to find an application's sys_id by name, then use this tool to get full details.

Install an application from the company's ServiceNow application repository using the CI/CD API. This is a MUTATIVE, LONG-RUNNING operation that blocks until installation completes or times out (default: 30 minutes).

Typically used for deploying custom applications across instances (e.g., dev -> test -> prod). Use list_company_apps to find the application scope and sys_id.

Install a ServiceNow store application on the target instance. This is a MUTATIVE, LONG-RUNNING operation that blocks until installation completes or times out (default: 30 minutes).

IMPORTANT:

• Installation adds new tables, scripts, and configuration to the instance.

• Review the application details (use get_app_details) before installing.

• Ensure the instance has sufficient capacity and the right entitlements.

• Consider testing on a sub-production instance first.

Use search_store_apps with tab_context 'available_for_you' to find apps available for installation.

List company-internal applications shared within your organization. Returns application metadata including name, scope, version, install status, and update availability.

Optionally filter by scope, sys_id, or installed status.

Publish an application to the company's ServiceNow application repository using the CI/CD API. This is a MUTATIVE, LONG-RUNNING operation that blocks until publishing completes or times out (default: 30 minutes).

This makes the application version available for installation on other instances in the company. Use list_company_apps or lookup_app to find the scope and sys_id.

Search or browse ServiceNow store applications by category.

Tab contexts:

• "installed" — list all installed store applications

• "updates" — list installed apps that have updates available

• "available_for_you" — browse apps available for installation

Use this to discover what is installed, find available updates, or browse for new applications to install.

Update an installed ServiceNow store application to a newer version. This is a MUTATIVE, LONG-RUNNING operation that blocks until the update completes or times out (default: 30 minutes).

IMPORTANT:

• Updates may alter existing behavior, modify tables, and affect customizations.

• Customizations to the application may be overwritten during the update.

• Consider testing on a sub-production instance first.

Use search_store_apps with tab_context 'updates' to find apps with available updates.

Validate whether a set of applications are installed at the expected versions. Reports which apps are valid, need installation, need upgrade, or have version mismatches.

Useful for verifying environment readiness or checking deployment prerequisites.

Execute a single ServiceNow ATF (Automated Test Framework) test by its sys_id. The test runs on the instance, and this tool waits for it to complete before returning the result. Returns the test name, status (success/failure), run time, and any output produced by the test.

Use this tool when the user wants to run a specific ATF test and see its results.

Execute a ServiceNow ATF test suite and wait for all tests to complete. Identify the suite by either its name or sys_id (provide exactly one). Returns a summary with pass/fail/skip/error counts and overall status.

Use this tool when the user wants to run a collection of ATF tests as a suite.

Get metadata for a specific attachment by its sys_id. Returns file name, content type, size, and the record it is attached to.

List file attachments on a ServiceNow record. Returns metadata for each attachment including file name, content type, and size.

Use this to discover what files are attached to incidents, changes, catalog items, or any other record.

Upload a file attachment to a ServiceNow record. The file content must be provided as a base64-encoded string.

IMPORTANT: This creates an attachment on the ServiceNow instance.

Create multiple records across one or more ServiceNow tables in a single batch. Operations execute sequentially, supporting variable references between them: use saveAs to name an operation's result sys_id, then reference it in later operations with ${name} in data values.

Example: Create a parent record with saveAs='parent', then create a child record with caller_id set to '${parent}'.

IMPORTANT: This creates records on the ServiceNow instance. Review the operations before executing.

Update multiple records across one or more ServiceNow tables in a single batch. Each update specifies a table, sys_id, and the field data to update.

IMPORTANT: This modifies records on the ServiceNow instance.

Get details of a specific service catalog category by sys_id, including the count of items in that category.

Get details of a specific service catalog item by sys_id, optionally including its variables (form fields). Use this to understand what a catalog item offers and what information is needed before submitting a request.

Set include_variables to true (default) to also retrieve the item's form fields.

List service catalog categories from the sc_category table. Filter by parent category, catalog, active status, or title. Use this to browse the catalog's organizational structure.

List the variables (form fields) for a specific catalog item. Returns variable names, types, whether they are mandatory, default values, and help text. Includes variables from associated variable sets by default.

Essential for understanding what data to provide when using submit_catalog_request. Variable types include: Single Line Text, Multi Line Text, Select Box, Reference, CheckBox, Date, Yes/No, and more.

List service catalog items from the sc_cat_item table. Supports text search on item name and description, filtering by category, catalog, and active status.

Use this to browse or search for available catalog offerings before getting item details or submitting a request.

Submit a service catalog request using the ServiceNow order_now API. Returns the request (REQ) and request item (RITM) numbers.

IMPORTANT: This creates a real service request on the instance. Use list_catalog_item_variables first to understand what variables are required. Variable values should be passed as a key-value object where keys are the variable names and values are strings. For reference-type variables, pass the sys_id of the referenced record.

Get direct relationships of a CMDB Configuration Item (CI). Returns upstream, downstream, or both relationship directions. Use this for impact analysis, dependency mapping, and understanding CI topology.

Provide the CI sys_id (from cmdb_ci or any CI class table). Optionally filter by relationship type (e.g., 'Depends on::Used by', 'Contains::Contained by').

Traverse the CMDB relationship graph starting from a Configuration Item using breadth-first search. Returns all nodes (CIs) and edges (relationships) discovered up to the specified depth.

Use this for deep impact analysis, service mapping, and understanding the full dependency chain of a CI. Max depth is 5, max nodes is 1000.

Add a new table to an existing code search group, expanding what gets searched. After adding a table, code searches using that group will also search the specified fields on the new table.

Requires the search group's sys_id (get it from list_code_search_groups) and the table name and fields to search.

IMPORTANT: This modifies the code search configuration on the instance. Verify the table name and fields before adding.

Search for code across a ServiceNow instance using the Code Search API. Finds matching scripts, business rules, script includes, and other code artifacts across the platform. Results include the record name, table, field, and matching line numbers with context.

Code Search works through Search Groups, which define sets of tables and fields to search. There is typically a default search group. Use list_code_search_groups to discover available groups, and list_code_search_tables to see which tables a group covers.

Key use cases:

• Find scripts that reference a specific API, table, or pattern

• Locate business rules, script includes, or UI scripts containing specific logic

• Verify whether code has been deployed to an instance

• Search within a specific application scope or table

List available code search groups on a ServiceNow instance. Search groups define which tables and fields are included when performing a code search. Each instance typically has a default search group, and additional groups can be created for specific use cases.

Use the group name as the search_group parameter in code_search. Use the group sys_id when adding tables via add_code_search_table.

List the tables associated with a code search group. These are the tables and fields that are searched when performing a code search with that group.

Use this to understand what a search group covers, or to identify if a specific table is missing and needs to be added via add_code_search_table.

Discover configuration affecting a table: business rules, UI actions, client scripts, UI policies and field actions, server data policies, workflows, flow triggers and generic state models. Defaults to active behavior and applicable ancestors. Returns conditions, timing, provenance and completeness; configuration is not a prediction that anything will execute. Select categories and request scripts/definitions/dependencies immediately when already needed. Flow runtime triggers and design-time definitions are labeled separately. Follow per-category cursors with the same filters; use get_behavior_details for known references or a targeted batch. Empty results describe this account's visibility only.

Read up to 50 known behavior references in one call without rediscovering a table. Pass references from discover_table_behavior or known kind/sourceTable/sysId values. Add details to request scripts, definitions and dependencies immediately; default is compact metadata. Flows accept sourceTable sys_hub_flow with kind flows; subflows, actions, Script Includes and decision tables can also be retrieved. Optional one-level dependency expansion is bounded and labels unresolved calls. Inaccessible and oversized details have explicit warnings and recovery references. This reads configuration only.

List tables on a ServiceNow instance with optional filtering. Returns table name, label, parent class, scope, and whether the table is extendable.

Unlike lookup_table (which searches by name or label keyword), this tool supports browsing with prefix filters, scope filters, and extendable-only mode. Use this to discover tables in a specific scope or browse tables by naming convention.

List ServiceNow platform plugins on an instance. Returns plugin ID, name, version, and active status. Use to discover which plugins are installed/active or to find a specific plugin by name prefix.

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.

Search for ATF (Automated Test Framework) tests on a ServiceNow instance. Find tests by name, description, or category. Returns a list of matching tests with their sys_ids, which can then be passed to the run_atf_test tool for execution.

Use this when you need to discover which ATF tests exist before running them.

Cancel a running or paused flow execution by its context ID. Use this to stop a background flow that is no longer needed, is stuck in a waiting state, or was started by mistake.

IMPORTANT: This is a destructive operation — the flow will be permanently cancelled and cannot be resumed.

Copy an existing ServiceNow Flow Designer flow into a target scoped application. This is the best-practice first step when you want to modify any flow — OOB (out-of-box) and shared flows should not be modified directly. Copying into your application scope first keeps the original intact and gives you a flow you own and can freely modify.

This tool enables the full AI-assisted flow development lifecycle: copy_flow → pull with 'now-sdk transform' → modify → push → test_flow → publish_flow

The copied flow lands in draft/unpublished state in the target scope with a new sys_id, independent of the source. The tool returns the new flow's sys_id and prints the exact 'now-sdk transform' command to pull it locally.

Use list_scoped_apps to find the target_scope sys_id for your application.

Execute a ServiceNow Flow Designer action by scoped name. Actions are the lowest-level building blocks in Flow Designer (e.g., lookup record, create task, send notification).

In foreground mode (default), the call blocks until the action completes and returns outputs directly. Actions typically complete quickly and foreground mode is usually appropriate.

Execute a published ServiceNow Flow Designer flow by scoped name. Runs the flow using sn_fd.FlowAPI via a background script.

In foreground mode (default), the call blocks until the flow completes and returns outputs directly. In background mode, it returns immediately with a context ID that you can poll with get_flow_context_status.

IMPORTANT: Flows with approval or wait steps MUST use background mode — foreground mode will fail if the flow enters a waiting state.

NOTE: This tool requires the flow to be published. If you are iterating and building a flow that may not be published yet, use test_flow instead — it tests the flow in its current draft state, exactly as the 'Test' button in Flow Designer does.

Execute a ServiceNow Flow Designer subflow by scoped name. Subflows are reusable building blocks in Flow Designer — this is the primary tool for testing subflows during development.

In foreground mode (default), the call blocks until the subflow completes and returns outputs directly. In background mode, it returns a context ID for polling with get_flow_context_status.

Pass inputs as key-value pairs matching the subflow's input variables.

Query the current status of a flow execution by its context ID. Use this to poll background flow executions started with execute_flow, execute_subflow, or execute_action in background mode.

Possible states: QUEUED, IN_PROGRESS, WAITING, COMPLETE, CANCELLED, ERROR.

Typical pattern: execute in background -> poll this tool every few seconds -> once COMPLETE, call get_flow_outputs. If ERROR, call get_flow_error.

Retrieve the error message from a failed flow execution by its context ID. Call this after get_flow_context_status shows ERROR to understand why the flow failed.

Returns the flow's error message which can be used to diagnose and fix issues in the flow definition.

Get rich execution details for a flow context: per-action timing, inputs, outputs, and high-level metadata (state, runtime, who ran it, test vs production).

This is the primary diagnostic tool after test_flow or execute_flow — use it to understand what each action did, identify which step failed, inspect inputs and outputs, and iterate on the flow definition.

Uses the ProcessFlow operations API (GET /api/now/processflow/operations/flow/context/{id}), the same endpoint Flow Designer uses to display execution details.

IMPORTANT: Requires flow operations logging to be enabled on the instance. If the execution report is unavailable, the response will include a notice explaining why.

Typical workflow: test_flow → get_flow_execution_details → diagnose → modify flow → test_flow again

Retrieve flow execution log entries from sys_flow_log for a given context.

Log entries include error messages, step-level debug output, and cancellation reasons. Use this alongside get_flow_execution_details to get the full picture of what happened during an execution.

Note: Log entries may be empty for simple successful executions, or if the flow's reporting level is set to NONE. Errors and warnings are always logged regardless of the reporting level setting.

Retrieve outputs from a completed flow/subflow/action execution by its context ID. Only call this after get_flow_context_status shows COMPLETE.

Returns the output name-value pairs defined by the flow/subflow/action.

Test a ServiceNow Flow Designer flow without requiring it to be published. This is the PRIMARY tool to use when building and iterating on a flow — it invokes the same API as the 'Test' button in Flow Designer, running the flow in its current saved (draft) state.

Unlike execute_flow (which requires a published flow and uses sn_fd.FlowAPI), test_flow works on unpublished drafts via the ProcessFlow REST API (POST /api/now/processflow/flow/{id}/test).

Provide the flow's sys_id or scoped name in flow_id, and supply trigger output variable values in output_map. For record-triggered flows this is typically { "current": "<record_sys_id>", "table_name": "" }. Check the flow's trigger configuration in Flow Designer to determine the correct variable names.

The tool returns a context ID on success — use get_flow_context_status to poll the execution, then get_flow_outputs or get_flow_error once complete.

Run a consolidated health check on a ServiceNow instance. Returns version info, cluster node status, stuck scheduled jobs, active semaphore count, and operational counts (open incidents, changes, problems).

Each section can be individually enabled/disabled. Use this to quickly assess the overall health and status of an instance.

Create a new knowledge article in a specified knowledge base. The article is created in 'draft' workflow state by default. Use publish_kb_article to make it visible to end users.

The body content can be provided as HTML (text field) or wiki markup (wiki field). HTML is the more common format.

IMPORTANT: This creates a new article on the instance.

Create a new category in a knowledge base. Requires a label and the knowledge base sys_id. Optionally set a parent category for subcategories.

IMPORTANT: This creates a new category on the instance.

Get the full content of a knowledge article by sys_id, including the HTML body text. Use this when you need to read, review, or extract content from an article.

Get details of a specific knowledge base by sys_id, including the total number of articles and categories. Use this to understand the scope of a KB before browsing its contents.

List knowledge article summaries from the kb_knowledge table. Returns lightweight records without body content for efficiency. Filter by knowledge base, category, workflow state (draft/published/retired), text search on title, or encoded query.

Use get_kb_article to retrieve the full article body content.

List knowledge base categories from the kb_category table. Filter by knowledge base, parent category, active status, or encoded query. Use this to understand a KB's taxonomy before creating or categorizing articles.

List knowledge bases on a ServiceNow instance. Returns knowledge base records from the kb_knowledge_base table with optional filtering by active status and encoded query. Use this to discover available KBs before browsing articles or categories.

Publish a draft knowledge article by setting its workflow_state to 'published'. This makes the article visible to end users who have access to the knowledge base.

IMPORTANT: This makes the article publicly visible. Ensure the content has been reviewed before publishing.

Update an existing knowledge article's fields. Only the fields provided will be modified; all others remain unchanged.

IMPORTANT: This modifies the article on the instance.

Search for ServiceNow applications (scoped apps) and platform plugins by name, scope namespace, or plugin ID. Returns sys_id, name, scope, version, active status, and type for each match.

ServiceNow uses a hierarchical table structure for packages:

• sys_scope: All scoped applications (base table)

  • sys_app: Custom applications in development on this instance

  • sys_store_app: Applications installed from the ServiceNow Store or company app repo

• sys_plugins: Platform plugins

Key use cases:

• Find an application's sys_id to pass as the scope parameter to execute_script (to run scripts within that application's scope)

• Check whether a specific app or plugin is installed/active on the instance

• Look up version, scope namespace, and vendor info for any application or plugin

List or search columns (fields) on a ServiceNow table. Queries the sys_dictionary table to find column names, types, and metadata for a given table.

Use this tool to:

• List all columns on a table to see what fields are available

• Validate a column name before using it in a query or script

• Find the correct internal element name when you only know the display label

• Check column types, whether a field is mandatory, read-only, or a reference

Returns: element name (internal), column label (display), type, max length, reference target, mandatory/read-only/active flags.

Search for ServiceNow tables by name or label. Queries the sys_db_object table to find and validate table names.

Use this tool to:

• Verify a table name exists before using it with query_table or in GlideRecord scripts

• Discover the correct internal name for a table when you only know the display label

• Find related tables (e.g., search "incident" to see incident, incident_alert, etc.)

• Check table hierarchy (which table a table extends)

Returns: table name (internal), label (display), parent table, whether it is extendable, number prefix, and application scope.

Find records matching an encoded query and delete them all. Supports a dry-run mode: set confirm=false (the default) to see how many records would be deleted WITHOUT making changes, then set confirm=true to execute.

IMPORTANT: When confirm=true, this PERMANENTLY DELETES records on the ServiceNow instance. Always run a dry-run first to verify the match count before committing. This operation cannot be undone.

Find records matching an encoded query and update them all with the specified data. Supports a dry-run mode: set confirm=false (the default) to see how many records would be affected WITHOUT making changes, then set confirm=true to execute.

IMPORTANT: When confirm=true, this modifies records on the ServiceNow instance. Always run a dry-run first to verify the match count before committing.

Query the ServiceNow system log (syslog) to check for errors, warnings, and debug output. Returns log entries with timestamps, levels, sources, and messages. Results are ordered newest-first.

Useful for monitoring script execution results, checking for errors after deployments, and debugging issues. Can be called repeatedly to check for new entries. Use the 'syslog' table for system-level logs and 'syslog_app_scope' for scoped application logs.

Query any ServiceNow table using the Table API. Returns records matching the specified criteria. Supports encoded query strings, field selection, and display value resolution.

Use this for general-purpose data retrieval from any table (incident, sys_user, cmdb_ci, change_request, etc.).

Discover the full schema of a ServiceNow table including all fields, types, references, and optionally choice values, relationships, UI policies, and business rules.

Returns the table name, label, parent class, and for each field: name, label, type, maxLength, mandatory, readOnly, referenceTable, and defaultValue.

Key use cases:

• Understand the structure of a table before querying or scripting against it

• Discover reference fields to understand table relationships

• Find choice values for dropdown fields

• Review UI policies and business rules that affect the table

Get detailed explanation of a specific field on a ServiceNow table, including type, constraints, help text, and available choice values.

Use this to understand what a field does, what values it accepts, and how it is configured before reading or writing data.

Validate a catalog item's configuration on a ServiceNow instance. Checks variables for duplicates, missing names, inactive mandatory variables, and UI policy issues.

Returns a valid/invalid flag, error and warning counts, and each issue with its severity, component, sys_id, description, and suggested fix.

Get the currently active application scope on the ServiceNow instance.

List scoped applications (sys_app records) on the instance with optional filtering.

Change the active application scope. Validates the app exists, records previous scope, verifies the change. IMPORTANT: This changes the session's application context.

Pull a script (Script Include, Business Rule, UI Script, UI Action, Client Script) from a ServiceNow instance and save it to a local file. The script content is read from the appropriate table and written to the specified file path.

Supported script types:

• sys_script_include (Script Include)

• sys_script (Business Rule)

• sys_ui_script (UI Script)

• sys_ui_action (UI Action)

• sys_script_client (Client Script)

Push a local script file to a ServiceNow instance, updating the script field on the matching record. The file is read from the specified path and the record is found by name in the appropriate table.

IMPORTANT: This modifies code on the ServiceNow instance. The record must already exist — this updates an existing script, it does not create new ones. Pushing code is refused when the session does not permit running scripts.

Supported script types:

• sys_script_include (Script Include)

• sys_script (Business Rule)

• sys_ui_script (UI Script)

• sys_ui_action (UI Action)

• sys_script_client (Client Script)

Add a comment or work note to any task-based record (incident, change_request, problem, etc.). Comments are customer-visible by default; set is_work_note to true for internal work notes visible only to fulfiller staff.

Approve a change request with optional comments. Sets the approval field to 'approved'. IMPORTANT: This changes the change request's approval status.

Assign a task record to a user and optionally an assignment group. Works on any task-based table (incident, change_request, problem, sc_task, etc.).

Close an incident by setting state to Closed (7). IMPORTANT: This changes the incident state. The incident should typically be in Resolved state before closing, though this depends on instance configuration.

Find a task record by its number (e.g., "INC0010001", "CHG0030002"). Returns the full record if found, or a clear message if not. Use this to look up sys_ids, check current state, or retrieve task details before performing actions like assigning or resolving.

Resolve an incident by setting state to Resolved (6) with resolution notes. IMPORTANT: This changes the incident state. The incident must typically be in an active state (New, In Progress, On Hold) for this to succeed.

Clone an existing update set by creating a new one and copying its records.

WARNING: do not use this to move or promote work. The copy keeps only a few columns of each capture (name, type, target_name, payload, category): it drops application (the copies default to global), action, table, replace_on_upgrade, update_guid and sys_recorded_at, so the clone does not commit like the original. To move a capture use move_update_set_capture; to ship a set, complete it and export_update_set. Use this only when the user asks for a clone knowing that.

Create a new update set, In progress, in the given application. It is not made current: use set_current_update_set for that. IMPORTANT: This creates a new update set on the instance.

Complete an In progress, non-Default update set after checking what it holds: the capture count must equal expected_captures (the number you reviewed, e.g. with inspect_update_set), no other user may be working in it, and every capture must belong to the set's application. The state is read back. A Complete set should not be reopened once another instance retrieved or exported it, so complete only when the work is done and reviewed. If it was the working set, put the previous one back with restore_update_set.

Export an update set to an XML file on this machine, as the platform's Export to XML does: a Complete local set, a batch base with its Complete children, or a Retrieved (Loaded) update set. The file is checked against the set's records before it is written, and a local export's temporary copy on the instance is removed and read back. The XML holds every record's full payload: it is written to the file only (mode 0600), never returned. Only export from a customer instance with the user's say-so.

Move one capture (sys_update_xml) from one In progress set to another In progress, non-Default set of its own application, then read it back. Refused when a newer capture of the same record exists elsewhere, when the target already holds one, or across applications. The reason is appended to the capture's comments.

Put back the working set (application and update set) that set_current_update_set reported as the previous one. If that set has closed meanwhile, the application's Default becomes current instead, and the result says so.

Get the currently active update set for the session.

Inspect an update set's contents — lists all components grouped by type (business rules, script includes, etc.).

List update sets on the instance with optional filtering.

Move records from one update set to another, by sys_id or all records of a source set.

WARNING: this is unverified: any HTTP 200 counts as moved, nothing is read back, and it does not check the same-application rule, newer captures elsewhere, or duplicates in the target. Prefer move_update_set_capture, which checks all of those and reads the move back; if you use this, query sys_update_xml afterwards.

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.

Create a complete ServiceNow workflow from a single specification. Orchestrates: create workflow record -> create version -> create activities -> create transitions -> optionally publish.

Activities are referenced in transitions by their id field (if set) or their array index (as a string like '0', '1', etc.).

IMPORTANT: This creates multiple records on the ServiceNow instance (workflow, version, activities, transitions). Review the specification carefully.

Export a single record from a ServiceNow instance in unload XML format. Uses the /.do?UNL endpoint to generate ServiceNow-native XML that can be imported into another instance or used as a configuration backup.

Common use cases:

• Backing up a Script Include, Business Rule, or other configuration record

• Exporting a record to transfer it to another instance

• Comparing record definitions across instances

• Generating XML for inclusion in an update set

Import XML records into a ServiceNow instance via the sys_upload.do processor. Accepts ServiceNow unload XML format (the output of export_record_xml or update set XML exports).

IMPORTANT: This is a mutative operation that creates or updates records on the instance. Always verify the XML content and target table before importing. Use this for restoring configurations, migrating records between instances, or applying exported record definitions.

Show which tool package this session is running and what other packages exist. Use this when a capability you expected is missing: the tool may exist on the server but be filtered out of this session, in which case the answer is a different MCP_TOOL_PACKAGE rather than a missing feature.

Show what this server permits right now: whether changing instance data (write) and running scripts, flows or tests (execute) are allowed, and which policy layer decided. Reads are never gated. Use it when a tool was refused. The policy is set in the server's environment and cannot be changed from a tool call.