What is Action Fabric?
Action Fabric is ServiceNow's framework for connecting AI agents across your enterprise. AI agents are software programs that can reason, plan, and take autonomous action on behalf of a user; unlike a chatbot that answers questions, an agent can make decisions, call tools, and complete multi-step tasks without step-by-step instruction. Action Fabric has three components: MCP Server Console exposes ServiceNow capabilities to external AI clients; MCP Client gives ServiceNow AI agents reach into external systems; and A2A enables two AI agents to collaborate on shared tasks as peers. Together they let any AI agent work with ServiceNow and ServiceNow agents work across your entire technology stack.
|
MCP Server Console ServiceNow as the server External AI agents connect in and invoke ServiceNow tools. |
MCP Client ServiceNow as the client ServiceNow AI agents call out to external MCP servers. |
A2A Agent-to-agent ServiceNow agents collaborate with external AI agents as peers. |
This article explains how each component works, what you can do with it today, how governance ties them together, and how to choose the right approach for your use case.
๐ Key terms
MCP (Model Context Protocol): Open standard for how AI agents discover and invoke tools in external systems.
MCP Server Console: ServiceNow capability for publishing, governing, and observing MCP tools exposed to external AI clients.
AIAS MCP Client: Outbound client used by AI Agent Studio and the AI Agent Orchestrator to invoke tools in external MCP servers.
Universal MCP Client: Outbound client used by Workflow Data Fabric apps and Build Agent; supports both Tools and Resources with AI Control Tower enforcement always on.
A2A (Agent2Agent): Open protocol for direct collaboration and task delegation between AI agents across different systems.
AI Control Tower: ServiceNow's governance product for enterprise AI agent connections. AI Gateway is the feature set inside it that governs MCP traffic.
ServiceNow products referenced in this article
AI Agent Studio โ The ServiceNow interface where builders create, configure, and deploy AI agents. Home to the AI Agent Orchestrator, which coordinates how agents plan and execute multi-step workflows, and the Worker Agent, which executes individual tool calls.
Workflow Data Fabric (WDF) โ ServiceNow's data integration layer. Build Agent and AI Data Explorer run inside WDF and use the Universal MCP Client to reach external systems.
AI Control Tower โ The governance console for ServiceNow AI. AI Stewards use it to discover, approve, monitor, and pause AI agent connections. AI Gateway is the feature set inside it that governs MCP traffic.
Jump to
What is MCP? MCP Client MCP Server Console A2A Governance How it all works Choosing the right approach Get started Build vs buy
Concept
What is MCP?
MCP (Model Context Protocol) is an open standard that defines how AI agents discover and invoke tools in external systems. Think of it as HTTP for AI agents, a shared protocol that means any compliant client can work with any compliant server, without custom per-connection integration work.
The difference from a traditional API matters. With a REST API, a developer specifies the exact endpoint, parameters, and format at build time. With MCP, the AI agent sends natural-language intent: "create an incident for this user" and the server resolves that intent to the right tool call at runtime. The agent doesn't need to know the tool name, parameter schema, or the system's internal structure.
|
REST API Developer specifies everything Exact endpoint, parameters, and format hardcoded at build time. Deterministic and predictable but requires custom code per action per system.
|
MCP AI resolves intent at runtime Agent sends natural-language intent. Server dynamically resolves to the right tool call. No custom integration per action.
|
REST API integrations are hardcoded per action; MCP lets the AI agent discover and invoke tools dynamically from a single connection.
The MCP spec defines the protocol, not your security posture. Community-built and open-source MCP servers vary widely in authentication and access control. ServiceNow's MCP Server Console addresses this with OAuth 2.0, three-vector access control, full audit logging, and ServiceNow-supported security patching. See the Governance section for details.
Outbound
MCP Client
The MCP Client capabilities let ServiceNow AI agents invoke tools in external MCP servers such as Jira, Salesforce, SAP, GitHub, or any MCP-compliant system without custom integration code. The agent sends natural-language intent; the external server resolves it to the right tool call and returns the result.
There are two implementations, each serving a different part of the platform. Which client is used depends on where your agent is built: AI Agent Studio agents use the AIAS MCP Client, WDF apps use the Universal MCP Client.
|
AIAS MCP Client AI Agent Studio Used by AI Agent Orchestrator. Configured in AI Agent Studio Settings. Supports Tools only. AI Gateway enforcement supported when MCP servers are managed in AI Control Tower; not on by default.
|
Universal MCP Client Workflow Data Fabric Used by Build Agent, AI Data Explorer, and Agentic Playbooks. AI Control Tower enforcement always on at runtime; revocation is immediate, no code changes required.
|
AIAS MCP Client serves AI Agent Studio and the Orchestrator. Universal MCP Client serves WDF apps and Build Agent.
Example: A ServiceNow AI Agent handling employee offboarding sends a prompt to the Salesforce MCP Server: "close this employee's open opportunities." Salesforce resolves the intent to the right API call, executes it, and returns the result. No custom Salesforce integration required in ServiceNow.
Governance difference between the two clients: The Universal MCP Client always enforces AI Control Tower approval at runtime; revocation is immediate. The AIAS MCP Client supports AI Gateway enforcement when MCP servers are managed in AI Control Tower; confirm it is active for security-sensitive deployments before connecting to external servers.
๐ Resources: MCP Client
- AI Agent Studio: configuring MCP servers
- Model Context Protocol Client (AIAS) product documentation
- AI Agents: MCP Client overview (AI Academy) โ walkthrough of outbound MCP client configuration
- MCP protocol specification โ authoritative MCP spec and external server listings
Inbound
MCP Server Console
MCP Server Console is ServiceNow's native implementation of an MCP server. It is the platform capability that lets administrators publish ServiceNow capabilities as MCP tools and manage everything about how they're exposed. Any MCP-compatible AI client such as Moveworks, Copilot Studio, Claude, AWS Bedrock, or a custom-built agent connects once and gains access to the tools published on that server. No custom integration per client.
The console organizes around three jobs: Integrate (publish tools and connect clients), Govern (control which tools are exposed to which clients using built-in access controls), and Observe (monitor usage, errors, and consumption via AI Gateway). For AI governance approval workflows, lifecycle tracking, sensitive data protection, and centralized monitoring across all MCP connections, see the Governance section covering AI Gateway.
Minimum version requirement: MCP Server Console requires Zurich Patch 9 or Australia Patch 2 as the minimum platform version. Verify your instance version before configuring.
What your agents can do today
As of June 2026, entitled customers can connect any MCP-compatible client and access the full range of tool types:
| What the agent asks | Tool type | Available |
|---|---|---|
| "Summarize incident INC39582" | Now Assist Skills | โ GA Dec 2025 |
| "How many open P1s does my team have, and which CIs are affected?" | Knowledge Graph | โ GA May 2026 |
| "Submit a PTO request for next week and notify my manager" | Subflows & Actions | โ GA May 2026 |
| "Show SLA performance against KPIs this quarter" | Scripted REST APIs (full CRUD) | โ GA May 2026 |
๐ก The shift from "answer a question" to "complete a task" happened in May 2026. External AI clients can now submit, route, approve, and confirm ServiceNow workflows end-to-end without custom integration code per client.
Two ways to give a ServiceNow AI agent a tool
MCP Server Console is not only for external clients. ServiceNow AI agents can also use it as their tool source. When you build an agent in AI Agent Studio, you choose what tools it can invoke. There are two paths:
|
Path 1: Native tools Wired directly in AI Agent Studio Configure a Subflow, Flow Action, Script, Now Assist Skill, or RAG tool directly in the agent's tool definition. The agent calls it natively with no protocol layer involved. Best when: you need custom logic, the tool is agent-specific and won't be shared with external clients, or you want the simplest possible setup. |
Path 2: MCP Server Console tools Via AIAS MCP Client Point the agent's MCP Client at an MCP server and it discovers the tools published there. Best when: ServiceNow's quickstart or customer servers already cover your use case, or you want the same tool catalog shared between internal agents and external clients without building it twice. |
๐ Resources: MCP Server Console
Agent collaboration
A2A
Agent2Agent (A2A) is an open protocol for direct collaboration between AI agents across different systems. Where MCP is about an agent invoking tools in a system, A2A is about two AI agents coordinating on a shared task, delegating subtasks, passing context across turns, and completing work that neither could do alone.
In an A2A interaction, both sides have AI agents. One acts as the primary (initiates the task), the other as the secondary (receives the delegation and executes). ServiceNow can operate as either.
Example: A ServiceNow AI Agent is handling an employee transfer between organizations. It creates the software license update in ServiceNow, then delegates the job history update to a Workday agent via A2A. Workday completes its task and returns results; the ServiceNow agent closes the workflow. No Workday API integration required in ServiceNow.
MCP vs. A2A: how to tell them apart
| MCP | A2A | |
|---|---|---|
| What it connects | Agent to tools in a system | Agent to another agent |
| Interaction type | Tool invocation: discrete, returns a result | Task delegation: multi-turn, stateful |
| Other side needs | An MCP server exposing tools | An AI agent with its own reasoning |
| Context sharing | Single call, no persistent context | Multi-turn, agents share goals and state |
| Best for | Actions: "do X in that system" | Collaboration: "handle the Y part of this" |
Governance note: A2A connections use OAuth 2.0 or API key authentication, configured per external agent in AI Agent Studio. AI Gateway currently governs MCP traffic only; A2A is outside its scope as of the current GA release. See the A2A concepts table below for current capabilities and known limitations.
The three actors in every A2A interaction
Every A2A interaction involves three roles. ServiceNow can play any of them depending on how the workflow is structured.
|
Role 1 User: The Initiator A human operator or automated trigger that initiates a request or defines a goal. In ServiceNow, this is typically an employee submitting a request through Now Assist, or an automated workflow trigger. |
Role 2 A2A Client: The Orchestrator (Primary) The agent acting on behalf of the user. It initiates communication via A2A, delegates subtasks to remote agents, and assembles results into a completed workflow. ServiceNow can be the client. |
Role 3 A2A Server: The Specialist (Secondary) An AI agent exposing an HTTP endpoint that implements A2A. It receives tasks, processes them autonomously, and returns results. ServiceNow can also be the server. |
Five core A2A concepts
A2A defines a set of building blocks for how agents communicate. These are the terms you will encounter when implementing or evaluating A2A.
| Concept | What it is |
|---|---|
| Agent Card | A JSON metadata document, the agent's "business card." Describes identity, capabilities, endpoint URL, available skills, and authentication requirements. How clients discover whether a remote agent can help. |
| Task | A stateful unit of work with a unique ID and defined lifecycle: submitted, working, completed, failed, or cancelled. Can span multiple turns and run asynchronously across agent boundaries. |
| Message & Part | A Message is one turn of communication between client and agent. It contains one or more Parts, the content containers: text, a file reference, binary data, or structured JSON. Makes A2A modality-independent. |
| Artifact | A tangible output generated by a remote agent: a document, structured data, image, or other deliverable. The concrete work product of a Task, with a unique ID and name. Distinct from Messages, which convey status. |
| Interaction patterns | Request/Response: client sends, server responds; client polls for long tasks. Streaming (SSE): real-time incremental results as the agent works. Push Notifications: server pushes updates to a client webhook for fire-and-forget tasks. |
Safe harbor statement: ServiceNow is planning to update to A2A v1.0 alongside the Linux Foundation's formal release. This represents forward-looking intent and is subject to change. Always check current release notes for the protocol version your instance supports.
๐ Resources: A2A
Governance
AI Control Tower and AI Gateway
Every MCP connection you manage should operate within a governance layer. Inbound connections from external AI clients reaching your MCP Server Console, and outbound connections from your ServiceNow agents to external MCP servers, are both governed by AI Gateway.
AI Control Tower is ServiceNow's governance product for enterprise AI. AI Gateway is the feature inside it built specifically for MCP: a centralized inventory for every ServiceNow and external MCP server and client connection you manage, approval workflows, runtime enforcement, and full observability across every tool invocation in both directions.
MCP Server Console handles publishing and execution. AI Gateway handles everything before a call is made, during every call, and what you can see afterward. The three pillars work as a closed loop:
| 01 ยท Govern
What is connecting, and has it been reviewed? Both registries live here: external MCP clients connecting inbound to your MCP Server Console, and external MCP servers your agents connect to outbound. Every connection has a lifecycle state: In Review, Assess, Approved, Active, or Deprecated. Nothing goes active without an AI Steward reviewing and approving it. Agent builders in AI Agent Studio only see servers that have already been approved. Every approval is recorded through the same Asset Approval Playbooks used for AI models and datasets. |
02 ยท Control
Runtime enforcement and instant response. OAuth 2.1 is enforced on every connection. Controls to block sensitive data before it passes through can be configured. Pause any client or server from AI Control Tower instantly and globally, no code changes, no redeployment required. |
| 03 ยท Observe
Know what is happening after every call. Usage, latency, success rate, and error breakdowns per tool and server on every call. Assist consumption tracked and linked to Subscription Management. |
|
๐ก The MCP specification defines the protocol, not your security posture. AI Gateway is the governance plane that sits above that protocol. It manages both the external clients calling into your MCP servers and the external servers your agents call out to. Approval playbooks and lifecycle tracking. Sensitive data protection can be configured to block requests before data is proliferated downstream or into logs. Pause any MCP connection, without code changes.
Scope note: AI Gateway governs MCP traffic in both directions: inbound external clients connecting to your MCP Server Console, and outbound external MCP servers your agents connect to via MCP Client. It does not currently govern A2A traffic. A2A connections use OAuth 2.0 or API key authentication configured per agent connection in AI Agent Studio.
๐ Resources: AI Control Tower and AI Gateway
Examples
How it all works
Each component handles a different direction of agent connectivity. Here's what each looks like in practice, followed by how they work together in a single workflow.
ServiceNow as an MCP server
An external AI agent calls into ServiceNow's MCP Server Console to invoke a tool.
ServiceNow as an MCP client
A ServiceNow AI agent calls out to an external MCP server to retrieve data or take action.
ServiceNow with A2A
A ServiceNow AI agent delegates a subtask to an external AI agent via A2A, then resumes its workflow once the result is returned.
๐ก MCP Client and A2A can work together inside a single agent workflow.
A ServiceNow agent handling employee onboarding might use the AIAS MCP Client to pull open tasks from Jira, then receive a subtask delegation from an HR system agent via A2A โ all within one AI Agent Orchestrator workflow. MCP Server Console is separate: it is configured by a platform administrator to expose ServiceNow capabilities to external clients like Copilot Studio, independently of what any individual agent workflow is doing.
Decision guide
Choosing the right approach
MCP, A2A, REST API, and Spokes are not competing; they solve different problems and routinely coexist in the same workflow. The right choice depends on what the AI needs to do, how much reasoning is involved, and how deterministic the interaction needs to be.
| Approach | What it is | Strengths | Tradeoffs |
|---|---|---|---|
| REST API | Standardized direct integration. Every parameter and format specified by the developer. Deterministic and programmatic. | Familiar, well-documented, highly controlled. Predictable and testable. Works with any system. | Custom-built per system. Parameters hardcoded, not AI-driven. Maintenance burden as APIs evolve. |
| Spokes | ServiceNow-delivered low-code integrations via Flow Designer. 200+ external systems supported out of box: Salesforce, Jira, Workday, SAP, and more. | No custom API work. Modular and usable in any SN workflow. ServiceNow-maintained and versioned. | Limited to what ServiceNow has built. Deterministic; doesn't adapt based on AI reasoning. |
| MCP | Open standard connecting AI agents to tools and data. The AI discovers available tools dynamically and calls the right one based on intent. No exact parameters required upfront. | Purpose-built for agentic AI. No custom integration per client or system. Any MCP-compliant client works with any server. Governed via AI Gateway. | Less deterministic; subject to LLM and prompt quality. Only for tool and data access, not agent collaboration. |
| A2A | Open standard for direct collaboration between AI agents. Agents share goals, context, and results across turns. Either party can be primary or secondary. | Agents collaborate as peers, not as tools. Supports long-running operations natively. Enables workflow modularity across enterprises. | Requires the other system to have an A2A-capable agent. More complex setup than MCP. Adds latency vs direct integration. |
When to reach for each
Reach for this when: the integration is well-defined and doesn't require AI reasoning, the external system doesn't have an MCP server or A2A agent yet, or you already have Spokes built for the target system.
Reach for this when: an external AI client needs governed, auditable access to ServiceNow capabilities, or you want multiple clients to connect without building a custom integration per client.
Reach for this when: a ServiceNow AI agent needs to call an external system that exposes an MCP server: Jira, Salesforce, GitHub, Linear, or any MCP-enabled system, as part of an agentic workflow.
Reach for this when: the other system has an AI agent with its own reasoning, not just an API, and the task requires multi-turn context sharing, subtask delegation, or long-running coordination neither agent can do alone.
Next steps
Get started
Three paths into ServiceNow agent connectivity, depending on where you want to start.
Path 1
Connect external agents to ServiceNow
MCP Server Console โ inbound
An external AI client such as Moveworks, Copilot Studio, or Claude needs to use ServiceNow capabilities as tools. You expose those capabilities through MCP Server Console.
What you need:
- MCP Server Console store app
- Zurich Patch 9 or Australia Patch 2 minimum
- Now Assist SKU for the relevant domain (ITSM, ITOM, etc.)
- OAuth client configured for your MCP client
Quickest path: Activate the Quickstart MCP Server. It ships pre-configured with incident and case summarization tools. Connect your MCP client to the server URL. No tool configuration required to get started.
Path 2
Give ServiceNow agents external tools
AIAS MCP Client โ outbound
A ServiceNow AI Agent needs to retrieve or act on data in an external system that has an MCP server. You configure the AIAS MCP Client to connect to it.
What you need:
- AI Agent Studio (Zurich or later)
- The external MCP server's endpoint URL
- Authentication credentials and a Connection and Credential alias configured in ServiceNow
Quickest path: In AI Agent Studio, go to Settings, then Model Context Protocol Servers, and register the external server URL and credentials. The ServiceNow agent can immediately discover and invoke tools from that server without integration code.
Path 3
Govern MCP connections first
AI Control Tower โ governance
Security and compliance teams need visibility before any agent connections go live. AI Control Tower gives you the registry, approval workflows, and observability to govern everything before and during deployment.
What you need:
- AI Control Tower plugin installed
- Zurich Patch 9 or Australia Patch 2 minimum
- AI Steward role assigned to your governance team
Quickest path: Activate AI Control Tower and assign the AI Steward role. Any MCP server connection registered in AI Agent Studio will require approval before agents can connect, and the full audit trail is on from day one.
MCP Server Console
Should you build your own MCP server?
The MCP specification is open and well-documented, and building a basic MCP server against ServiceNow's Table API is technically feasible. Many teams start there as a proof of concept. This section gives you a clear picture of what that path involves at production scale, and what MCP Server Console handles for you.
A reasonable starting point: Building a proof of concept is quick. The question isn't whether it's possible to start; it's whether a custom-built server is the right foundation for a production deployment, and what your team will be responsible for maintaining as your agentic use cases grow.
What a homegrown MCP server requires you to own
|
Security ServiceNow's ACLs apply at the data layer; that's a baseline. But a homegrown MCP server has no governance at the tool and agent orchestration layer, which is where the new attack surface in agentic deployments lives.
|
Governance Without a governance layer, it becomes difficult to answer basic operational questions as your agentic deployment scales.
|
Maintenance When you build the server, your team becomes the MCP infrastructure operator, indefinitely.
|
Capabilities a Table API wrapper can't reach
| Capability | Table API wrapper | MCP Server Console |
|---|---|---|
| Knowledge Graph | Record retrieval based on text proximity | Live semantic graph traversal across relationships between people, assets, services, and processes. |
| Now Assist Skills | Raw record data; agents do the reasoning themselves | 50+ pre-built GenAI skills as governed MCP tools: incident summarization, KB generation, case handling, and more. ServiceNow-maintained, versioned, and SKU-aligned. |
| Workflows & Actions | Table writes: creates and updates, without workflow context | Subflows, Actions, and Scripted REST as tools; agents trigger platform workflows end-to-end, including approvals, notifications, and multi-step orchestration. |
| AI Gateway | Not applicable | Centralized registry, approval workflows, OAuth 2.1 enforcement, PII Vault Service, full audit trail, instant pause; built in. |
๐ก A homegrown MCP server is a reasonable starting point for a proof of concept. It is not a reasonable foundation for a production enterprise deployment where governance, security, and compliance matter. The question isn't whether you can build it; it's whether you want to operate it indefinitely.
Explore the documentation and community resources for each component.
MCP Server Console docs AI Gateway docs MCP & A2A FAQ A2A authentication guide MCP protocol spec A2A spec
