MFA ServiceNow MCP

🌐 English | 🇰🇷 한국어 | 🇯🇵 日本語 | 🇮🇳 हिन्दी | 🇨🇳 简体中文 | 🇪🇸 Español | 🚀 GitHub Pages

MFA-first ServiceNow MCP server. Authenticates via real browser (Playwright) so Okta, Entra ID, SAML, and any MFA/SSO login just works. Also supports API Key for headless/Docker environments.

Table of Contents

• Features

• Setup

• MCP Client Configuration

• Authentication

• Tool Packages

• CLI Reference

• Keeping Up to Date

• Safety Policy

• Performance Optimizations

• Local Source Audit

• Skills

• Docker

• Developer Setup

• Documentation

• Related Projects

• License

Related MCP server: servicenow-mcp

Setup

Two steps: install, then add the server to your MCP client config. No installer command, no per-client flags.

1. Install

The default is uvx — no separate install step, it just runs. For most people this is the whole story.

# macOS/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows PowerShell
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

uvx --refresh --with playwright --from mfa-servicenow-mcp servicenow-mcp --version  # fetch + verify the server
uvx --with playwright playwright install chromium                                   # Chromium for MFA/SSO login

To update — uvx caches the last version it downloaded and keeps reusing it, so a new release has to be pulled in explicitly with --refresh:

uvx --refresh --with playwright --from mfa-servicenow-mcp servicenow-mcp --version
uvx --with playwright playwright install chromium     # a newer Playwright needs a newer Chromium build

If uvx is blocked — pip

Windows Smart App Control stops uvx from running at all: uvx unpacks an unsigned temporary executable on every run, and SAC blocks it. If uvx suddenly stopped working right after a Windows update, this is almost certainly why. Use pip instead:

pip install mfa-servicenow-mcp playwright
python -m playwright install chromium

To update:

pip install --upgrade mfa-servicenow-mcp playwright
python -m playwright install chromium

A Python from the python.org installer (signed, 3.10+) passes SAC as-is. Launch it with python -m servicenow_mcp rather than the servicenow-mcp console script — that script is an unsigned .exe shim pip generates, and SAC blocks it too.

On mac/Linux the one pip caveat is that Homebrew and distro Pythons refuse global installs under PEP 668 (externally-managed-environment). Use the python.org installer, or just stay on uvx.

Installing Chromium up front matters either way. Deferring it to the first tool call means a ~150 MB download racing the MCP host's handshake deadline, which surfaces as connection closed.

Guided setup. Running servicenow-mcp setup with no flags (pip: python -m servicenow_mcp setup) walks you through numbered menus (pick clients and auth type by number or name — no free-text guessing), in English or Korean (auto-detected from your locale; force with SERVICENOW_MCP_LANG=ko|en).

2. Configure your MCP client

Add the server to your client's config file. The env block is identical no matter how you installed — only command/args follow the path you picked above:

Only two env vars are required; MCP_TOOL_PACKAGE defaults to standard, so leave it out unless you need a different package.

Single instance

If you only use one instance, this is all you need.

Claude Code — .mcp.json (project root) / ~/.claude.json (global):

{
  "mcpServers": {
    "servicenow": {
      "command": "uvx",
      "args": ["--with", "playwright", "--from", "mfa-servicenow-mcp", "servicenow-mcp"],
      "env": {
        "SERVICENOW_INSTANCE_URL": "https://your-instance.service-now.com",
        "SERVICENOW_AUTH_TYPE": "browser"
      }
    }
  }
}

If you installed via pip, swap command/args to this — everything else stays the same:

      "command": "python",
      "args": ["-m", "servicenow_mcp"],

Codex — .codex/config.toml (project) / ~/.codex/config.toml (global):

[mcp_servers.servicenow]
command = "uvx"
args = ["--with", "playwright", "--from", "mfa-servicenow-mcp", "servicenow-mcp"]
# pip: command = "python"  /  args = ["-m", "servicenow_mcp"]

[mcp_servers.servicenow.env]
SERVICENOW_INSTANCE_URL = "https://your-instance.service-now.com"
SERVICENOW_AUTH_TYPE = "browser"

OpenCode — opencode.json (project root):

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "servicenow": {
      "type": "local",
      "command": ["uvx", "--with", "playwright", "--from", "mfa-servicenow-mcp", "servicenow-mcp"],
      "enabled": true,
      "environment": {
        "SERVICENOW_INSTANCE_URL": "https://your-instance.service-now.com",
        "SERVICENOW_AUTH_TYPE": "browser"
      }
    }
  }
}

Other clients (Cursor, VS Code, Antigravity, Zed, …) and full env options (auth types, tool packages) are in MCP Client Configuration.

Then restart the client. The first browser tool call opens a window for Okta/Entra ID/SAML/MFA login. Sessions persist — no re-login every time.

