ServiceNow Action Fabric: A detailed walkthrough

[SujanDutta]

All you need to know about ServiceNow Action Fabric.

ServiceNow Action Fabric is a framework that lets AI agents built on the ServiceNow platform interoperate with agents and tools outside ServiceNow, using the MCP and A2A protocols. It supports three interaction patterns: ServiceNow as an MCP client calling outward, ServiceNow as an MCP server exposing its own capabilities, and ServiceNow agents collaborating with external agents over Google's A2A protocol.

In this series, we will unpack a concept of Action Fabric each week to help you unlock the full potential of your AI agents.

Episode 1: ServiceNow Action Fabric Intro

Every enterprise runs on multiple applications and platforms. And right now, every one of those platform vendors is shipping their own intelligent AI agents.

Individually, they're impressive. Collectively, they're a mess.

You end up with a fleet of capable agents, each locked inside its own platform, each unaware the others exist. That is not an intelligent enterprise operational model. That's automation islands. And it caps you hard: you can't build genuinely complex, scalable, modular workflow solutions for your customers when every agent stops at its own platform boundary.

What you actually need is for those agents to start working with each other.

That's the gap ServiceNow Action Fabric is built to close, an enterprise-grade framework where agents across your stack interoperate, with ServiceNow sitting at the heart of the orchestration.

The tech stack behind the concept

What does Action Fabric look like from the back end?

The design goal is interoperability, and the consequence of that goal is that Action Fabric is deliberately platform-agnostic. It doesn't care what's on the other end of the wire. That's the whole point.

It delivers on that through three protocols.

1. ServiceNow as MCP Client (outbound)

ServiceNow initiates the call. Your ServiceNow AI agent reaches out to an external MCP server, discovers the tools published there, and pulls back whatever context or capability it needs. Think of it as your agent extending its own reach, using best-of-breed external tools instead of you rebuilding them inside the platform.

2. ServiceNow as MCP Server (inbound)

Flip the direction. Here ServiceNow is the server, publishing its capabilities as MCP tools. External clients like ChatGPT, Cursor, whatever the team is already using, can then consume Now Assist skills, custom-built skills, scripted APIs, and knowledge graphs as first-class tools.

3. A2A (Agent2Agent)

The third is Google's open Agent2Agent protocol. Where MCP is an agent invoking tools in a system, A2A is two AI agents coordinating as peers on a shared task, delegating subtasks, passing context across turns, completing work neither could finish alone.

A ServiceNow AI agent built on the core platform can act as the primary agent that delegates outward, or as the secondary agent that receives a delegation from an external one. Both directions work.

Episode 2: MCP in ServiceNow

Remember life before USB-C? Every device had its own charger, its own port, its own cable. Your laptop, phone, tablet, and camera all spoke a different language, and you carried a bag full of adapters just to keep everything running.

That was AI agents before MCP. Every agent needed custom integration code to talk to every tool or system. MCP - Model Context Protocol, is the USB-C moment. One standard protocol. Any agent can connect to any MCP server without writing custom glue code.

ServiceNow as a MCP Server

Here's where it gets interesting for platform developers: your existing ServiceNow capabilities can become tools that any external AI can call. Now Assist skills, scripted REST APIs, Table API queries, package them behind an MCP server, and they're no longer locked inside ServiceNow. Any external LLM or agent can discover and use them.

That discovery step happens through a simple mechanism and once the agent knows what's on offer, it starts making tool calls, and ServiceNow returns results back to whatever's asking, an external copilot, a custom agent, anything speaking MCP.

ServiceNow as a MCP Client

MCP isn't one-directional. ServiceNow can also reach outward, acting as an MCP client that consumes tools from someone else's server, say, the Microsoft Learn MCP server for docs and code search, or any other external MCP-compliant source.

MCP is a fundamental for your enterprise automation flows.

Episode 3: ServiceNow as MCP client

Picture a fulfiller or support user working an incident. They're stuck on something like a Microsoft application issue, and their only real options are digging through the incident's own history, searching the knowledge base, or opening a browser tab and searching the vendor's docs manually. None of that is fast, and none of it is something an AI agent sitting inside ServiceNow could help with on its own, because the answer simply doesn't live in the platform.

That's exactly the gap MCP as client closes. Instead of limiting a ServiceNow AI agent to whatever it can query from the platform, you register an external MCP server, let the agent discover the tools published there, and give it a controlled path to pull in outside knowledge, then bring the result back into the incident where the user is actually working.

The use case: a resolution assist agent

The scenario built out in this episode is a resolution assist agent for an incident management workflow:

1. A support user is handling an incident.
2. The agent pulls the incident's own context first : short description and description, using an internal script tool.
3. The agent then reaches out to an external MCP server (the Microsoft Learn MCP server, in this demo) and performs a doc search using that context.
4. The retrieved guidance gets posted back to the incident as a work note, ready for the support user to review, refine, or use as the seed for a new knowledge article.

This is a small use case on purpose. It's meant to show the mechanics clearly enough that you can swap in your own external MCP server and your own workflow.

Technical implementation

Here's the step-by-step build, as it happened in the demo.

 

