Your agent needs to work ServiceNow: open and resolve incidents, file change requests, read the CMDB, and act as the engineer who asked. ServiceNow now gives you two front doors. The native MCP Server Console publishes governed tools inside ServiceNow's AI stack; the REST API exposes the raw platform the way integrations have used it for years. They make different tradeoffs on entitlement, cost, and how much you own. Here is how to pick, and how to wire either one to a production agent.
Before comparing them, it helps to be precise about what each object is, because for ServiceNow the two paths are not symmetric. One is a governed AI control plane; the other is the platform's raw integration surface.
The MCP Server Console is ServiceNow's control plane for publishing and governing MCP tools. It reached general availability in the Zurich release; the current console lists Zurich Patch 9 or Australia Patch 2 as its minimum platform version. An administrator packages capabilities (Now Assist Skills, Knowledge Graph, subflows and actions, and Scripted REST APIs) and publishes them as governed tools that any MCP client can call. See the official reference on Exploring MCP Server Console.
Authentication is OAuth 2.0 Authorization Code Grant, currently the only supported flow, configured through the Machine Identity Console under Inbound integrations. PKCE applies for public clients, and Client ID Metadata Documents (CIMD) are supported from Australia Patch 1 or Zurich Patch 7 onwards; Dynamic Client Registration is deliberately not supported. Transport is Streamable HTTP for remote clients. Every call runs through AI Control Tower and AI Gateway, so it is identity-verified, permission-scoped, metered, and audited.
The REST API is the platform's integration surface, available on every instance and every version with no Now Assist entitlement. It is not one API; it is a family. The Table API does generic CRUD and query against any table, and dedicated APIs cover Change Management, the CMDB (including the Identification and Reconciliation Engine), Service Catalog, Import Set, Aggregate statistics, Attachments, and Knowledge. The full reference lives in the ServiceNow REST API documentation.
The REST API accepts Basic authentication, OAuth 2.0 across several grant types, and mutual TLS. OAuth 2.0 is the right path for agents acting on behalf of a user, since basic authentication is disabled by policy on many enterprise instances and on new developer instances by default. There is no Assist consumption; REST calls are standard integration traffic.
Capability coverage is where the two paths diverge most sharply, because the native MCP server only exposes what an administrator chose to publish, while the REST API exposes the platform.
The table below covers the actions ServiceNow agents reach for most. Read the MCP column as "available only if an admin packaged it," and the REST column as "available directly."
The native server is built for governed, user-facing work inside ServiceNow's AI stack. Its strength is orchestrating Now Assist Skills, flows, and approvals with human-in-the-loop consent. Its constraint is that raw platform breadth is not there unless an administrator packages each capability first, and packaging is a deliberate governance act, not a default.
If your agent needs generic table access, CMDB reconciliation from an external system of record, bulk import, or aggregate reporting, the REST API already exposes it. That breadth is exactly what Scalekit's connector wraps: 112 prebuilt tools spanning incidents, changes, problems, CMDB, Service Catalog, Import Sets, and Aggregate queries, documented on the Scalekit ServiceNow connector page.
Both paths can act as the individual user, and both respect ServiceNow ACLs. What differs is the flow you are locked into and what that implies once you have more than one tenant.
The native server enforces the Authorization Code Grant with browser-based consent. That is correct for interactive, user-present agents, and it integrates with third-party identity providers such as Okta, Microsoft Entra, and Ping Identity. It is a hard constraint for headless work: there is no static-credential or client-credentials shortcut for the MCP path today. Understanding Client ID Metadata Documents is increasingly important as MCP client registration evolves.
The REST API is more flexible. It supports the Authorization Code Grant for per-user delegation, plus service-oriented grants and mutual TLS for background integrations. For an agent acting as a specific engineer, per-user OAuth is the right model; for scheduled jobs, the REST path has options the MCP path does not.
A B2B agent serving fifty engineers across eight customer ServiceNow instances produces one credential per user per instance. The MCP path gives you an OAuth token per user; the REST path gives you a credential per user. Neither path stores, refreshes, or revokes those credentials for you across your customer base. That is infrastructure you build or buy. This is exactly the challenge covered in depth when moving from single-tenant to multi-tenant tool calling agent auth.
Operational surface area is the difference between a demo and a system that survives a Now Assist license review and a security audit.
ServiceNow owns hosting, schema updates, and governance. You still own client-side OAuth token storage per user, refresh handling, revocation when someone leaves, and the entitlement itself. AI Control Tower and AI Gateway give you observability inside the instance, which is real value, but only for traffic that flows through that one instance.
You own the full stack: endpoint selection, request construction, pagination, retries, error handling, and the entire token lifecycle. You also own LLM-ready tool schemas for every API surface you touch, and you re-own them each time an API version or field changes. Writing the schema is the hard part, not the API call, and every connector you build is a connector you now maintain.
Cost is a first-class production constraint here. Native MCP tool calls run as Now Assist actions and consume Assist currency, with skills exposed as tools consuming their usual assists plus one per invocation. REST calls consume no Assist currency; they are bound instead by the instance's inbound API rate limits and transaction quotas. For high-volume or background agents, that difference compounds quickly. It is worth reading about why MCP can be up to 32× more expensive than CLI to understand how protocol choice affects cost at scale.
The decision is rarely about capability alone; it is about who your agent serves, whether you hold the Now Assist entitlement, and how many customer instances you span.
Scalekit exposes ServiceNow as a single OAuth 2.0 connector that wraps the REST surface as prebuilt tools, and it can serve the same connector through a Virtual MCP endpoint. The flow below follows discovery, then scope, then execution. The connection name you pass must match the one you created in the dashboard, character for character.
The user grants access once; Scalekit runs the OAuth flow against ServiceNow and vaults the token. The agent never touches the raw credential.
The agent does not load a 112-tool catalog. It loads only the tools this user's connected account is authorized to call, which reduces token overhead and improves tool-selection accuracy. Surface reduction is the lever, not better prompting.
Each scoped tool becomes a LangChain tool whose executor calls executeTool for the same user. Scalekit resolves that user's vaulted token server-side and makes the real ServiceNow call.
If you prefer the MCP wire protocol, Scalekit gives the same connector a per-user Virtual MCP endpoint with nothing to host. Mint a short-lived, user-scoped token before each run and connect any MCP-capable framework, such as Google ADK.
The auth-model difference between the two paths is real, but it hides a problem that sits underneath both. In a multi-tenant agent, credential management is the same shape whichever front door you chose.
ServiceNow enforces identity well. Both paths run as the authenticated user, ACLs apply on every call, and the native MCP server adds AI Control Tower governance and AI Gateway observability inside the instance. What the user cannot do, the agent cannot do. That is the posture a security auditor wants to see.
ServiceNow governs what happens inside a single instance. It does not manage the credentials your agent holds across your customer base. Fifty engineers across eight instances means fifty tokens to store encrypted, fifty to refresh before they expire, and fifty to revoke when someone offboards. The token type differs between MCP and REST; the infrastructure required does not. The patterns around secure token management for AI agents at scale apply equally to both paths.
Scalekit's ServiceNow connector handles the OAuth flow, per-tenant token vaulting, automatic refresh, and revocation for the REST path, and serves the same connector as a Virtual MCP endpoint. The credentials never enter the agent runtime or the LLM context. The MCP vs API decision stops changing your auth infrastructure. Compare plans on the Scalekit pricing page.
For a B2B ServiceNow agent, the two hardest production problems are proving who did what and keeping one customer's data away from another's. Both are infrastructure decisions, not prompt decisions.
A shared service account makes every ServiceNow write look identical in the audit trail, which breaks attribution the moment a second user shows up. Scalekit resolves the real user credential per call and records who triggered which tool and what came back, with a 90-day, SIEM-ready history. Audit trails for agent auth in B2B SaaS explains the event surface and why per-user attribution matters in enterprise deployments.
Most ServiceNow agents also touch Slack, a knowledge base, or a ticketing tool. A Virtual MCP server gives you one server definition per agent role, declares exactly which tools it can see, and mints a per-user session token before each run. The endpoint is static; the identity is per-user; there is no MCP server for you to deploy, host, or maintain.
ServiceNow work maps cleanly onto existing templates. The incident response agent and the new hire provisioning agent both run on the same per-user auth model, and the support ticket automation agent shows the cross-tool pattern. Browse the full set from the Scalekit connectors overview.
The choice is not MCP or REST in the abstract; it is a function of who your agent serves and what you already own.
If your users work in ServiceNow's AI experiences, you hold a Now Assist entitlement, and you want AI Control Tower governance with human-in-the-loop approvals, the native MCP Server Console is the right path. Package the skills you need, accept the Assist consumption, and let ServiceNow own hosting.
If your agent runs headless, spans many customer instances, needs raw platform breadth, or cannot pay Assist currency per call, build against the REST API and let Scalekit own the per-user credential layer. The Scalekit ServiceNow connector gives you that surface without new auth code per connector.
If the agent lives inside one customer's ServiceNow AI stack, use the native MCP server. If it acts across your customers on their behalf, build on the REST API and solve credentials at the infrastructure layer, because that is the part neither ServiceNow front door solves for you.
If you are wiring ServiceNow into a production agent, come compare notes: join the Scalekit community on Slack, or talk to us about ServiceNow agent actions for hands-on help.
The MCP Server Console is ServiceNow's control plane for publishing and governing MCP tools, generally available as of the Zurich release. Administrators package capabilities such as Now Assist Skills, Knowledge Graph, and Scripted REST APIs and expose them as governed tools any MCP client can call.
Yes. The native MCP server requires a Now Assist or AI Native SKU. Every tool call also consumes Assist currency. The REST API has no such entitlement requirement and incurs no Assist metering.
Currently only the OAuth 2.0 Authorization Code Grant, with PKCE for public clients. Client Credentials and other service-oriented grants are not supported on the MCP path. The REST API supports a wider range of grant types including mutual TLS.
Not easily. The native MCP path requires browser-based consent via the Authorization Code Grant. Headless or background agents are better served by the REST API, which supports service-oriented OAuth grants and mutual TLS.
Scalekit wraps the ServiceNow REST surface as 112 per-user OAuth 2.0 tools, handles token vaulting, automatic refresh, and per-user revocation across all your customer instances. It also exposes the same connector as a Virtual MCP endpoint, so you do not need separate auth infrastructure for each ServiceNow front door.
With a shared API key or service account credential, a leak exposes all tenants sharing that credential. With per-user OAuth tokens managed via Scalekit, exposure is scoped to the individual user's token, which is short-lived and revocable without affecting other users or tenants.
Yes. The REST API family covers Table CRUD, Change Management, CMDB and IRE, Service Catalog, Import Sets, Aggregate statistics, Attachments, and Knowledge—all without a Now Assist entitlement. The native MCP server only exposes what an administrator explicitly packages.
Neither ServiceNow path automatically revokes credentials your agent holds for that user across your customer base. You must build or buy that revocation infrastructure. Scalekit handles this at the grant level: revoking a user's connection invalidates their token without affecting other users or tenants.
.webp)