Multiple instances (dev / test / prod)

If you work across dev / test / prod, don't stand up several servers. Changing only env lets a single connection handle all of them:

      "env": {
        "SERVICENOW_ACTIVE_INSTANCE": "dev",
        "SERVICENOW_INSTANCE_CONFIG": "{ \"dev\": { \"url\": \"https://acme-dev.service-now.com\", \"auth_type\": \"browser\", \"allow_writes\": true }, \"prod\": { \"url\": \"https://acme.service-now.com\", \"auth_type\": \"browser\" } }"
      }

All that changes is an alias list taking the place of SERVICENOW_INSTANCE_URL; command/args stay the same. What you get:

• Production is protected by default — an alias without allow_writes is read-only. In the example above, prod cannot be written to at all.

• Query another instance without restarting — pass instance to a read tool, as in sn_query(instance="prod", ...).

• Compare across instances — compare_instances puts the same component from dev and prod side by side.

• One login — the browser session is shared across aliases.

The full rules (write routing, gates, ${ENV} references) live in Multiple instances — two approaches. Only reach for B. Multi-process there if the connections have to look separate in your client's UI.

Prefer an AI to do it? Paste into Claude Code / Cursor / Codex / etc.: Install and configure mfa-servicenow-mcp following https://raw.githubusercontent.com/jshsakura/mfa-servicenow-mcp/main/docs/llm-setup.md

If your corporate network blocks the install

TLS-inspecting proxies (Zscaler and friends) and blocked PyPI access have their own path — see Install (offline / corporate).

Features

• Browser authentication for MFA/SSO environments (Okta, Entra ID, SAML, MFA)

• 4 auth modes: Browser, Basic, OAuth, API Key

• 66 registered tools with 6 active package profiles plus disabled none — from minimal read-only to broad bundled CRUD

• 4 workflow skills with safety gates, sub-agent delegation, and verified pipelines

• Streamable HTTP transport — keep stdio as the default, or expose /mcp for HTTP-capable clients and bridges

• Local source audit with HTML report, cross-reference graph, dead code detection, and auto-generated domain knowledge

• Authoritative relationship graphs on disk — _graph.json (widget→Angular Provider, from the live M2M) and _page_graph.json (page→widget, from sp_instance) let the LLM answer dependency questions offline instead of re-querying the instance

• Incremental sync (incremental=True) — re-download only records changed since last sync (sys_updated_on watermark), like git pull; reconcile_deletions=True flags records deleted on the instance

• Cross-scope dep auto-resolve in download_app_sources — pulls global-scope Script Includes, Widgets, Angular Providers, and UI Macros that the app references, so the local bundle is self-contained for analysis

• Attachment download (download_attachment) — fetch a record's attachment file(s) (xlsx, PDF, Word, …) to local disk by attachment sys_id or by parent table+record; resolves a record's attachments automatically and writes bytes to disk so the LLM reads them from saved_path

• Dry-run preview on every write tool (dry_run=True) — returns field-level diff, dependency counts, and precision notes before any side effect. Uses read-only APIs, works under all auth modes.

• Write intent gate: every mutation requires an explicit confirm='approve' (accidental-write guardrail, not an adversarial boundary — see Safety Policy)

• Payload safety limits, per-field truncation, and total response budget (200K chars)

• Transient network error retry with backoff

• Tool packages for core, standard, service desk, portal developers, and platform developers — full available for advanced users (see warning)

• Developer productivity tools: activity tracking, uncommitted changes, dependency mapping, daily summary

• Full coverage of core ServiceNow artifact tables (see Supported Tables)

• CI/CD with auto-tagging, PyPI publishing, and Docker multi-platform builds

Supported ServiceNow Tables

Install (offline / corporate)

For most users the Setup above (uvx) is all you need. Two corporate-network cases are worth calling out.

The common case is PyPI reachable, but HTTPS is TLS-inspected (Zscaler / Netskope / corporate MITM) — that is what the section below covers.

If PyPI itself is blocked outright, neither uvx nor pip can reach the package. Ask your IT team to allowlist pypi.org and files.pythonhosted.org, or to mirror the package on an internal index you can point pip install --index-url at.

Installing behind a TLS-inspecting proxy (Zscaler etc.)

Use this when PyPI is reachable but a TLS-inspecting proxy re-signs HTTPS, so installs and runtime calls fail with SSL: CERTIFICATE_VERIFY_FAILED. Registering the proxy's root CA in the OS trust store is not enough — Python (pip, requests, httpx), curl_cffi, and Playwright each ship their own CA bundle (certifi / libcurl / node) and ignore the OS store unless you point them at the cert via env.