1. Register the external MCP server

   In AI Agent Studio, go to Settings in the left navigation and select Manage MCP Servers. This is the landing page where you register an external MCP server so ServiceNow can discover what tools live underneath it.

   • Choose the authentication type: OAuth 2.0 or API key.
   • If you're using an API key, provide the MCP server URL and the key.
   • Once saved, the server shows up as available.

2. Create an AI agent

   Add a new AI agent and give it a clear, meaningful role description so it understands the job it's doing. Everything else can stay at default for a first pass.

3. Add an internal script tool to pull incident context

   The first tool added is a simple script tool that fetches the incident details, specifically the short description and description fields, using the incident number. This tool is configured as supervised, so the agent checks in before running it.

4. Add the MCP server tool

   Next, add a tool of type MCP tool, and pick the registered MCP server from the list. ServiceNow performs a tools/list discovery call against the server, and every tool it exposes shows up as an option.

5. Add a script tool to post the result back

   A second script tool takes the incident number and the resolution content returned by the MCP tool, and writes it back to the incident as a work note.

6. Test it

   With the agent's reasoning panel toggled on, the run looks like this:

   • The agent pulls incident context and works out the actual issue.
   • With the context-gathering tool was supervised, the agent pauses to confirm its understanding before moving on.
   • It proposes a search query based on that context and asks for confirmation before proceeding.
   • Once confirmed, it invokes the MCP tool, which reaches out to the external server and returns documentation-based guidance, information that existed in neither the incident nor the internal knowledge base.
   • Finally, it posts that guidance to the incident's work notes automatically.

The end result: a support user gets externally sourced, relevant resolution guidance sitting directly in the incident, without ever leaving ServiceNow.

Any ServiceNow agent that needs context, data, or capability it doesn't natively have can reach out through a registered MCP server, under governed authentication, and bring the result back into whatever record or workflow triggered it. That's the core promise of Action Fabric's MCP-client direction: extend your agents' reach without rebuilding external systems inside the platform.

Episode 4: ServiceNow as MCP Server

Can ServiceNow be a server exposing its own skills, REST APIs, flows and sub-flows, actions, and knowledge graphs as tools that supercharge some other MCP client, like Claude or ChatGPT?

The answer is 'Yes'. And this is the direction that really unlocks agent-to-agent interoperability, because it means the capabilities you've already built inside ServiceNow don't have to stay locked inside ServiceNow.

The use case: turning ServiceNow into a tool provider for an external AI

The scenario in this episode is straightforward on purpose, so the mechanics stay visible:

1. Register a new MCP server inside ServiceNow and attach a handful of tools to it — starting with incident lookup and incident modification.
2. Set up a secure inbound integration path (OAuth, JWT tokens, user-scoped access) so an external AI can actually reach that server.
3. Connect an external AI client (Claude, in this demo) to the ServiceNow MCP server using a custom connector.
4. Extend the server further by exposing a custom scripted REST API as a tool.
5. To test: create an incident from natural language, add a work note to it, and pull data back through the custom REST API, all from outside ServiceNow.

Technical implementation

Here's the step-by-step build, as it happened in the demo.

1. Open the MCP Server console: You'll need the AI admin role, and your instance needs to be on Zurich Patch 9 or later, or on the Australia Patch 2 or later. Once you're in, you'll see an out-of-the-box "Quick Search" MCP server already available, a good sandbox for getting a feel for how MCP servers behave before you build your own.

2. Create a new MCP server: Give it a meaningful name and short description. As soon as you save it, the server URL populates automatically, that's the endpoint external clients will connect to. Worth noting, you'll typically want multiple MCP servers rather than one giant one. The reasoning is governance. You probably don't want your IT-focused tools exposed to the same server as your HR use cases. Scoping servers by use case keeps access boundaries clean.

3. Add tools to the server: Start simple. In this demo, two tools get added: a lookup incident records tool and a modify incident tool.

4. Set up the inbound integration (Machine Identity Console): This is the piece that lets an external agent actually authenticate against your new MCP server.

• Open the Machine Identity Console and set up an application registry entry.

• Choose the Authorization Code grant type.

• Fill in the redirect URL.

• Copy the generated client ID and client secret.

• You can scope this broadly for a demo, but in production you'd lock down which API scopes the registry entry can touch.

• Critically, switch the token format to JWT, this is the format the MCP server connection currently expects.

5. Build the connection from the external client (Claude):

• In Claude's connector settings, add a custom connector.

• Name it (e.g., "ServiceNow MCP") and paste in the MCP server URL, client ID, and client secret from the previous step.

• The connector is registered but not yet connected, you still need to authenticate.

• When you connect, you're prompted for ServiceNow credentials. This step matters: authenticating this way keeps the connection user-scoped, so the external AI only ever sees what that specific ServiceNow user account is entitled to see. No elevated privileges just because the request came in over MCP.

6. Attach a Now Assist skill to the MCP server: Create a custom analysis skill designed to accept natural-language queries and create an incident from them. Create a new tool, mark it as an "analysis skill" type, and attach the MCP server to it. One tool can be attached to multiple MCP servers if you need to reuse it across contexts.

