MCP field guide / ServiceNow

// mcp field guide · enterprise / itsm

ServiceNow MCP server

On an enterprise ITSM platform, a "write" is rarely a leaf change — it propagates through business rules, flows, SLAs, notifications and approvals. So the blast radius exceeds the record edit. The strong guard targets are specific: approving/executing a change request, deploying a script, deleting records, and altering group membership — actions that reach real production process.

Official: MCP Server Console (GA, Zurich → Australia) Community: echelon-ai-labs/servicenow-mcp (MIT)

READS

WEAK

Query incidents, changes, CMDB, catalog, KB. No state change (PII-exposure aside).

RECORD WRITES

MODERATE

Create/update incident, comment, assign — reversible, but each fires automation, SLAs, notifications.

EXECUTE / DELETE / DEPLOY

STRONG

Approve/execute change, delete records, deploy scripts/changesets, change membership.

Two servers

Official — ServiceNow MCP Server Console (native, GA in the Zurich release). Admins package platform capabilities — Now Assist Skills, Knowledge Graph, Subflows/Actions, Scripted REST APIs — as MCP tools, with OAuth auth and AI-Control-Tower governance. Its tools are admin-defined per instance, so exact names are instance-specific (unverified as a fixed set); a tool wrapping a Scripted REST API or Subflow can execute arbitrary server-side logic.1 Community — echelon-ai-labs/servicenow-mcp (Python, MIT) is the most-used standalone server, connecting over ServiceNow's REST/Table APIs with verified tool names.2

Tools by risk surface (community server, verified names)

TierTools
read-onlylist_incidents, get_record, search_records, perform_query, list_change_requests, get_change_request_details, list_catalog_items, list_articles, get_article, list_users, list_script_includes
mutatingcreate_incident, update_incident, add_comment, add_work_notes, resolve_incident, create_change_request, catalog/KB writes (create_article, publish_article), user/group writes
destructive / executesubmit_change_for_approval, approve_change, reject_change; deletes (delete_workflow, delete_script_include, delete_story); create/update_script_include (server-side JS), commit_changeset, publish_changeset; add/remove_group_members

Why the "mutating" tier is heavier than it looks: a leaf record write here rarely stops at the record. update_incident, resolve_incident, and assignment changes fire business rules, flows, SLAs, and notifications. So a guard should treat writes touching users/groups, published KB, or catalog as more than plain CRUD.

Real use cases

Incident triage. Query open incidents, add work notes, resolve — from natural language.

Change management assist. Draft a change request, add change tasks, route for approval (a human decides).

KB / catalog ops / low-code dev. Create/publish articles, tune catalog items, manage script includes and changesets.

Where a human-approval guard fits

Reads → weak. list_*/get_*/search_records don't change state (PII-exposure is a policy concern, not a mutation gate).

Record writes → moderate. Individually reversible, but each can trigger downstream automation — approval matters more than in a plain CRUD app.

Execute / delete / deploy → strong. This is where the guard earns its keep:

The framing: because a ServiceNow mutation propagates through automation, the guard's job is to hold the calls whose consequence reaches production process — approval/execution, script deployment, deletes, entitlement changes — and let the read-heavy majority flow. Gate the dangerous subset.

Gate the change execution, not the query

ChronoMCP passes reads through and holds change approval/execution, script deploys and deletes for a human — with a tamper-evident record for audit.

Read the quickstart → More MCP profiles

Sources

  1. ServiceNow — MCP Server Console docs (GA, Now Assist Skills / Scripted REST / Subflows as tools): servicenow.com — MCP Server Console
  2. Community — echelon-ai-labs/servicenow-mcp (verified tool names, MIT): github.com/echelon-ai-labs/servicenow-mcp

Profiles describe third-party software from its public sources; ChronoMCP is not affiliated with ServiceNow, and the community server is an independent, unofficial project. The official console's tools are admin-defined per instance (names unverified as a fixed set). Community tool names are as documented in the repo README. Risk groupings are our classification. Sources current as of Aug 2026 — check the source links.