1. Get the proxy root CA as a PEM file (ask IT, or export it from the OS keychain). Assume it lands at /etc/ssl/zscaler-root.pem (Windows: C:\certs\zscaler-root.pem).

2. Install — point the installer at the cert:

pip install --cert /etc/ssl/zscaler-root.pem mfa-servicenow-mcp
python -m playwright install chromium     # NODE_EXTRA_CA_CERTS (step 3) covers its download

Prefer uvx? uv can use the OS trust store directly (where the proxy CA is already registered):

UV_NATIVE_TLS=1 uvx --with playwright --from mfa-servicenow-mcp servicenow-mcp --version

3. Runtime — set the CA path in your MCP client env. The non-obvious part: live ServiceNow calls go through curl_cffi (libcurl), which reads CURL_CA_BUNDLE — not REQUESTS_CA_BUNDLE. Set all of them so every layer trusts the proxy:

{
  "mcpServers": {
    "servicenow": {
      "command": "python",
      "args": ["-m", "servicenow_mcp"],
      "env": {
        "SERVICENOW_INSTANCE_URL": "https://your-instance.service-now.com",
        "SERVICENOW_AUTH_TYPE": "browser",
        "CURL_CA_BUNDLE": "/etc/ssl/zscaler-root.pem",
        "REQUESTS_CA_BUNDLE": "/etc/ssl/zscaler-root.pem",
        "SSL_CERT_FILE": "/etc/ssl/zscaler-root.pem",
        "NODE_EXTRA_CA_CERTS": "/etc/ssl/zscaler-root.pem"
      }
    }
  }
}

In a fully-inspected network the proxy re-signs every host, so the single proxy-root PEM covers all HTTPS. If some hosts bypass the proxy, concatenate the proxy root with certifi's bundle (python -m certifi prints its path) into one PEM and point the env vars at that.

Last resort if you genuinely can't obtain the PEM: pip install --trusted-host pypi.org --trusted-host files.pythonhosted.org mfa-servicenow-mcp skips verification for the install only — it does nothing for runtime ServiceNow calls, which still need CURL_CA_BUNDLE. Prefer the cert path; --trusted-host disables a security control.

MCP Client Configuration

Recommended: use Setup above. Use the copy-paste configs below when you need to inspect, repair, or hand-manage a client config file.

Each project can connect to a different ServiceNow instance. Set the config in your project directory so each project has its own instance URL and credentials.

Copy-paste configs for each client: Client Setup Guide

SERVICENOW_USERNAME / SERVICENOW_PASSWORD are optional — they prefill the MFA login form. On Windows, set these as system environment variables.

Profiles vs. multi-process

The examples above are single-instance — that stays the default. With more than one instance there are two ways to go, and it's worth picking one before you configure anything:

Most people want A. Write safety is already solved there — leave allow_writes off a prod alias and it's read-only, and writes to a non-active instance have to clear the confirm_instance gate. On top of that, only A gives you cross-instance comparison and a single login.

Pick B only when the connections need to be visibly separate in the client UI. Tool names come through as mcp_snow-prd_*, so a human tells them apart at a glance. The cost is three logins, no comparison, and three copies of the config. Details: Telling multiple connections apart.

A. Profiles

To switch between several instances from one client, list them in SERVICENOW_INSTANCE_CONFIG (alias → settings) and pick the active one with SERVICENOW_ACTIVE_INSTANCE. Each alias can carry its own credentials (username / password / auth_type / api_key); ${ENV} references keep secrets out of the JSON. The single-instance SERVICENOW_INSTANCE_URL form still works as a fallback.

{
  "mcpServers": {
    "servicenow": {
      "command": "uvx",
      "args": ["--with", "playwright", "--from", "mfa-servicenow-mcp", "servicenow-mcp"],
      "env": {
        "MCP_TOOL_PACKAGE": "standard",
        "SERVICENOW_ACTIVE_INSTANCE": "dev",
        "SERVICENOW_INSTANCE_CONFIG": "{ \"dev\": { \"url\": \"https://acme-dev.service-now.com\", \"auth_type\": \"browser\", \"username\": \"dev_user\", \"password\": \"${SERVICENOW_DEV_PASSWORD}\", \"allow_writes\": true }, \"test\": { \"url\": \"https://acme-test.service-now.com\", \"auth_type\": \"browser\", \"username\": \"test_user\", \"password\": \"${SERVICENOW_TEST_PASSWORD}\" } }"
      }
    }
  }
}

SERVICENOW_ACTIVE_INSTANCE is where writes default; read tools peek at the others with instance="test", and a single write can be routed to a non-active instance with instance="test" confirm_instance="test" confirm="approve" (guarded, and verified after it lands). Full rules (write routing, gating, comparison, ${ENV}): Multi-Instance Mode.

B. Multi-process

Only worth it when you want the connections split apart in the client UI. Each entry pins one instance and gets its own name via --server-name:

