Understanding MCP: How ServiceNow Connects, Discovers, and Governs MCP Connections to MCP Servers

[Joe Wilmoth]

AI agents are only as useful as the tools and data they can reach. To take real action — opening a ticket, checking a repository, updating a record — an agent has to connect to the systems where that work actually happens. The Model Context Protocol (MCP) is quickly becoming the standard way that connection is made, and it's changing how enterprises think about agentic AI.

This article explains what MCP is, why it matters right now, and how ServiceNow approaches connecting, discovering, and governing MCP Servers across the enterprise.

What is MCP?

MCP — the Model Context Protocol — is an open standard for how AI agents discover and invoke tools in external systems. A helpful way to think about it: MCP is like HTTP for AI agents. It's a shared protocol that lets any compliant client work with any compliant server, without building a custom integration for every connection.

The difference becomes clear when you compare it to the traditional approach:

The traditional approach (REST APIs)

• The developer specifies everything: exact endpoint, parameters, and format, all hardcoded at build time.
• It's deterministic, but every action against every system requires its own custom code.
• Maintenance grows heavier as APIs evolve.

The MCP approach

• The agent sends a natural-language intent, and the server dynamically resolves it to the right tool call at runtime.
• The AI drives the interaction — the logic isn't hardcoded.
• One connection gives access to all of a server's published tools.
• The server can evolve without breaking the client.

Why MCP Matters Now

As AI agents move from answering questions to taking action, they need to reach the outside world — systems like Jira, Confluence, GitHub, internal APIs, and partner platforms. MCP is emerging as the universal connector for that agentic activity.

But connection was never really the hard part. The hard part is control. As enterprises adopt MCP, three gaps tend to appear:

• Every team reinvents discovery. There's no standard way to describe what a server does, where it lives, or whether it's approved for use.
• There's no governance at runtime. Servers get configured once and then run unchecked — even servers that should no longer be reachable.
• Shared credentials leave no audit trail. Without per-user identity, there's no clear record of which agent called what.

Solving connection without solving control is where enterprise risk quietly accumulates.

The ServiceNow Approach: Three Components That Work Together

ServiceNow's MCP strategy rests on three components. Each plays a distinct role, and together they deliver secure, governed MCP connectivity for every application and external AI host.

1. Universal MCP Client — Connect

The standard way applications connect to MCP Servers on the ServiceNow AI Platform, whether those are internal ServiceNow applications or external AI hosts like Claude. It's built to scale, and each user authenticates individually — no shared credentials, full traceability. Onboard a server once, and it becomes available to every consuming application, with governance applied automatically rather than bolted on afterward.

2. ServiceNow MCP Registry — Discover

A private catalog — one per company — built on the open MCP Registry API standard. It stores a "Server Card" for each MCP Server, describing what the server does, where it connects, the tools and resources it offers, and its approval status. Importantly, the Registry stores metadata only. It never holds credentials, tokens, or certificates — authentication happens when the connection is made, not in the catalog.

Because it's built on an open standard, any MCP-compatible client can discover servers through it — from ServiceNow applications to tools like Claude, GitHub Copilot, and Cursor. Register a server once, and it's discoverable everywhere.

3. AI Gateway (within AI Control Tower) — Govern

AI Gateway is the governance, observability, and security layer for MCP transactions, delivered as part of AI Control Tower. It owns the approval workflow: when a server needs approval, AI Gateway manages the queue, the policy, and the enforcement. And it enforces at runtime across every MCP connection — if a server isn't approved at the moment of execution, the call doesn't run. Every connection is auditable and policy-enforced before it executes.

How It Works: Discover → Approve → Connect

The three components map cleanly to three steps:

• Discover. An application or external AI host queries the ServiceNow MCP Registry to find available MCP Servers — what each one does, what tools it offers, and its approval status.
• Approve. If a server isn't yet approved, AI Gateway manages the approval workflow. For ServiceNow-native clients, attempting to invoke an unapproved server automatically raises an approval request — a governed, self-service loop with no manual steps.
• Connect. The client executes the connection to the approved server. Each call is tied to the individual user, enforced by policy at runtime, and fully auditable.

The Registry and AI Gateway can each work independently — the Registry on its own is useful for inventory and discovery, and AI Gateway can enforce policy without it. The full experience — governed discovery, approval, enforcement, and audit — comes from using them together.

Governance Built Into Visibility

One of the more elegant parts of the design is that governance isn't just a runtime check — it shapes what different clients can even see.

• ServiceNow-native clients see all servers, approved and unapproved. Unapproved servers are visible but not callable, and any attempt to invoke one raises a governed approval request.
• Third-party clients (such as Claude, GitHub Copilot, and Cursor) see only approved servers. Unapproved servers are never surfaced to them at all, so there's no path to reach something that hasn't been cleared.

The Registry governs discovery. AI Gateway enforces execution — at runtime, at the moment of the call. Revoked or unapproved servers cannot be reached.

What Makes It Different

Public MCP registries do a valuable job: they help developers find servers that exist in the community. An enterprise registry needs to do more — it needs to answer not just "what exists?" but "what's allowed here?" and then enforce that answer.

Dimension	ServiceNow MCP Registry	Public registries
Registry type	Private, one per company	Public, open
Governance	AI Control Tower approval workflow	None
Runtime enforcement	Yes	No
Third-party discovery	Approved servers only	All servers
Audit trail	Full, per call	None
Credentials stored	No — metadata only	No

Public registries tell you what exists. The ServiceNow MCP Registry tells you what is allowed — and enforces it.

Availability

The ServiceNow MCP Registry is the first enterprise private MCP registry built on the open MCP Registry API standard. Both the ServiceNow MCP Registry and the Universal MCP Client are bundled with Workflow Data Fabric. AI Gateway is delivered within AI Control Tower.

The Takeaway

MCP is becoming the connective tissue of agentic AI, and the real challenge isn't getting agents connected — it's keeping those connections discoverable, governed, and auditable as they scale. ServiceNow's answer brings those together: one client to connect, one catalog to discover, and one policy engine to govern. Connect, discover, govern.

Get Started

To install the ServiceNow MCP Registry, visit: https://store.servicenow.com/store/app/2d463d6787608354669040c8dabb3530

To install the Universal MCP Client, search for MCP Client (sn_wdf_mcp_client) in the Application Manager within your ServiceNow instance.