MCP Server Console FAQ

Ashley Snyder
ServiceNow Employee

yesterday

What is MCP Server Console?

MCP Server Console is ServiceNow's purpose-built control plane for publishing and governing AI agent connections. It lets administrators package ServiceNow capabilities — including Now Assist Skills, Knowledge Graph, Subflows and Actions, Scripted REST APIs, and AI Agents via Scripted REST APIs — as governed MCP tools that any standards-compliant AI client can discover and invoke. Your ServiceNow instance retains access control and policy enforcement over every interaction. For full observability, audit logging, and sensitive data protection across MCP traffic, AI Gateway in AI Control Tower is recommended.

This FAQ covers the most common questions from administrators deploying MCP Server Console for the first time, as well as those expanding existing deployments.

Two ways to get external AI agents and MCP clients working with ServiceNow MCP

MCP Server Console is the platform framework — it is where administrators register servers, package tools, connect clients, and control access across your instance.

Pre-built domain-specific MCP servers are purpose-built servers that ServiceNow product teams have already built on top of that framework for specific domains. If a pre-built server covers your use case, you can connect directly and start using it without building anything.

MCP Server Console governs both — servers you build yourself and pre-built servers your teams connect to.

📖 Key Terms

 

MCP (Model Context Protocol): An open standard protocol that lets AI agents discover and call tools on external systems in a standardized way.

MCP Server: A server that exposes capabilities as callable tools. ServiceNow acts as the MCP server when external agents connect to it.

MCP Client: An AI agent or application that connects to an MCP server to use its tools — for example, Copilot, Claude, or Moveworks.

Tool catalog: The curated set of tools available on a specific MCP server. Each server has its own catalog.

Quickstart Server: A pre-configured MCP server that ships with MCP Server Console out of the box — no setup required to get started.

AI Gateway: The enforcement feature inside AI Control Tower that governs MCP traffic — providing observability, sensitive data protection, approval workflows, and audit logging across every tool invocation.

Getting Started

Q: What is the difference between MCP Server Console and ServiceNow's pre-built domain-specific MCP servers?

A: MCP Server Console is the platform framework that powers all MCP connections on your ServiceNow instance. It is where administrators register and configure servers, package platform capabilities as tools, connect AI clients, and control access. Every MCP server — whether built by ServiceNow or by your own team — runs on this framework.

Pre-built domain-specific MCP servers are ready-to-use servers that ServiceNow product teams have already built on top of MCP Server Console for specific domains. Two are available today:

If a pre-built server covers your use case, you can connect to it directly — no server configuration required. MCP Server Console governs both pre-built servers and any servers your team builds.

Q: What is MCP Server Console?

A: MCP Server Console is ServiceNow's purpose-built control plane for publishing and governing AI agent connections. It lets administrators package ServiceNow capabilities — including Now Assist Skills, Knowledge Graph, Subflows and Actions, Scripted REST APIs, and AI Agents via Scripted REST APIs — as governed MCP tools that any standards-compliant AI client can discover and invoke. Your ServiceNow instance retains access control and policy enforcement over every interaction. For full observability, audit logging, and sensitive data protection across MCP traffic, AI Gateway in AI Control Tower is recommended.

Q: Does ServiceNow act as an MCP client, an MCP server, or both?

A: Both roles are supported:

 

As an MCP server, MCP Server Console exposes ServiceNow capabilities as governed tools for external AI agents and MCP clients to call — for example, a Copilot Studio agent invoking an incident summarization skill or triggering a workflow.

 

As an MCP client, ServiceNow AI Agents can connect to external MCP servers to use tools defined outside ServiceNow — for example, a ServiceNow AI Agent querying an external system through that system's MCP server.

The right role depends on your use case. Many deployments use both simultaneously.

Q: What is the Quickstart Server?

A: The Quickstart Server is a pre-configured MCP server that ships with MCP Server Console out of the box. It is the recommended starting point for first-time deployments and testing — no configuration required to connect your first MCP client.