{
  "mcpServers": {
    "snow-dev": {
      "command": "uvx",
      "args": ["--with", "playwright", "--from", "mfa-servicenow-mcp", "servicenow-mcp", "--server-name", "snow-dev"],
      "env": {
        "SERVICENOW_INSTANCE_URL": "https://acme-dev.service-now.com",
        "SERVICENOW_AUTH_TYPE": "browser"
      }
    },
    "snow-prd": {
      "command": "uvx",
      "args": ["--with", "playwright", "--from", "mfa-servicenow-mcp", "servicenow-mcp", "--server-name", "snow-prd"],
      "env": {
        "SERVICENOW_INSTANCE_URL": "https://acme.service-now.com",
        "SERVICENOW_AUTH_TYPE": "browser",
        "MCP_TOOL_PACKAGE": "standard"
      }
    }
  }
}

Tool names are then pinned to mcp_snow-dev_* / mcp_snow-prd_*. Drop --server-name and both advertise themselves as ServiceNow, so the client numbers them by load order (mcp_servicenow, mcp_servicenow2) — and that numbering can shift between restarts, which means you can never trust which one is production.

To keep the production connection read-only, give it a read-only MCP_TOOL_PACKAGE. Unlike A, there is no allow_writes alias gate here — the tool package is the only thing blocking writes.

Login prompts come up per process, and cross-instance tools like compare_instances are unavailable — each process only knows its own instance. If that bites, go with A.

Authentication

Choose the auth mode based on your ServiceNow environment.

Browser Auth (MFA/SSO) — Default

The Setup command uses browser auth by default. Optional flags:

Login sharing across hosts and instances — how it actually works

The server caches two things under ~/.mfa_servicenow_mcp/: the Playwright profile (Chromium SSO cookies) and a session JSON (parsed cookies reused on the next start). Both are scoped per instance + username — files are named profile_<host>_<user> and session_<host>_<user>.json.

That scoping does two things for you automatically, with no configuration:

• Multiple hosts share one login. Claude Code and Codex on the same machine both resolve ~/.mfa_servicenow_mcp/, so whichever logs in first writes the session and the other reuses it — no second MFA prompt.

• Different instances / different credentials stay isolated. Each instance+user gets its own profile and session file, so dev and test (or two accounts) never collide. For multiple instances, configure them in SERVICENOW_INSTANCE_CONFIG (JSON) — each alias gets its own scoped cache; you do not manage this with a profile path.

Do not set SERVICENOW_BROWSER_USER_DATA_DIR to "share" logins. It overrides the profile path verbatim — the per-instance scoping is bypassed, so every instance you run is forced into one Chromium profile and their cookies collide. The only legitimate use is a narrow one: a sandboxed host (e.g. Claude Desktop on macOS) that remaps HOME to a container path, so its ~/.mfa_servicenow_mcp/ no longer matches the terminal's. In that single-instance case, point the sandboxed host at the real home path:

# Only when a sandbox remapped HOME, and only for a single-instance host
export SERVICENOW_BROWSER_USER_DATA_DIR="/Users/you/.mfa_servicenow_mcp/profile_acme"

If you run more than one instance, leave this unset and let the per-instance scoping do its job.

Basic Auth

Use this for PDIs or instances without MFA.

python -m servicenow_mcp \
  --instance-url "https://your-instance.service-now.com" \
  --auth-type "basic" \
  --username "your_id" \
  --password "your_password"

OAuth

Current CLI support expects OAuth password grant inputs.

python -m servicenow_mcp \
  --instance-url "https://your-instance.service-now.com" \
  --auth-type "oauth" \
  --client-id "your_client_id" \
  --client-secret "your_client_secret" \
  --username "your_id" \
  --password "your_password"

If --token-url is omitted, the server defaults to https://<instance>/oauth_token.do.

API Key

python -m servicenow_mcp \
  --instance-url "https://your-instance.service-now.com" \
  --auth-type "api_key" \
  --api-key "your_api_key"

Default header: X-ServiceNow-API-Key (customizable with --api-key-header).

Tool Packages

MCP_TOOL_PACKAGE controls which tools the server exposes. Default: standard — no config needed for most users.

Read-only (safe defaults):

⚠️ Write-capable (advanced — grants create/update/delete):

