ServiceNow Event Management is evolving from an event-processing engine into an AI-ready operational data pipeline. Raw events are deduplicated, grouped, enriched, correlated with changes and knowledge, and analyzed by ServiceNow AI capabilities. And potentially enriched with data from Dynatrace/. The resulting alert is therefore more than a monitoring notification. It is a rich operational object containing the context needed to understand a problem.
Many of us spend our days now in ChatGPT/Claude/Grokbot/Hermes environments. In this walkthrough, a significant alert automatically triggers an outbound webhook to Grokbot. Grokbot then connects securely to the ServiceNow ITOM MCP Server and uses its tools to investigate the alert, retrieve additional context, and supports notification and further diagnosis.
Grokbot is the example, but the pattern can potentially be applied to other external AI systems that support the required webhook, OAuth, and MCP capabilities.
The main lesson is: Event Management creates the operational intelligence, ServiceNow AI Agents reason within the platform, and MCP allows external AI systems to build further value on top of that work.
Step 1: Understand the intelligence already inside the Alert
Before connecting an external AI system, it is important to understand how much work has already gone into the Alert. Event Management does not simply forward a raw monitoring Event. Throughout the Event Management pipeline, information can be processed and added through:
Each stage adds context or reasoning. By the time the operator sees the Alert, it can represent much more than the original monitoring signal.
In this example, Event Management has created a critical Alert for a problem affecting the Payments API. Several related symptoms have been collected around the same problem, including:
- Increased 5xx errors
- High API latency
- Authorization failures
- Authentication timeouts
- Load balancer degradation
- Network path anomalies
This is important to the rest of the walkthrough. Grokbot does not start with an isolated Event or an empty prompt. Grokbot starts with an operational Alert that has already been processed, correlated and enriched and analyzed by ServiceNow Otto AI Agents.
The AI investigation starts with the Alert, but the intelligence started much earlier in the Event Management pipeline.
Step 2: Create the Grokbot webhook receiver
I assume you have Grokbot from X.ai.
Setup a bot "ServiceNow Service Monitoring bot". For good measure I instructed it to change its logo to "Now".
Set up Grokbot to receive outbound API calls and copy the generated webhook URL for Step 3.
On the top right you'll now have a routine, there you can take the URL and the credentials you need in the next step.
At this point, no Alerts are being sent yet. This step only prepares the external endpoint that ServiceNow will call.
Step 3: Determine which Alerts should trigger Grokbot
The next step is to determine when the external AI system should become involved.
I created an Alert Automation rule that selects Alerts which:
- Are top-level Alerts
- Are not in maintenance
- Have a severity greater than Warning
This will need further definitions in production environments.
Goto the "Service Operation Workspace", and bottom left the "AIOps configuration".
Under "Optimize" find "Respond to alerts".
Select "Create Automation", and for example create these criteria.
And set the URL and the JSON payload
And the "Payload headers"
These conditions prevent every Event and every related child Alert from starting a separate external investigation.
Event Management first handles the noise reduction, grouping, enrichment and analysis. Only after a significant operational Alert has been created does the external investigation begin.
This makes Event Management the signal broker. ServiceNow decides that something meaningful has happened before involving the external AI system.
Step 4: Test that Grokbot receives the Alert
I created an Alert that matched the conditions in the Alert Automation rule. Event Management then triggered the outbound webhook and sent the configured JSON payload to Grokbot.
Check that the webhook was received and that fields such as the Alert number, CI, severity, description and ServiceNow link contain the expected values. A successful webhook call does not always mean that every field is mapped correctly.
At this point, Grokbot only knows the information included in the webhook payload. The deeper investigation will use the ITOM MCP Server.
The webhook tells Grokbot that something happened. MCP allows Grokbot to investigate what happened.
Step 5: Configure the ITOM MCP Server
I created an ITOM MCP Server in ServiceNow to give the external AI system controlled access to selected ITOM capabilities. "Admin", and "MCP Server Console".
And "Activate" the ITOM MCP Server.
The MCP Server exposes ITOM capabilities as tools. An authenticated MCP client can discover and invoke these tools as part of an investigation. "Added tools".
MCP allows the AI to select a tool and request additional information based on the questions that arise during the investigation. Grokbot is therefore not limited to reading the fields included in the original webhook. Grokbot can use the ITOM capabilities exposed through the MCP Server to continue investigating the Alert.
Step 6: Secure the MCP connection with OAuth
The connection between Grokbot and the ServiceNow ITOM MCP Server is protected using OAuth.
I created an OAuth configuration in ServiceNow and added the redirect URI required by Grokbot.
I then configured Grokbot to connect to the ServiceNow ITOM MCP Server and completed the OAuth authentication.
Setup the "Advanced Options"
I asked the grokbot to setup an MCP connection to a ServiceNow instant and it worked with me step by step to set it up:
I provided it with the Clientid and the Client secret when it asked. Which it did not store after connecting.
Then it asked to authorize:
After authentication, Grokbot could discover the ITOM tools made available through the MCP Server.
For a production implementation, the security of this connection requires careful consideration. I recommend:
- Using a dedicated integration identity
- Assigning only the required roles and permissions
- Exposing only the MCP tools required for the use case
- Protecting client secrets and access tokens
- Testing the integration with non-production data first
- Removing credentials and tokens from screenshots and logs
MCP provides the interface, but the existing ServiceNow security model still needs to determine what the connected identity is permitted to access and execute.
Step 7: Ask Grokbot questions about the Alert
After connecting Grokbot to the ITOM MCP Server, I could ask questions about the ServiceNow Alerts directly from Grokbot.
The Alert number received through the webhook provides the starting point for the investigation.
Grokbot can then use the available MCP tools to:
- Retrieve the Alert details
- Examine the related Alerts
- Run Alert analysis
- Review impact information
- Explore CI reliability and topology
- Collect additional ITOM context
- Create a working hypothesis
Event Management is evolving into an AI-ready operational data pipeline. It collects information, adds context and uses AI to reason about operational problems. Operators, automation, ServiceNow AI Agents and external AI systems can all harness the intelligence produced throughout that pipeline. The ITOM MCP is a great way to expose this information to agentic frameworks outside the ServiceNow platform.
Also note there is CMDB and ITSM MCP servers available for even further integration options.