The tools available on the Quickstart Server depend on which Now Assist store apps are installed on your instance. With Now Assist for ITSM installed, the server includes lookup_incident_records and incident_summarization. With Now Assist for ITSM and HRSD or CSM installed, it also includes lookup_case_records and case_summarization, for a total of four tools.

You can add your own tools to the Quickstart Server at any time, or use it as a reference when building purpose-built servers for your own use cases.

Q: Can I build my own MCP server using ServiceNow APIs instead of using MCP Server Console?

A: Building a basic MCP server against ServiceNow APIs is technically feasible, and some teams start there for proof-of-concept work. However, ServiceNow does not recommend a custom-built server as a production pattern. Here is what a homegrown approach cannot provide:

  • Platform intelligence. A homegrown server built against ServiceNow's Table API is limited to standard record reads and writes. It has no access to Now Assist Skills, Knowledge Graph, platform workflows, or AI Agents — the platform's semantic intelligence does not travel through a raw Table API connection. This is the limitation of a custom-built approach, not of MCP Server Console itself. MCP Server Console exposes a materially broader set of platform capabilities as governed tools: Now Assist Skills, Knowledge Graph, Subflows, Actions, and Scripted REST APIs including read and write operations.
  • Knowledge Graph. Your ServiceNow instance's Knowledge Graph maps exact relationships between people, assets, services, and processes, with access control enforced at every node in the traversal. A homegrown server wrapping the Table API can retrieve records, but it cannot replicate entity resolution, relationship traversal, or contextual grounding. This is the capability that prevents an agent from routing an incident to the wrong team based on stale text similarity.
  • Governance at the tool level. Your ServiceNow instance's native ACLs apply at the data layer when calling the Table API, but there is no governance at the tool and agent orchestration level. A homegrown server has no tool-level exposure controls, no runtime enforcement of which agents can invoke which capabilities, and no observability into tool calls.
  • Time to value. MCP Server Console can be configured and deployed in minutes by a non-technical administrator, with security and governance included by default. A homegrown MCP implementation requires custom development, security review, infrastructure setup, and ongoing maintenance — typically months before a single production tool call is possible.
  • Continued maintenance. When you build your own server, you own it. Security patching, uptime, incident response, and compatibility with platform upgrades are your responsibility. ServiceNow support does not cover homegrown MCP implementations.

Authentication and Connections

Q: What authentication options are available for connecting to MCP Server Console?

A: MCP Server Console uses OAuth 2.0 with Authorization Code Grant to authenticate all connections. This is the only currently supported OAuth flow for MCP Server connections. It is configured through ServiceNow's Machine Identity Console under Inbound integrations. Roles required: oauth_admin, mi_admin, or admin.

The Authorization Code Grant flow works differently depending on who is connecting:

 

For human users connecting through a client such as Claude Desktop or Microsoft Copilot — the user completes the OAuth browser redirect themselves, authenticating with their own ServiceNow credentials. The session is established under that user's identity. Every tool call executes under their existing roles and access controls. No additional identity configuration is needed beyond the OAuth registration.

 

For autonomous agents operating without a user present — an administrator completes the OAuth browser redirect once during setup, authenticating as a dedicated ServiceNow integration user account created specifically for the agent. The token is stored and reused by the agent for subsequent connections without further human involvement. The agent's tool calls execute under that integration user's identity, and that account's roles and ACLs govern what the agent can access. Configuring the integration user with appropriate roles and minimum necessary permissions before completing the OAuth setup is essential — this account is the identity the agent will operate as.

 

To set up OAuth, navigate to All > Machine Identity Console > Inbound integrations, create a new integration, select OAuth - Authorization code grant, and set Token Format to JWT under Advanced Options. You will need a redirect URL from your client.

For full setup instructions including server URL formats and OAuth configuration fields, see Connect to a Model Context Protocol server from an MCP client. For a full overview of connection types in Machine Identity Console, see Inbound integrations in Machine Identity Console.