~Tokens is the approximate footprint each package's tool schemas add to the model's context per request (measured with tiktoken cl100k_base over the server's compacted schemas; actual Claude counts vary slightly). Staying on the narrowest package keeps the context budget — and cost — down.

Each server process binds to one active ServiceNow instance for ordinary tools. A write to a different configured instance is possible per call, but only through an explicit, guarded acknowledgement (below) — never a silent switch.

Multi-Instance Mode (comparison + guarded single-call writes)

When you need to compare dev/test/prod or deploy to a chosen one, opt into named instances with SERVICENOW_INSTANCE_CONFIG. SERVICENOW_ACTIVE_INSTANCE is still required.

Two things are global, one is per-instance:

• Tool surface is global — set once with MCP_TOOL_PACKAGE. Only one instance is ever active per server process, so there is no per-instance tool package.

• Write permission is per-instance — each alias carries allow_writes. It is enforced at call time against the active instance: a write tool can be loaded but still refused if the active instance has allow_writes: false. Writes are opt-in: omit allow_writes and the instance is read-only.

• Credentials are per-instance with global fallback — put username / password / api_key (and auth_type) on an alias to override; omit them and the alias inherits the global SERVICENOW_USERNAME / SERVICENOW_PASSWORD / etc. So if every instance shares one login, set it once globally and leave the alias entries credential-free.

Other rules:

• Read tools accept an instance argument to run a single read against a non-active instance — e.g. sn_query(instance="test", table="incident", ...) or sn_health(instance="test") while dev stays active. Every read tool in your package exposes it in its schema (enum of configured aliases). This is how you peek at another instance's data without restarting.

• A single write can be routed to a non-active instance, but never silently. Pass instance="test" confirm_instance="test" confirm="approve" (target named twice — as intent and acknowledgement) and the target must have allow_writes=true. Only that one write goes there; the active instance is restored immediately after. A target/confirm mismatch or a read-only target is refused with an explicit message, so a dev/test/prod mix-up cannot land on the wrong instance. The write is then re-read on the target and reported as landed (or WRITE_NOT_LANDED), with target_instance echoed — "success" means the content is confirmed present on the intended instance, not just a 200.

• list_instances reports configured aliases plus the active one and each one's write flag. compare_instances performs read-only table comparisons across aliases.

• Switching the default active instance requires restarting the MCP client — it is read once at server startup, not refreshed live. (Per-call instance= routing above does not need a restart.)

Example — shared global login, per-instance write gating:

export MCP_TOOL_PACKAGE=standard
export SERVICENOW_USERNAME=svc_account
export SERVICENOW_PASSWORD='...'
export SERVICENOW_ACTIVE_INSTANCE=dev
export SERVICENOW_INSTANCE_CONFIG='{
  "dev":  { "url": "https://acme-dev.service-now.com",  "allow_writes": true },
  "test": { "url": "https://acme-test.service-now.com", "allow_writes": true },
  "prod": { "url": "https://acme-prod.service-now.com", "allow_writes": false }
}'

To give an instance its own login instead, add the fields to that alias (a ${ENV} reference is resolved, so you can keep secrets out of the JSON):

"prod": { "url": "https://acme.service-now.com", "username": "prod_user", "password": "${SERVICENOW_PROD_PASSWORD}" }

Use compare_instances for dev/test drift checks. For promoting MANY records (especially Service Portal / scoped tables), prefer an Update Set (commit on source, retrieve + commit on target in the UI) over per-record cross-instance writes — it bypasses the per-table/SP ACLs that single Table-API writes hit.

If a tool is not available in your current package, the server tells you which package includes it.

For the full reference (all packages, inheritance details, config syntax): Tool Packages Advanced Guide.

CLI Reference

Server Options

HTTP transport example:

servicenow-mcp --transport http --http-host 127.0.0.1 --http-port 8000

The MCP endpoint is http://127.0.0.1:8000/mcp; /health returns a lightweight health response.

Telling multiple connections apart (--server-name)

If you register several server entries in one client (dev / stg / prd as separate processes), they all default to the name ServiceNow, so the client disambiguates them by load order — mcp_servicenow, mcp_servicenow2, mcp_servicenow3. That numbering can change between restarts, which makes it untrustworthy for telling which one is production. Name each connection instead:

servicenow-mcp --server-name snow-prd          # uvx / console script
python -m servicenow_mcp --server-name snow-prd # pip

The tool namespace is then pinned to mcp_snow-prd_*. SERVICENOW_MCP_SERVER_NAME does the same thing as an env var, and the flag wins if both are set. Unset, it stays ServiceNow, so existing configs keep working.

Looking to switch instances inside one server instead? That's Multi-Instance Mode, not this. The two are unrelated — --server-name is the name the client sees, while a multi-instance alias names an instance inside a single process.

Basic Auth

OAuth

API Key

Script Execution

Keeping Up to Date

Pick the one matching how you installed (the same commands are in the Install section):

# uvx — it caches the last version it downloaded, so --refresh is how you pull a new one
uvx --refresh --with playwright --from mfa-servicenow-mcp servicenow-mcp --version
uvx --with playwright playwright install chromium

# pip
pip install --upgrade mfa-servicenow-mcp playwright
python -m playwright install chromium

