Your NOC never sleeps. Now neither does its context | Meet the ITOM MCP Server

YuvalMamka
ServiceNow Employee
INTRODUCING THE ITOM MCP SERVER

Your NOC never sleeps.
Now neither does its context.

Follow the sun without dropping the thread. One question, one answer, every time zone.

It's 2 a.m. in Austin. A payment service starts throwing alerts. Tel Aviv is just logging on. Bangalore chased this exact pattern yesterday, but the notes are buried in someone's chat history.

Sound familiar? Your people aren't the problem. The handoffs are. Every shift change, context leaks out.

So we built the ITOM MCP Server. It brings ServiceNow operations data straight into the AI client your team already uses, whether that's Claude, a custom agent, or any MCP-compatible assistant. No new console. No tab-hopping. Just ask.

SEE IT IN ACTION

Meet Julia. She just got paged.

The payment gateway is down, and Julia has zero context. Watch her go from page to pattern to permanent fix in one conversation, without ever opening the AIOps workspace.

00:03: Meet Julia.

00:04: She is working in the cloud operations team and she does not work directly in ITOM

00:08: AIOps - she uses Claude.

00:11: She can directly access the platform: By ask about an alert, receives the same data

00:16: an AIOps operator would see, and acts on it.

00:21: The story starts

00:21: when Priya messages Julia on Teams: The Payment Gateway is down.

00:26: Julia has no context, so she takes it into her chat window and starts asking.

00:31: First question: get me the alert details.

00:35: Now, Julia needs to understand the impact of this:

00:37: This is the part that usually takes a user three tabs and a service map.

00:42: The MCP Server walks the CMDB relationships and answers in business terms.

00:48: Has this happened before?

00:49: The MCP Server runs the investigation across the alert and incident history.

00:54: Now, Julia can understand if this is a one-time issue or a pattern.

00:59: Julia now uses Claude's power to analyze ServiceNow

01:02: data and asks to see the pattern of this alert on this service. It

01:05: is all clear: this

01:06: is lunch-hour checkout

01:08: traffic, and it happens on schedule.

01:11: Now, Julia starts to take action - starting with acknowledging the alert and

01:16: adding a work

01:16: note. The MCP Server does both on the

01:19: platform. Priya can see she has it, and the next person to touch this alert inherits

01:24: the context instead of starting over.

01:28: Next, the fix. The remediation that worked the last three times - Restart

01:32: Application Service - is offered back. Julia runs it to get the service back up.

01:39: But that's not all. A restart clears

01:41: the symptom,

01:41: but Julia closes the loop on the cause: this keeps happening at the same time every

01:46: day - create an incident and flag it for a change to scale up capacity ahead of

01:50: the noon peak. As part of the operations team, she can ask claude to automate

01:55: this response, or even have automatic escalation, saving the trouble of reassignment.

02:01: Here's where we're taking this next: Today

02:03: the server answers questions and runs the investigation with you. On the roadmap,

02:08: you'll be able to stay in the same conversation and do the admin work too

02:11: - so the fix you just talked through becomes a standing rule without ever leaving

02:15: the chat.

02:18: That is the whole arc in one conversation: page, context, pattern, fix, and a permanent

02:24: change

02:25: queued for approval.

02:27: This is the power of ServiceNow Action Fabric.

AIOPS

Know what's happening. Then do something about it.

  • Alert analysis and investigation: what fired, why it matters, and what's related, in one answer.
  • Impact analysis: see which services and business processes are affected before anyone opens a dashboard.
  • Hypothesizer: see where an alert is headed if nobody steps in.
  • Remediation and alert actions: get suggested next steps, then acknowledge or update alerts right from the conversation.

SERVICE RELIABILITY MANAGEMENT

Protect what your customers actually feel.

  • CI reliability status and topology: check the health of any configuration item and see how reliability ripples through its dependencies.
  • Incident-linked reliability: understand how an open incident is hitting the services behind it.
  • SLO creation: give any configuration item a standard availability objective in a single request.

LEAP

Stop fixing the same thing twice.

  • Automation opportunities: surface the repetitive work your teams keep doing by hand, grouped and ready to automate.
  • Setup and configuration checks: confirm LEAP is ready and look up its settings without digging through admin screens.

ONE INCIDENT. THREE TIME ZONES.

Zero lost context.

Austin asks, "What's going on with the payment service?" and gets the alert story, the impact, and the likely cause.

Tel Aviv picks up the thread hours later and sees exactly what was done.

Bangalore notices the pattern keeps coming back and turns it into an automation candidate.

Nobody starts from scratch. Everybody starts from the same page.

Your team stops stitching screens together and starts fixing what matters. AI does the gathering. Your people make the calls. That's what it looks like to put AI to work for people.

Built in, governed by default. The ITOM MCP Server runs on the ServiceNow AI Platform, so the roles, permissions, and audit trails you trust today cover every question asked and every action taken.

Your turn. Tell us what you think.

  • What would your team ask first?
  • Which handoff hurts most today?
  • What tool should we build next?

Drop your answers in the comments. We read every one, and your feedback shapes what we ship next.

Yuval Mamka, Product Manager, ITOM AIOps, ServiceNow

© 2026 ServiceNow, Inc. All rights reserved.

0 REPLIES 0