Note: OAuth Client credential grant — which would allow agents to authenticate without a user identity — is not currently supported for MCP Server Console connections. It is on the product roadmap. Safe Harbor: This represents ServiceNow's current product direction and is subject to change. It should not be relied upon in making deployment decisions.

Q: Does every client need to be manually registered before it can connect?

A: For most clients, yes. An administrator needs to create an OAuth inbound integration in Machine Identity Console before the first connection. Automatic client registration is available for select partner clients that support domain-based identity verification — these clients prove their identity via a Client Instance Metadata Document hosted at their domain, eliminating the need for a manual registration record. For all other clients, the manual OAuth setup step is required.

Q: Does MCP Server Console respect my existing ServiceNow access controls?

A: Yes. MCP does not bypass ServiceNow's native access controls. Your existing ACLs, role-based permissions, and field-level security all apply to tool calls made through MCP Server Console.

How enforcement works depends on who is calling and which server they are using:

 

Human users — tool calls execute under the authenticated user's ServiceNow identity. A user who cannot read incident records in ServiceNow cannot retrieve them through an MCP tool. All four layers of ServiceNow access control apply: role-based access, contextual script ACLs, row and field-level security, and deny-unless-permitted defaults.

 

Autonomous agents — tool calls execute under the identity of the integration user account configured during OAuth setup. What the agent can access is governed by that account's roles and ACLs. Two independent layers control this:

  • The integration user's roles — the account used during OAuth setup must have the roles required for the tools the agent will call. Under-provisioning this account will cause tool calls to fail. Over-provisioning creates unnecessary risk. Apply the principle of minimum necessary permissions.
  • Tool-level ACLs — govern whether execution is permitted at the tool level, independent of the integration user's roles. How this is configured depends on which tool type is in use:
  • Pre-built domain-specific servers (ITSM, ITOM) — ServiceNow manages the ACL configuration. No additional tool-level setup required.
  • Custom servers using Now Assist Skills — administrators must configure an execute ACL and Role Masking for each skill exposed as an MCP tool. Without this, tools may return empty results rather than an error, which can be difficult to diagnose.
  • Subflows and Actions — AI ACLs are mandatory for any Subflow or Action to be eligible as an MCP tool. The platform runs a compatibility check at design time; assets without AI ACLs will not appear in the tool selection list. Only synchronous Subflows and Actions are supported — flows with wait steps, async execution, or human intervention steps are automatically excluded.
  • Knowledge Graph tools — ACL enforcement happens at the node level during every graph traversal. Two users or agents with different permissions issuing the same query will receive different results based on what each is permitted to see.

For guidance on AI ACL configuration for flows and actions, see Understanding invoke_from_ai ACL in ServiceNow.

Q: What transport protocols are supported?

A: MCP Server Console supports Streamable HTTP. By default, tool calls return a single JSON response. Server-Sent Events (SSE) are optionally available for streaming response types. Stdio is not supported.

Q: Are local MCP servers supported?

A: No. Only remote MCP servers are supported. Local server connections are not available.

Q: I am having trouble connecting an MCP client to MCP Server Console. Where should I start troubleshooting?

A: Start by checking your Connection and Credential records in ServiceNow to confirm they are configured as expected. Verify that an OAuth token has been requested in the Credential record and check that it has not expired. Verify that the redirect URL in your configuration matches exactly.

⚠️ Common issue: If tools are not discoverable after setup, the most likely cause is an ADC routing issue. Open a case with ServiceNow Support for assistance.

Server Design

Q: What tools do the pre-built domain-specific MCP servers include?

A: Each server ships with a curated set of tools for its domain. See the product documentation for the full list of available tools and their descriptions:

Q: How should I structure my MCP servers?

A: The recommended approach is one server per use case. Rather than creating a single server that exposes every available tool, use our out-of-the-box purpose-built servers or create your own scoped to specific workflows or teams — an IT server, an HR server, a CSM server, and so on. This makes each server easier to govern, keeps tool catalogs focused, and avoids exposing tools to clients that have no need for them.

 