Chromium gets refreshed alongside in both cases because a newer Playwright wants a different Chromium build (see below).

After refreshing, restart your MCP client (Claude Code, Cursor, etc.) to load the new version.

Check the current version:

uvx --from mfa-servicenow-mcp servicenow-mcp --version   # uvx
python -m servicenow_mcp --version                       # pip

Why Chromium has to be installed up front

A new Playwright release wants a different Chromium build. Left alone, the first browser tool call has to fetch ~150 MB of browser binaries — which on a slow link blows past the MCP host's handshake timeout and surfaces as:

MCP startup failed: handshaking with MCP server failed: connection closed: initialize response

That's why the upgrade commands above run playwright install chromium every time.

Why we no longer auto-install Chromium inside the MCP server: that download used to run during the first tool call. On a slow link the subprocess outlived the host's handshake deadline and the client reported "connection closed". v1.13.1 changed this — the MCP server now only warns if Chromium is missing. Install it ahead of time (out-of-band, no handshake timer).

Safety Policy

All mutating tools require an explicit confirm='approve' argument.

Rules:

1. Mutating tools with prefixes such as create_, update_, delete_, remove_, add_, move_, activate_, deactivate_, commit_, publish_, submit_, approve_, reject_, resolve_, reorder_, and execute_ require confirmation.

2. You must pass confirm='approve'.

3. Without that parameter, the server rejects the request before execution.

This policy applies regardless of the selected tool package.

What this gate is — and is not. The server enforces confirm='approve' before any write, but the argument is supplied by the same LLM that issued the call. So the gate is an intent checkpoint that stops accidental or ambiguous mutations — it forces a deliberate, auditable "yes" and a preview hint. It is not a defense against a determined or prompt-injected agent, which can simply include confirm='approve'. Treat it as guardrails, not a security boundary: review what a tool will do before approving, run against a least-privilege ServiceNow account, and do not rely on confirmation alone in adversarial settings. For high-stakes automation, add out-of-band approval.

Write Guards

Beyond the confirm gate, every write runs through deterministic guards that block unsafe writes before they reach ServiceNow. The concurrent-edit and duplicate-create checks run after the confirm gate, so an unconfirmed write never touches the network. Each guard fails open on a denied/failed pre-read — it never blocks a legitimate write just because it couldn't look first. The intent is simple: you should never be able to silently clobber a teammate's change — if someone else touched the record, the write stops and tells you, rather than overwriting and moving on.

Fail-open vs fail-closed. The default (fail-open) favors availability: if the pre-write audit read cannot run (network error, ACL denial, 5xx), the write proceeds. That means the concurrent-edit guard can silently no-op exactly when the instance is unreachable. Security-sensitive deployments can set SERVICENOW_WRITE_GUARDS_FAIL=closed so a guard that could not verify blocks instead — trading availability for the guarantee that a lost-update check never silently passes. Scoped to genuine read failures; a successful read that finds no conflict still proceeds.

Disable the whole layer with SERVICENOW_WRITE_GUARDS=off. In multi-instance mode, every write response also carries an instance_target field (and reads routed elsewhere an instance_source) so the instance a call hit is always visible.

Portal Investigation Safety

Portal investigation tools are conservative by default:

• search_portal_regex_matches starts with widget-only scanning, linked expansion off, and small default limits.

• trace_portal_route_targets is the preferred follow-up for compact Widget -> Provider -> route target evidence.

• download_portal_sources does not pull linked Script Includes or Angular Providers unless explicitly requested.

• Large portal scans are capped server-side and return warnings when the request exceeds safe defaults.

Pattern matching modes:

Performance Optimizations

The server includes several layers of performance optimization to minimize latency and token usage.

Serialization

• orjson backend: All JSON serialization uses json_fast (orjson when available, stdlib fallback). 2-4x faster than stdlib json for both loads and dumps.

• Compact output: Tool responses are serialized without indentation or extra whitespace, saving 20-30% tokens per response.

• Double-parse avoidance: serialize_tool_output detects already-compact JSON strings and skips re-serialization.

Caching

• OrderedDict LRU cache: Query results are cached with O(1) eviction using OrderedDict.popitem(). 256 max entries, 30-second TTL (600s for stable metadata: schema/scope/choice tables), thread-safe.

• Tool schema cache: Pydantic model_json_schema() output is cached per model type, avoiding repeated schema generation.

• Lazy tool discovery: Only tool modules required by the active MCP_TOOL_PACKAGE are imported at startup. Unused modules are skipped entirely.

Network

• Browser-grade TLS by default: The HTTP layer routes through curl_cffi with a Chrome impersonation profile (chrome120 by default), so the TLS handshake is byte-for-byte like a real browser — instances behind Cloudflare/Akamai or JA3 bot-detection that reject stock Python requests work with no extra config. Opt out with SERVICENOW_TLS_IMPERSONATE=off.

