The integration problem nobody wants to keep solving
Cross-instance ServiceNow integrations can devolve into point-to-point implementations — one connector per AI vendor, per target instance. Ten AI tools across five ServiceNow instances can produce up to fifty distinct connector configurations. From projects I've worked on: API changes, credential rotations, and vendor updates grow the maintenance surface; authentication, logging, rate limiting, and permission checks get re-implemented per connector; and without a centralized governance and observability layer, the question "which agent did what, against which instance, under which identity?" rarely has a single, consistent answer across teams. Your mileage may vary — this is an observation, not a measurement.
This is the N×M integration problem: N AI agents multiplied by M enterprise systems produces a brittle, duplicated integration matrix. Add cross-instance scenarios (Instance A → Instance B) and the second credential perimeter makes reuse nearly impossible without custom middleware.
ServiceNow's Zurich release introduces a native MCP Server Console for publishing MCP Tools. OAuth-based authentication is configured per server through the Machine Identity Console / inbound integrations. AI Control Tower helps govern and observe MCP server usage on the instance.
Why MCP matters now
❌ BEFORE MCP (illustrative): An AI agent that wants to create an incident on Instance B has to integrate against ServiceNow's Table API or a custom Scripted REST endpoint, manage a per-instance credential, encode field semantics in code, and re-author the integration for the next AI vendor or the next target instance. The agent owns the integration burden in this pattern, and the burden grows with each new instance and AI tool added.
✅ AFTER MCP: Instance B publishes its capabilities once as governed MCP Tools. The agent reasons over an abstract create_incident tool with a JSON schema and a description. It does not know Instance B's REST APIs, its tables, or its scope conventions. Any MCP-compliant client (for example, Claude or Microsoft Copilot), alongside ServiceNow's own MCP Client, can discover and invoke the same governed tool without rebuild.
What MCP is NOT — common misconceptions
| Misconception | Reality |
|---|---|
| "MCP is just another REST wrapper." | MCP is a protocol with built-in discovery (tools/list), invocation (tools/call), structured inputs/outputs, and error semantics. REST does not define these at the protocol level — they have to be layered on per implementation. |
| "Flow Designer / IntegrationHub can do this." | The MCP Server Console is the surface that publishes tools to external MCP clients. Wrap your logic in a Now Assist Skill and attach it as an MCP Tool — that's what makes the capability discoverable and invocable cross-instance / cross-vendor. |
| "You need an external Python or FastMCP server." | On Zurich+ the native MCP Server Console publishes governed tools end-to-end — no separate external MCP server is required for the native path. |
| "A2A and MCP solve the same problem." | MCP and A2A are separate, complementary AI protocols. Refer to each protocol's official spec (modelcontextprotocol.io for MCP, the A2A protocol documentation for A2A) to understand the interaction patterns each is designed for — they aren't interchangeable. |
| "Every AI vendor needs its own connector." | The same published MCP Server speaks the open protocol. Any compliant client (for example, Claude or Microsoft Copilot), alongside ServiceNow's own MCP Client, can connect with its own client-side configuration — no per-vendor server-side rebuild is required. |
How it works — Architecture
The link between Instance A and Instance B is the MCP protocol itself, layered with the platform's governance and observability. The native path described here does not introduce a separate integration middleware tier or a custom REST wrapper between the agent and the target instance — Instance A reaches Instance B over HTTPS using the MCP protocol directly. Network reachability (firewalls, VPN, proxies) is whatever your network policy already provides between the two instances; verify this independently.
Instance A (Agent Side) holds the AI Agent, the MCP Client, and a Connection & Credential Alias for outbound authentication. Instance B (Tool Side) publishes the MCP Server, which exposes one or more MCP Tools that wrap Now Assist Skills. The transport between them is Streamable HTTP carrying JSON-RPC 2.0 messages, authenticated via one of the supported MCP Client modes (OAuth 2.1, API Key, or Custom / Others).
[Image: Topology diagram — Instance A (AI Agent + MCP Client + Connection Alias) ⇄ OAuth + MCP over Streamable HTTP ⇄ Instance B (MCP Server + MCP Tool + Now Assist Skill + Incident Table).]
Runtime in three phases:
- One-time registration & discovery. The MCP Client performs an OAuth 2.1 flow against Instance B — the grant type depends on configuration (Authorization Code or Client Credentials), and PKCE may apply for public clients. The client receives an access token, then calls tools/list to fetch the tool catalog and input schemas live (the ServiceNow MCP Client does not permanently cache schemas — re-selecting the server in the AI Agent form refreshes them). The discovered tool is then bound to the AI Agent on Instance A.
- Per-prompt invocation. The user prompts the AI Agent, which maps the intent to the create_incident tool, extracts structured arguments, and calls tools/call over MCP. The MCP Server executes the bound Now Assist Skill, which inserts the incident record and returns number, sys_id, state, and a deep-link URL.
- Governance and observability run in parallel. The MCP Client logs each outbound call in sn_mcp_execution_logs. MCP server-side telemetry (latency, success rate, throughput) is consumable through AI Control Tower's observability surface — verify the specific telemetry tables and dashboards on your own instance, as these may vary across releases.
[Image: Sequence diagram — User → AI Agent → MCP Client → OAuth handshake → MCP Server → Now Assist Skill → Incident Table → return path back to User.]
Authentication modes: The ServiceNow MCP Client supports multiple authentication types — OAuth 2.1, API Key, and Custom / Others (Connection Alias). Per-user OAuth allows access on the target instance to be authorized per calling user, with downstream access control enforced by the target's ACLs. Pick the mode that matches your audit and least-privilege requirements, and confirm exact audit behavior on your instance.
Transport: ServiceNow uses MCP Streamable HTTP for MCP server communication. SSE is an optional mechanism within Streamable HTTP; Streamable HTTP replaces the older HTTP+SSE transport in newer MCP spec versions — verify compatibility for any non-Streamable HTTP server before registering it.
Build Runbook
This is the complete, reproducible build sequence. The order is fixed: Instance B first (Steps 0–5), then Instance A (Steps 6–8). You cannot register a server from Instance A until Instance B has it active.
Conventions. Instance B = the Tool Side (publishes the MCP Server). Instance A = the Agent Side (consumes Instance B's MCP Server). Replace <instance-b> and <instance-a> with your actual instance hostnames.
Instance A:
Prompt: Create an Incident with short description "Test Incident to demonstrate the MCP PoC - Cross incident creation", in 'Software' category, Low Impact and Low Urgency
Instance B:
Step 0 — Prerequisites (both instances)
Goal: confirm plugin versions, role assignments, MCP service routing, and the service user exist before any configuration begins.
0.1 Verify plugins are installed and up to date
On each instance, navigate to All > System Applications > All Available Applications > All, filter by App ID, and confirm Installed and Up to date:
| App ID | Role in PoC |
|---|---|
| sn_mcp_server | Instance B only (server publishing) — verify installed version on your instance |
| sn_mcp_client | Instance A only (external server consumption) — verify installed version on your instance |
| sn_awh_config | Both instances (AI Gateway governance) — verify installed version on your instance |
| sn_generative_ai | Both instances (underpins Now Assist) — verify installed version on your instance |
0.2 Grant roles
Assign the following roles to the build user on the appropriate instance:
| Instance | Role | Scope of capability |
|---|---|---|
| B | sn_mcp_server.admin | Create/update MCP Servers and Tools |
| B | sn_skill_builder.admin | Author Now Assist Skills in NASK |
| B | sn_nowassist_admin.user | Activate published Skills via Now Assist Admin |
| A | sn_mcp_client.admin | Register external MCP Servers |
| A | sn_aia.admin | Author AI Agents in AI Agent Studio |
0.3 Confirm MCP service routing on Instance B
The /sncapps/mcp-server URL path on Instance B must be explicitly forwarded to mcps-prod-default. On many sandboxes and PDIs the path is not enabled by default. This is a Support-side enablement requested via HI case if missing.
Test from an unauthenticated browser tab:
https://<instance-b>.service-now.com/sncapps/mcp-server/mcp/sn_mcp_server_default
| Response | Meaning | Action |
|---|---|---|
| HTTP 401 / OAuth challenge / JSON error from the MCP service | Routing is live (the MCP service responded) | Proceed to Step 0.4 |
| HTTP 404 / "Instance not found" / generic 404 HTML | Routing not enabled | STOP. Open an HI case asking ServiceNow Support to enable /sncapps/mcp-server path forwarding to mcps-prod-default on this instance for the MCP Server Console. |
| Any other non-JSON response (e.g., HTML login page, redirect to /login.do, server error) | Needs investigation — may indicate a routing issue, a session/auth artifact, or an instance-state issue | Re-run from a fully unauthenticated session before proceeding; if behavior persists, open an HI case asking Support to verify that /sncapps/mcp-server is forwarded to mcps-prod-default on this instance. |
0.4 Provision the service user on Instance B (run-as identity)
Create a dedicated user record that the Skill executes under.
Navigate to All > User Administration > Users > New. Fields:
- User ID: mcp.incident.svc
- First name / Last name: MCP / Incident Service
- Active: true
- Internal Integration User: true
- Web service access only: false (the skill runtime is internal, not REST)
Save, then open the user record → Roles related list → Add:
- itil (incident table read/write)
- sn_nowassist_admin.user (required for skills invoked via Now Assist runtime)
Verification: impersonate mcp.incident.svc and confirm you can navigate to All > Incident > Create New.
Step 1 — Instance B — Register OAuth Inbound Integration
Goal: create the OAuth 2.0 Authorization Code grant integration that Instance A authenticates against. This is the single piece that secures the MCP Server endpoint.
1.1 Open Machine Identity Console
Navigate to All > MCP Server Console > Configuration > Servers. Look for the banner "OAuth setup required" and click Set up OAuth. This takes you to All > Machine Identity Console > Inbound integrations.
Alternate path: All > Machine Identity Console > Inbound integrations > New.
1.2 Create inbound integration
Click New, then choose OAuth - Authorization code grant. Fill the form:
- Name: MCP Server — Incident Creation (PoC)
- Redirect URLs: https://<instance-a>.service-now.com/oauth_redirect.do
- Under Auth scope: clear the Allow access only to APIs in selected scope toggle (makes the token broadly scoped so it can reach /sncapps/mcp-server).
- Under Advanced options: set Token Format = JWT.
Click Save.
1.3 Capture client credentials
After save, the form reveals Client ID and Client secret — copy both to a secure password manager. You will paste them into Instance A's MCP server registration in Step 7.
Verification:
- Navigate to All > System OAuth > Application Registry and confirm an "OAuth API endpoint for external clients" record exists with the name you chose.
- Confirm Access Token Lifespan = 1800 seconds (30 min) and Refresh Token Lifespan = 8,640,000 seconds (100 days) — ServiceNow defaults.
- Confirm Scope Restriction = Broadly Scoped on the Application Registry record (per KB2820840). If it is not set to Broadly Scoped, set it now — leaving it scope-restricted is one of two known causes of a tools/list failure on Instance A.
Step 2 — Instance B — Author the Create Incident Now Assist Skill
Goal: author a Now Assist Skill that uses the Now LLM Service to parse user input and orchestrate a Script tool node. The LLM reasons about the inputs and the Script tool node performs the actual GlideRecord insert, returning a structured output (number, sys_id, state, url).
2.1 Open NASK
Navigate to All > Now Assist Skill Kit > Home. Click Create new skill.
2.2 Fill the New skill form
| Field | Value |
|---|---|
| Skill name | Create Incident |
| Description | Creates an Incident record on this instance given structured fields (short_description, priority, category, etc.). Returns number, sys_id, state, and a deep-link URL. Intended for invocation via the Model Context Protocol Server Console. |
| Default provider | Now LLM Service |
| User access | Select roles → add sn_mcp_server.tools_admin (MCP runtime invokes under this role) |
| Role restrictions | itil — mandatory, aligns with the run-as service user's role and the incident table's access boundary |
Click Next. On the prompt selection step, choose Write from scratch, then paste:
You are a strict, rule-following incident-creation assistant. Your only job is to invoke the createIncident tool node and return its output verbatim.
Inputs provided:
- Short Description: {{short_description}}
- Description: {{description}}
- Priority: {{priority}}
- Category: {{category}}
- Impact: {{impact}}
- Urgency: {{urgency}}
Rules:
1. If Short Description is empty or blank, return {"error": "missing_input", "reason": "short_description is required"} and do NOT invoke the tool.
2. For all other inputs, pass them as-is. Blank or missing values are acceptable — the tool handles defaults.
3. After invoking the tool, return its output exactly as JSON. Do NOT add commentary, rephrase, or modify the output in any way.
Click Next.
2.3 Add Skill inputs and outputs
Add the following inputs:
| Input name | Type | Required | Description |
|---|---|---|---|
| Short Description | String | Yes | Short one-line description of the incident |
| Description | String | No | Longer free-form description, optional |
| Priority | Numeric | No | Incident priority, 1 (critical) through 5 (planning). Defaults to 3 |
| Category | String | No | Incident category (e.g., network, software, hardware). Free-form, OOB default applies if absent |
| Impact | Numeric | No | Impact 1–3, optional |
| Urgency | Numeric | No | Urgency 1–3, optional |
Do not add custom outputs. The skill's JSON result will be returned by the LLM in the default response output.
Click Go to summary → Finish.
2.4 Add a Script tool
In the NASK skill editor, navigate to the Add tools tab. Click Add a tool and select Script. The platform opens a 5-step wizard titled "Add script as a tool".
Step 1 — General info:
- Name: createIncident
- Script style: Write my own script
- Replace the entire default body with:
(function runScript(context) {
var gr = new GlideRecord('incident');
gr.initialize();
gr.setValue('short_description', context['short_description']);
var desc = context['description'];
if (desc) gr.setValue('description', desc);
var priority = context['priority'];
gr.setValue('priority', priority || 3);
var category = context['category'];
if (category) gr.setValue('category', category);
var impact = context['impact'];
if (impact) gr.setValue('impact', impact);
var urgency = context['urgency'];
if (urgency) gr.setValue('urgency', urgency);
var sysId = gr.insert();
if (!sysId) return { error: 'insert_failed', reason: gr.getLastErrorMessage() };
gr.get(sysId);
return {
number: gr.getValue('number'),
sys_id: sysId,
state: gr.getDisplayValue('state'),
url: gs.getProperty('glide.servlet.uri') + 'nav_to.do?uri=incident.do?sys_id=' + sysId
};
})(context);
Click Continue.
- Step 2 — Tool inputs: on my Zurich+ instances, this step displayed "For the 'write my own script' option, there are no tool inputs required." — the script accesses skill inputs directly from context. Click Continue.
- Step 3 — Tool outputs: on my instances, the form auto-detected the script's return value as Output (type: object). Leave Truncate unchecked. Click Continue.
- Step 4 — Tool conditions: None (Always run) is selected by default. Leave it. Click Continue.
- Step 5 — Summary: verify Type=Script, Name=createIncident, Inputs=empty, Outputs=Output / object, Tool conditions=none. Click Add tool.
Verification: the tool node createIncident appears in the skill's tool graph. Click Run tools with test values — confirm the output contains number, sys_id, state, and url.
2.5 Configure and deploy the Skill
- Configurations tab: leave Model on default, Temperature = 0 (greedy decoding — lowest LLM output variance), Maximum response tokens = 512 (structured JSON response is small).
- Skill settings tab → Deployment Settings:
- Workflow: Technology
- Product: ITSM
- Feature: Now Assist Admin
- Name: create_incident
- Description: (reuse the Skill description)
- Enable from: leave all channel toggles off — MCP is the only caller.
- Click Save.
2.6 Finalize and publish
Back on the Skill Home page: Finalize prompt → Publish. State shows "Published". If an "Add roles to ACL" dialog appears, click it (on my instances, this added now_assist_panel_user for Conversational experiences).
2.7 Activate in Now Assist Admin — HARD GATE
Navigate to All > Now Assist Admin > Now Assist Skills > ITSM. Find Create Incident in the search results, click Activate skill. Confirm in the selected application scope.
Verification:
- The row for Create Incident shows Status = Active with a green badge.
- The Action column shows Deactivate (the button changes from "Activate" to "Deactivate" when the skill is live).
Step 3 — Instance B — Provision the MCP Server
Goal: create an MCP Server record that will publish the Create Incident Tool.
3.1 Create the server
- Navigate to All > MCP Server Console.
- From the Configuration tab, select Servers.
- Click New.
- Fill the Server form (only two fields):
- Label: Incident Creation MCP Server (PoC)
- Short description: Publishes the Create Incident tool for cross-instance invocation. PoC scope only — do not attach production tools.
- Skip the Tools section for now (added in Step 4).
- Click Save as draft (not Create yet — attach the Tool before activating).
Verification:
- Navigate to the sn_mcp_server_registry table list. New record exists with your Label, status = Draft.
- The Server URL field is populated automatically: https://<instance-b>.service-now.com/sncapps/mcp-server/mcp/<server-name>. Copy this URL — you will paste it into Instance A in Step 7.
Step 4 — Instance B — Create and attach the Create Incident MCP Tool
Goal: wrap the published NASK skill as an MCP Tool and link it to the Server record from Step 3.
4.1 Create the Tool
- Navigate to All > MCP Server Console > Configuration > Tools.
- Click New.
- Fill the Tool form:
- Category: AI Skill (default)
- Now Assist skill: Create Incident (reference picker — only published + activated skills appear)
- Label: Create Incident
- Name: auto-populates from Label
- Application: Global
- Servers: add Incident Creation MCP Server (PoC) from Step 3
- Description: paste the tool description below — this text is sent to the calling LLM and drives tool selection accuracy:
Creates a new Incident record on ServiceNow. Use this tool when the user asks to log, create, open, or report an incident. Required inputs: short_description (one-line summary). Optional inputs: description (detail), priority (1=critical, 2=high, 3=moderate, 4=low, 5=planning; default 3), category (free-form e.g., network/software/hardware), impact (1-3), urgency (1-3). Returns the created incident's number, sys_id, state, and deep-link URL. Call only when the user clearly wants a new incident, do not use this tool for lookups, updates, or duplicates.
- In the Tool inputs section, the six inputs from the Skill auto-populate. Review the Enabled toggles:
- Keep enabled: short_description, description, priority, category, impact, urgency.
- Do not disable short_description — it is required.
- Click Create.
4.2 Verify linkage
Open the Server record from Step 3. The Tools related list should now show Create Incident. Equivalently, open the Tool record — the Servers field should show Incident Creation MCP Server (PoC).
Verification:
- sn_mcp_tool_definition has a record for Create Incident with category = AI Skill, and the servers field references the Server.
- The sn_mcp_server_registry record's tools field lists Create Incident (cross-reference of the same link).
Step 5 — Instance B — Activate the MCP Server
Goal: move the Server from Draft to Active.
Navigate to the Server record from Step 3 → click Activate.
Verification:
- The Server list shows Status = Active for the record.
- The sn_mcp_server_registry record's status field reads Active.
- Optional smoke test from a workstation: send an unauthenticated GET to https://<instance-b>.service-now.com/sncapps/mcp-server/mcp/<server-name>. Expected: HTTP 401 (auth challenge) — confirms the path reaches the MCP service. If it returns HTML or 404, the routing prerequisite from Step 0.3 was not actually met — go back to Step 0.3.
Step 6 — Instance A — Create Connection & Credential Alias
Goal: create the Connection & Credential Alias on Instance A that the MCP server registration record will reference for authentication.
6.1 Create Connection & Credential Alias
- All > Connections & Credentials > Connection & Credential Aliases > New
- Fields:
- Name: MCP Instance B Incident Server
- Type: Connection and Credential
- Connection type: HTTP
- Save.
6.2 Add Connection record
On the saved alias record → Connections related list → New:
- Name: mcp_incident_server_oauth
- Credential: leave blank (OAuth tokens are created automatically in oauth_credential on first authentication)
- Connection URL: the Server URL captured in Step 3 — https://<instance-b>.service-now.com/sncapps/mcp-server/mcp/<server-name>
- Active: true
Submit.
Verification: alias record MCP_Instance_B_Incident_Server exists in sys_alias with one Connection record, Host = <instance-b>.service-now.com, Protocol = HTTPS.
Step 7 — Instance A — Register Instance B's MCP Server
Goal: create the MCP server registration record on Instance A so AI Agent Studio can discover and invoke Instance B's tools.
7.1 Add MCP Server via AI Agent Studio
Navigate to All > AI Agent Studio > Settings > Manage MCP Servers > New. Fill the form:
| Field | Value |
|---|---|
| Name | Instance-B-Incident-Server (plain ASCII — alphanumeric and hyphens only, avoid em-dashes) |
| MCP Server URL | https://<instance-b>.service-now.com/sncapps/mcp-server/mcp/<server-name> |
| Connection Alias | auto-generated by the form (e.g., AutoGen_<Name>_<timestamp>_OAuthProviderAlias) |
| Authentication type | OAuth 2.1 |
| Grant Type | Authorization Code |
| Token authentication method | Client Secret Post |
| Client ID | the Client ID copied from Step 1.3 |
| Client Secret | the Client Secret copied from Step 1.3 |
| Authorization URL | https://<instance-b>.service-now.com/oauth_auth.do |
| Token URL | https://<instance-b>.service-now.com/oauth_token.do |
Save.
7.2 Authenticate
Open the saved sn_mcp_server record. Click Authenticate. A browser tab opens to Instance B's OAuth authorization page.
Likely first-attempt error: Invalid redirect_uri. The MCP Client sends https://<instance-a>.service-now.com/oauth_redirect.do as the redirect URI. This must be registered on Instance B's inbound integration.
Fix: on Instance B, open Machine Identity Console → Inbound integrations → MCP Server — Incident Creation (PoC) → append https://<instance-a>.service-now.com/oauth_redirect.do to the Redirect URLs field (comma-separated, no spaces, no newlines). Save. Retry Authenticate on Instance A.
After consent (Allow), tokens are stored automatically in oauth_credential (per-user per-server). The sn_mcp_server record now shows a Re-authenticate button instead of Authenticate.
Verification:
- sn_mcp_server record exists on Instance A with the Server name, URL, and Connection Alias populated.
- The record shows Re-authenticate instead of Authenticate (indicates tokens are stored).
- A row exists in oauth_credential for the build user, scoped to the Connection Alias.
Step 8 — Instance A — Configure the AI Agent
Goal: build a Specialty AI Agent on Instance A that uses the registered MCP server to invoke the Create Incident tool on Instance B.
8.1 Create the AI Agent (Chat type)
Navigate to All > AI Agent Studio > Create and manage > AI agents > Add > Chat.
Fill the agent form:
| Field | Value |
|---|---|
| Name | Cross-Instance Incident Intake Agent |
| Description | Accepts user requests to create incidents on Instance B via the MCP Server, with governance, audit, and cross-tenancy separation enforced by protocol. |
| Allow third party to access this AI agent | OFF (this agent is the caller — no external system invokes it) |
Role (LLM instruction) — paste:
You are a cross-instance incident intake assistant. When a user describes an operational issue, you must: 1. Extract the short description (one sentence). 2. Infer priority from language cues: "critical" / "outage" / "down" = 1, "high" / "urgent" = 2, "moderate" / "degraded" = 3, "low" / "minor" = 4, "planning" / "when you can" = 5. 3. Infer category when possible (network, software, hardware, database, email). Leave blank if unsure. 4. Invoke the create_incident tool on the Instance B MCP Server. 5. Confirm to the user using the returned number and deep-link URL. Do NOT invent incident numbers. Do NOT rephrase the tool output. Do NOT attempt to create incidents on this instance directly — this agent operates cross-instance only via MCP.
List of steps — paste:
1. Read the user's prompt and identify whether they want to create an incident. 2. If yes, extract short_description, priority, category, impact, urgency from the prompt. 3. Call the Create Incident tool with the extracted arguments. 4. Return the tool's structured response to the user, including the incident number and URL. 5. If the tool returns an error, surface the reason verbatim to the user without hallucinating a workaround.
Execution Mode: Autonomous
8.2 Add the MCP tool
In the Add tools and information section:
- In the Add tool dropdown, choose MCP server tool.
- Fill the Add a Model Context Protocol Tool form:
- Select Model Context Protocol Server: the server registered in Step 7 (reads from sn_mcp_server)
- Select MCP server tools: check Create Incident (fetched live via tools/list from Instance B)
- Name: create_incident
- Tool and Description: description auto-populates from the server, accept default
- Execution Mode: Autonomous
- Display output: No (headless)
- Processing message: Creating incident on Instance B…
- Click Add. Tool definition is saved to sn_aia_tool.
8.3 Define security controls
- Under Define user access: select Users with specific roles → add itil or a tester role.
- Under Define data access: choose Dynamic user (the caller's identity propagates via OAuth token to Instance B).
8.4 Skip triggers (manual test only for PoC)
The PoC does not add an automated trigger — testing is done manually via the Studio test pane. Triggers can be added post-PoC when moving to production channels.
8.5 Activate
Click Save and continue until the final activation screen, then Activate. Agent state = Active.
Verification: navigate to All > AI Agent Studio > Testing > Start manual test, select the agent, enter a test prompt (e.g., "I need to log a P1 incident for email outage in the Zurich DC"), and confirm the agent invokes the Create Incident tool and returns the new INC00xxxxx number.
Three takeaways
- MCP turns ServiceNow capabilities into first-class network primitives. Publish a tool once on the MCP Server Console and it becomes discoverable and invocable by any MCP-compliant client (for example, Claude or Microsoft Copilot), alongside ServiceNow's own MCP Client, without rebuilding the server side per vendor.
- The native Zurich+ stack supports a no-middleware path. OAuth-based authentication is configured per server through inbound integrations; AI Control Tower and AI Gateway provide the governance and observability surface. For the native MCP path, no separate external MCP server, IntegrationHub orchestration, or bespoke REST wrapper is required.
- The /sncapps/mcp-server routing prerequisite is a common failure point. Validate Step 0.3 from an unauthenticated browser before any further configuration — downstream errors otherwise may resemble authentication or schema problems when the real cause is that /sncapps/mcp-server was never routed to mcps-prod-default on Instance B.
Fastest path to try this: provision two Zurich+ instances, confirm /sncapps/mcp-server/mcp/sn_mcp_server_default returns 401 (not 404) on the target, then follow Steps 0–8 above. Start with the Quickstart Server endpoint to validate routing, then build your own MCP Server with a single Create Incident tool. The full path from clean instance to cross-instance E2E call is achievable in a single working session once the routing prerequisite is met.
#ServiceNow #MCP #ModelContextProtocol #AIAgents #AIAgentStudio #NowAssist #NASK #MCPServerConsole #AIControlTower #Zurich #Australia #OAuth #Integration #CrossInstance #GenerativeAI #AgenticAI