Before building a server from scratch for a given use case, check the product documentation or contact your account team to see whether an out-of-the-box server already exists.

Q: Why should I not put all my tools on one server?

A: When an MCP client connects to a server, it loads the full list of available tools and passes that list to the underlying AI model as context. The more tools in that list, the more tokens are consumed before a single query is answered. Large, undifferentiated tool catalogs increase cost, slow response time, and can degrade model performance by introducing noise into the tool selection process. Keeping servers lean and use-case-scoped avoids these issues.

Q: Can I add the same tool to more than one server?

A: Yes, and this is sometimes the right choice. A shared capability like incident summarization might reasonably belong on both an IT server and a service desk server.

⚠️ Important: A tool definition is shared, not copied. Any change you make to a tool's name, description, or input configuration applies everywhere that tool is in use. Before editing a tool, review which servers it belongs to in the tool detail view and assess the downstream impact on every server it is mapped to.

Q: What happens if I add a scoped app tool to a global server?

A: The tool will not be available at runtime. Global tools must be added to global servers, and tools defined within a scoped application must be added to a server within that same application scope. Mixing scopes causes tools to be silently excluded when the server is called. When planning your server architecture, align each server's scope to the applications that own the tools you intend to expose.

Tool Configuration

Q: What types of ServiceNow capabilities can be exposed as MCP tools?

A: MCP Server Console supports the following tool types today:

  • Now Assist Skills — Pre-built and custom GenAI capabilities including incident summarization, case summarization, knowledge generation, and more. 50+ skills ship out of the box. Custom skills can be built via Now Assist Skill Kit.
  • Knowledge Graph — Semantic graph queries across people, assets, services, and processes on your instance. ACL enforcement at the node level. Six schemas available out of the box.
  • Scripted REST APIs — Any developer-defined Scripted REST endpoint exposed as a governed MCP tool. GET, POST, and PUT operations are supported.
  • Subflows — Synchronous Flow Designer subflows exposed as MCP tools. AI ACLs are mandatory for eligibility. Async and wait-step subflows are not supported.
  • Actions — Synchronous Flow Designer actions exposed as MCP tools. Same eligibility requirements as Subflows.
  • AI Agents via Scripted REST APIs — ServiceNow AI Agents can be invoked as MCP tools through governed Scripted REST endpoints.

Q: How do I make sure my AI client calls the right tool at the right time?

A: Tool descriptions determine how an AI client selects tools. When a client receives the list of available tools, it relies on each tool's description to decide whether and how to call it. A description that only names what a tool does is insufficient.

 

Every tool description should answer two questions: what does this tool do, and when should it be called?

Example: "Retrieves a ServiceNow incident record by incident number. Call this tool when the user references a specific incident by number and needs details such as state, priority, assignment group, or recent work notes. Do not call this tool for general incident searches or list queries."

 

ServiceNow ships tools with rich descriptions by default. When creating custom tools, particularly Scripted REST tools, invest time in the description. Vague or incomplete descriptions are the most common reason AI clients call the wrong tool or fail to call the right one.

Q: Do I need to provide inputs when calling a Scripted REST tool?

A: Yes. Unlike a conversational Now Assist skill that can infer context from a user's message, a Scripted REST tool requires inputs to be supplied explicitly and declaratively. If a required parameter — such as a record number, a date range, or a filter value — is not present in the request, the tool will not be able to complete the task.

 

Example: You have a Scripted REST API that returns all incidents assigned to a specific team within a date range. Without explicit inputs, the tool cannot execute — it has no way to infer which team or which dates.

A well-written tool description would say: "Returns all open incidents assigned to a specified assignment group within a given date range. Requires: assignment_group (string, the exact group name), start_date (string, format YYYY-MM-DD), end_date (string, format YYYY-MM-DD)." When the calling agent reads this description, it knows exactly what to collect from the user before invoking the tool. Without that description, the agent may attempt to call the tool with missing or incorrectly formatted parameters and receive no useful result.

 