• Session keep-alive (browser auth): While you're actively working, a background thread pings the instance every 5 minutes with the same lightweight probe the restore path uses, so ServiceNow's sliding idle timeout never kills the session between tool calls — no more surprise MFA windows after a lunch break. It never opens a browser (a dead session just waits for the next real call to re-auth), stops after 6 hours without real activity, and is tunable via SERVICENOW_SESSION_KEEPALIVE=off, SERVICENOW_SESSION_KEEPALIVE_INTERVAL_S (default 300, min 60), and SERVICENOW_SESSION_KEEPALIVE_MAX_IDLE_S (default 21600).

• HTTP session pooling: Persistent session with TCP keep-alive and gzip/deflate compression (60-80% payload reduction on large JSON). The stock-requests opt-out path mounts a 20-connection HTTPAdapter.

• Parallel pagination: sn_query_all fetches the first page sequentially for total count, then retrieves remaining pages concurrently via ThreadPoolExecutor (up to 4 workers).

• Dynamic page sizing: When remaining records fit in a single page (<=100), the page size is enlarged to avoid extra round-trips.

• Batch API: sn_batch combines multiple REST sub-requests into a single /api/now/batch POST, with automatic chunking at the 150-request limit.

• Parallel chunked M2M queries: Widget-to-provider M2M lookups split into 100-ID chunks are executed concurrently rather than sequentially.

Schema & Startup

• Shallow-copy schema injection: Confirmation schema (confirm='approve') is injected via lightweight dict copy instead of copy.deepcopy, reducing list_tools overhead.

• No-count optimization: Subsequent pagination pages use sysparm_no_count=true to skip server-side total count computation.

• Payload safety: Heavy tables (sp_widget, sys_script, etc.) have automatic field clamping and limit restrictions to prevent context window overflow.

Local Source Audit

Download and analyze your entire ServiceNow application locally — no repeated API calls, no context waste.

Step 1: download_app_sources(scope="x_company_app")    → All server-side code + cross-scope deps to disk
Step 2: audit_local_sources(source_root="temp/...")     → Analysis + HTML report

Step 1 runs auto_resolve_deps=True by default: after the in-scope download it scans every .js/.html/.xml file and fetches any referenced sys_script_include, sp_widget, sp_angular_provider, or sys_ui_macro records not already in the bundle — no matter what scope they live in. Pulled deps are saved into the same tree with "is_dependency": true in their _metadata.json, so the audit in Step 2 sees the complete call graph. Set auto_resolve_deps=False if you only want in-scope records.

Tip — pull a whole scope, including global: pass scope="global" to dump every global-scope record, or keep your app scope and let auto_resolve_deps reach into global for the records you actually reference. Either way the local bundle is self-contained, so analysis runs entirely offline against disk.

Incremental Sync

Re-downloading a large app on every run is slow and risks timeouts. Pass incremental=True to fetch only what changed since the last download — like git pull instead of a fresh clone. Works on both download_app_sources and download_portal_sources.

download_app_sources(scope="x_company_app")                      # 1st run: full download
download_app_sources(scope="x_company_app", incremental=True)    # later: changed records only

• How it works: the first download records each record's sys_updated_on into _sync_meta.json. On an incremental run, every source family queries sys_updated_on >= <latest seen> (server-side timestamps, no clock skew), re-downloads just those records, and leaves unchanged local files untouched.

• Deletions: timestamp deltas can't see deleted records. Add reconcile_deletions=True to list records present locally but gone on the instance — reported as warnings under deletion_candidates, never deleted automatically.

• First run / no prior data: falls back to a full download automatically.

• Run a full (non-incremental) download periodically to stay fully in sync.

Download Safety & Completeness

The download is the source of truth for offline analysis, so it is built to be deterministic and to never look complete when it isn't:

• Scope auto-resolution. Pass the app namespace (x_company_app), its display name ("My App"), or a sys_scope sys_id — all resolve to the canonical namespace, so the local folder (temp/<instance>/<namespace>/) and every query are identical every run. The resolved value is echoed as scope_resolution.

• No silent caps. If a source family hits max_records_per_type, it is flagged loudly: a per-family capped: true in source_types, the family in incomplete_types, and a top-level complete: false. A truncated download can never masquerade as a full one.

• Cross-instance / stale guards. Pushing back (update_remote_from_local) checks the local tree's recorded origin against the connected instance; a resume re-download that keeps a stale local copy preserves the real sync watermark and warns instead of hiding the drift.

• Relationship metadata at download time. Widget→Angular-Provider edges (_graph.json) and widget→CSS/JS-dependency edges (_dependency_graph.json) are captured from the live M2M tables during the portal download — analysis reads the real graph instead of guessing from code.