7. Expose a scripted REST API as a tool: This is where it gets more powerful. Beyond Now Assist skills, you can expose existing scripted REST APIs, flows, sub-flows, actions, and knowledge graphs as MCP tools. In the demo, a simple scripted REST API tied to incidents gets registered as a tool, tagged to the same MCP server, given a description, and saved.

8. Refresh the tool list on the connector: Back on the Claude side, refresh the MCP server's tool list. The two newly added tools show up automatically, no reconnect needed, just a refresh.

9. Test it end-to-end

• Create an incident from natural language: "My MacBook is extremely slow" + "it's really high priority." Claude calls the MCP server, discovers the available tools, matches the request to the incident-creation tool, and creates the incident.

• Add a work note: "Can you add a comment to this incident?" Claude identifies the modify incident tool this time and adds the comment.

• Pull data through the custom REST API tool: Claude calls the scripted REST API tool and returns the expected results, confirming the custom-exposed tool works exactly like the built-in ones.

The result: an external AI client, operating under the logged-in user's own permissions, creating and updating ServiceNow records and calling custom APIs, without ever opening the ServiceNow UI.

That's the core promise of Action Fabric's MCP-server direction: your existing platform investment, skills, APIs, knowledge graphs all becomes reusable infrastructure for whatever AI tooling your organization (or your users) already prefer to work in.

Frequently Asked Questions

 

What is ServiceNow Action Fabric used for?

ServiceNow Action Fabric is used to make AI agents interoperable across vendor boundaries, so agents built on ServiceNow can work with agents and tools from Microsoft, SAP, Salesforce, and other platforms instead of operating in silos. It provides an enterprise-grade framework for cross-platform agent orchestration, with ServiceNow at the center of the network. The practical outcome is that a single workflow can span multiple vendors' agents without custom point-to-point integration.

What is the difference between Action Fabric and MCP?

MCP (Model Context Protocol) is an open standard for exposing and consuming tools between AI systems. Action Fabric is the ServiceNow framework that implements MCP, along with Google's A2A protocol, as a governed, enterprise-grade capability on the Now Platform. Put simply: MCP is the protocol, and Action Fabric is how ServiceNow makes that protocol usable with platform authentication, scoping, and agent orchestration built in.

What is the difference between MCP and A2A in ServiceNow?

MCP operates at the tool level: it lets an AI agent discover and call individual capabilities, such as a Now Assist skill , a scripted REST API, or a knowledge graph lookup. A2A (Agent2Agent, Google's open protocol) operates at the agent level, letting a ServiceNow AI agent  delegate to and collaborate with an entire external agent rather than a single tool. In Action Fabric, MCP covers tool access in both directions, while A2A covers peer-to-peer agent interaction.

Can ServiceNow agents talk to ChatGPT or Cursor?

Yes, in both directions. When ServiceNow acts as an MCP server, external clients like ChatGPT and Cursor can discover and call your Now Assist skills, scripted REST APIs, and knowledge graphs  subject to OAuth and user-scope enforcement, so the caller only sees what that identity is entitled to. When ServiceNow acts as an MCP client, agents registered in AI Agent Studio  can reach outward and call tools on any registered external MCP server.

Is Action Fabric part of Now Assist?

No, Action Fabric and Now Assist are separate but complementary. Now Assist provides the generative AI skills that run on the platform; Action Fabric is the interoperability layer that lets those skills be exposed to external AI systems and lets ServiceNow agents consume external tools. In practice a Now Assist skill becomes one of the tools published through an Action Fabric MCP server.

What does it mean for ServiceNow to act as an MCP client?
It means a ServiceNow AI agent initiates the connection outward to an external MCP server, discovers the tools that server publishes, and calls them to retrieve information or capability that doesn't exist inside ServiceNow. The agent stays in control of the workflow; the external server is just supplying a tool call and a result.

What authentication does ServiceNow support when registering an external MCP server?
The Manage MCP Servers page supports both OAuth 2.0 and API key authentication. For API key auth, you provide the server URL and the key directly when registering the server.

What's the difference between ServiceNow as an MCP client vs. an MCP server?
As an MCP client, ServiceNow initiates the call outward to pull in external tools or data. As an MCP server, ServiceNow is on the receiving end, external AI clients connect to it and call the tools ServiceNow exposes, like Now Assist skills, scripted REST APIs, and knowledge graphs.

What can I expose as an MCP tool besides Now Assist skills?
Scripted REST APIs, flows, sub-flows, actions, and knowledge graphs can all be registered as MCP tools, alongside table lookups like incident records.

Does the external AI need to know which tool to call?
No, that's the point of MCP discovery. The client calls the MCP server, retrieves the list of available tools, and matches the user's natural-language request to the right tool automatically (e.g., recognizing "add a comment" should call the modify-incident tool, not the incident-creation tool).

Can I reuse the same tool across multiple MCP servers?
Yes. A single tool can be attached to more than one MCP server if it's relevant to multiple use cases.

Next week, we look at ServiceNow AI agents collaborating with external agents over A2A protocol