When configuring Scripted REST tools, ensure your tool description clearly states what inputs are required and what format they should be in. This gives the calling agent the information it needs to construct a valid request.

Q: What Knowledge Graph schemas are available, and which should I use?

A: Six schemas ship out of the box:

  • Enterprise Graph: Covers all tables on your instance. Best for complex queries spanning multiple domains.
  • Enterprise Graph (Small): A curated subset of the most commonly queried tables. Faster, more token-efficient, and the right starting point for most IT and HR workflows.
  • User Graph: Focused on people, organizational structure, roles, and relationships. Best for org hierarchy lookups or manager relationships.
  • NLQ User Graph: A variant of User Graph optimized for natural language queries. Consult your implementation guide for specific use cases.
  • Table Look up Graph: Designed for structured table and record lookups. Consult your implementation guide for specific use cases.
  • Identify Survey Instance: A specialized schema for survey-related workflows. Consult your implementation guide for specific use cases.

✓ Recommendation: Start with Enterprise Graph (Small). Move to the full Enterprise Graph only if your workflows require cross-domain traversal that the smaller schema does not cover. For people and org structure queries, User Graph or NLQ User Graph is the more targeted choice.

Q: Are MCP resources and prompts supported?

A: Not at this time. Support for MCP resources and prompts is on the product roadmap.

Safe Harbor: This represents ServiceNow's current product direction and is subject to change. It is not a commitment to deliver specific functionality and should not be relied upon in making purchasing decisions.

Governance and Observability

Q: How do I monitor what my connected agents are doing?

A: Oversight of MCP Server Console connections is provided through AI Control Tower with AI Gateway. When your MCP server is managed in AI Gateway as part of AI Control Tower, you get visibility into usage, latency, and connection health across your servers, tools, and clients — including recent executions, error breakdowns, Assist consumption tracking, and an exportable audit history for compliance purposes.

 

The audit history supports accountability by ensuring every tool invocation can be traced back to the agent, client, and server responsible for it — a requirement for any organization operating AI systems under regulatory or internal governance frameworks.

 

For production deployments, enabling AI Control Tower with AI Gateway is recommended.

Q: Does MCP Server Console protect against sensitive data being passed through tool calls?

A: When your MCP server is managed in AI Gateway as part of AI Control Tower, sensitive data protection is applied automatically. AI Gateway detects and blocks regulated data patterns — including social security numbers and credit card numbers — before they pass through any tool invocation. This protection applies across all tool types.

 

Without AI Gateway, there is no automated data interception layer in the MCP traffic path. For any deployment handling potentially sensitive data, enabling AI Control Tower with AI Gateway is recommended.

Q: Can I control which tools a specific client can access?

A: Yes. Administrators control which tools appear on each server by adding or removing tools from the catalog — this gives you direct control over what each client can discover and invoke on a given server. A client connecting to a server sees only the tools on that server; connecting to a different server requires that server's specific URL.


For granular control over which clients are permitted to connect to which servers, AI Gateway in AI Control Tower provides the approval workflow layer — AI Stewards can review, approve, and manage client connections to MCP servers from a centralized registry before any client goes active.

Q: Should I use CMDB to track my MCP servers?

A: When an MCP server is registered as an AI asset in AI Control Tower, a configuration item is automatically created in CMDB, giving you native visibility into your MCP servers as part of your broader AI asset inventory — with no additional configuration required.

 

For AI governance — the policies, frameworks, and controls that ensure your AI systems operate responsibly and in compliance with applicable requirements — AI Control Tower is the recommended management layer. It is purpose-built for AI infrastructure oversight rather than general CMDB administration.

Have more questions?

Visit the ServiceNow product documentation for full setup guides, prerequisites, and release notes for MCP Server Console.

View Product Documentation
0 Helpfuls
  • 318 Views
Version history
Last update:
yesterday
Updated by:
ServiceNow Employee
Contributors