• Transitive dependency depth. Cross-scope deps resolve 2 passes deep by default (conservative). Raise with SERVICENOW_DEP_MAX_DEPTH (clamped to 1–6) to chase longer A→B→C→D chains.

• One-call graph build. Pass build_graph=True to download_app_sources to run the offline relationship audit right after the download — no extra API cost.

• Create → local sync nudge. When you create a widget/page on the instance and a local tree exists for that scope, the create response adds a local_out_of_sync message with the exact download_portal_sources(...) command to pull the new record into local. It never writes local files for you.

What Gets Generated

Individual Download Tools

Use the orchestrator for a full dump, or download_server_sources for a targeted single-family refresh:

All downloads write full source to disk with zero truncation. Only a summary is returned to the LLM context.

Skills

Tools are raw API calls. Skills are what make your LLM actually useful — verified pipelines with safety gates, rollback, and context-aware sub-agent delegation. MCP server + skills is the complete setup for LLM-driven ServiceNow automation.

4 skills today, more coming with every release.

Install Skills

# Claude Code
uvx --from mfa-servicenow-mcp servicenow-mcp-skills claude

# OpenAI Codex
uvx --from mfa-servicenow-mcp servicenow-mcp-skills codex

# OpenCode
uvx --from mfa-servicenow-mcp servicenow-mcp-skills opencode

# Antigravity
uvx --from mfa-servicenow-mcp servicenow-mcp-skills antigravity

The installer downloads the skill files from this repository's skills/ directory and places them in a project-local LLM directory. No authentication or configuration needed.

If servicenow-mcp-skills is blocked by security policy on Windows, call it as a module instead — same behavior:

python -m servicenow_mcp.setup_skills claude

How it works: Each skill is a standalone Markdown file with YAML frontmatter (metadata) and pipeline instructions. The LLM client reads these files from the install path and exposes them as callable commands or skill triggers.

Update: Re-run the same install command — it replaces all existing skill files (clean install, no merge).

Remove skills only: delete the skill install directory manually (for example rm -rf .claude/commands/servicenow/).

Skill Categories

Skill Metadata

Each skill includes metadata that helps LLMs optimize execution:

context_cost: low|medium|high    # → high = delegate to sub-agent
safety_level: none|confirm|staged # → staged = mandatory diff/preview/apply
delegatable: true|false           # → can run in sub-agent to save context
triggers: ["위젯 분석", "analyze widget"]  # → LLM trigger matching

For the full skill reference, see skills/SKILL.md.

MCP Resources (Built-in Skill Guides)

Skills are also exposed as MCP resources directly from the server — no client-side installation required. Any MCP-compliant client can discover and read them on demand.

# List available skill guides
list_resources → skill://manage/local-sync, skill://manage/app-source-download, ...

# Read a specific guide
read_resource("skill://manage/local-sync") → full pipeline with safety gates

Tools that have a matching skill guide show a → skill://... hint in their description. The guide content is pull-based — zero token cost until the client actually reads it.

Docker

API Key auth only (MFA browser auth requires GUI, not available in containers).

docker run -it --rm \
  -e SERVICENOW_INSTANCE_URL=https://your-instance.service-now.com \
  -e SERVICENOW_AUTH_TYPE=api_key \
  -e SERVICENOW_API_KEY=your-api-key \
  ghcr.io/jshsakura/mfa-servicenow-mcp:latest

See Client Setup Guide for local build options.

Developer Setup

If you want to modify the source locally:

git clone https://github.com/jshsakura/mfa-servicenow-mcp.git
cd mfa-servicenow-mcp

uv venv
uv pip install -e ".[browser,dev]"
uvx --with playwright playwright install chromium

Running Tests

uv run pytest

Linting & Formatting

uv run black src/ tests/
uv run isort src/ tests/
uv run ruff check src/ tests/
uv run mypy src/

Building

uv build

Windows: see Windows Installation Guide

Documentation

• LLM Setup Guide — AI-guided one-line installation flow

• Client Setup Guide — Installer-first setup plus fallback client configs

• Tool Inventory — Complete tool list by category and package

• Windows Installation Guide

• Catalog Guide — Service catalog CRUD and optimization

• Change Management — Change request lifecycle and approval

• Workflow Management — Workflow (wf_workflow engine) and Flow Designer tools

• Korean README

Related Projects and Acknowledgements

• This repository includes tools consolidated and refactored from earlier internal / legacy ServiceNow MCP implementations. The current surface is organized around bundled manage_* tools (see tool_utils.py).

• This project is focused on safe, diff-first MCP server use cases: every write goes through confirm + write-guards (concurrent-edit, duplicate-create, publish, Flow Designer), and source edits are diffed against the live remote before they are pushed.

License

Apache License 2.0