What a governed ServiceNow MCP server rollout looks like
A governed ServiceNow MCP server rollout is three decisions, taken before anyone connects a chat client: which role each person holds, what the connection's OAuth client may reach in ServiceNow, and which tools that role may call.
The request usually arrives from the service desk. Someone wants Claude to answer "what is still open on the network queue" without a tab switch. The quick version is one admin credential pasted into a personal setup. It works on the first afternoon. It also means every question runs with admin reach, and nothing records who asked.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves MCP at one endpoint, https://api.elaichi.ai/mcp, the same address for every organization. The address carries no identity. Each person approves one named client, that approval is called a grant, and the grant decides which organization and person a call acts as. Elaichi re-reads it on every request (one endpoint against one per team).
Who holds which role before you connect ServiceNow
Assign roles first, because a role is what a restriction attaches to. A member holds exactly one role in an organization. To combine two, an admin authors a custom role.
Elaichi seeds eight system roles. Six form a chain: Guest, Member, Team Admin, People Admin, Org Admin, Org Owner. Billing Admin and Auditor sit off the chain.
Four of them carry an IT rollout.
- Member for help desk agents. Member holds tool:execute, so their client can run tools, and connection:create, so they can connect their own account.
- Auditor for the compliance reviewer. It holds 12 view permissions, including audit:view and restriction:view, and no tool:execute. Their MCP tool list is empty, which is the point, and it does not take a billable seat. The read-only auditor role setup covers the rest.
- Guest for a contractor who should see the connector catalog and nothing else. One permission, connector:view, no tool execution, no billable seat. See the contractor Guest role.
- Org Admin for whoever writes the rules. restriction:manage and restriction:override sit with Org Admin and Org Owner only.
Custom roles need the role:manage permission and the plan feature that Gold and Black both include. A custom role always takes a billable seat, even one holding only view permissions.
Whose ServiceNow access does the connection carry?
Not each agent's own. Elaichi's ServiceNow connector signs in with OAuth client credentials, a client ID and secret, rather than a person's browser sign-in. Every call through the connection uses that one stored credential, from its owner or from anyone it is shared with, so every caller gets the same reach in ServiceNow.
Before the first ticket question, have an admin check in ServiceNow what that OAuth client is allowed to see and change. That is the ceiling for everyone the connection reaches.
Per-person limits come from Elaichi, not from ServiceNow. Three things decide what one member can do: the role they hold, the restrictions on that role or on them personally, and who the connection or toolbox is shared with. A member who cannot use the connection reaches ServiceNow only through stored toolboxes shared with them that pin it. The same decision shows up in a GitHub rollout behind SSO, where the connection shape and the role split have to agree.
Give the connection to somebody who is staying. When the owner leaves, the toolbox entries they pinned resolve as unmet for everyone until someone re-pins them. A shared connection also has to be transferred during the removal itself, because only an owner can transfer or delete one afterwards. Offboarding AI access walks the whole removal.
Which ServiceNow tools each IT role may call
Start from the connector's own tool list rather than from memory. In the console, a connector's page lists its tools with a search box and labels each one Read only or Makes changes. The public page for the ServiceNow connector carries the same list.
Then split it by job. Help desk agents get the read tools: looking up a ticket with list_all_servicenow_incident and get_single_servicenow_incident_by_id, a change record with list_all_servicenow_change_request and get_single_servicenow_change_request_by_id, or a business service configuration item with list_all_servicenow_cmdb_ci_service and get_single_servicenow_cmdb_ci_service_by_id. A service desk lead gets those plus the few tools that change the records their team owns. The compliance reviewer and contractors get none, which their role already settles.
Two details decide whether that split holds.
First, connected tools are never listed one by one, however few there are. A model finds one with search_tools and runs it with execute_tool. A client-side list of allowed tool names cannot tell one connected app from another, because one tool name carries them all. Per-app control is set in Elaichi.
Second, the consent checkbox "Run your connected tools" covers every tier of connected tool, deletes included. Unticking "Create and change data" does not make ServiceNow read-only; that box governs Elaichi's own write operations.
How a restriction blocks the tools that change ServiceNow
A restriction is a rule that says which connectors and tools a target may reach. It has a mode, allow or block, a list of whole connectors and a list of single tools. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule meant for the service desk is therefore written on their role.
The two shapes fail differently.
Block rules name the tools you do not want. Everything the rules do not name stays reachable, including a write tool nobody listed. This is the fast start, and it needs re-reading when the connector gains tools.
An allow rule naming the read tools is stricter, with one catch. It switches the role to an allowlist, so every other app that role uses is blocked until the role gets a whole-connector allow rule for each one. Choosing an allowlist or a blocklist walks that switch, and the allow rule that blocks all tools covers the empty-rule case.
The two rule kinds find their tool differently, which how blocks and allows find a tool explains.
A restricted tool is not invisible. A help desk agent who searches for a write tool still sees its name, marked restricted, but gets no schema and cannot call it. The refusal tells the caller whether the block comes from their role or their own account. From the client, that person can file their own access request. Only an admin in the console decides it, under Governance then Access requests, and approving creates an access grant for that one person rather than editing the role's rules.
Timing matters here. A role, team or restriction change reaches every surface in about two minutes. Revoking a share, disconnecting an account, and removing or suspending a member all take effect on the caller's next call.
What the audit log records for each ServiceNow call
Elaichi's audit log keeps one entry for each connected-tool call that reaches execution (a call refused earlier writes none). For a ServiceNow call, the row shows who acted, which ServiceNow connection the call reached, which tool ran and how it ended. What an AI agent audit log must capture lists every field and what to check against.
It leaves things out too. Of the call's arguments, it keeps the one path argument that names the object, as the target id, and nothing else about the arguments. A call refused before execution writes no row at all, so a tool a restriction withholds leaves no entry; the rule change itself is logged as restriction.created.
Two things to know before your first search. Connected-tool calls sit in the audit log's assistant category, not the mcp category, which holds client grants. And Elaichi keeps 90 days of history; for longer, export to your own Datadog comes with the Black plan.
Org Owners, Org Admins and Auditors hold audit:view and read every event in the organization. Anyone else sees their own events, and the events of any connection they own or can edit.
Why not ServiceNow's own MCP server?
Because of the other apps, and mostly only because of them. If ServiceNow is the single system your IT team needs an assistant to reach, going straight to the app's own server means one fewer vendor.
Two things change that answer. Calls a client makes to a vendor's own MCP server directly do not pass through Elaichi, so Elaichi does not govern them: no restriction, no audit row, nothing in the removal checklist. And an IT team rarely stops at one app. The second and third bring their own address, their own consent screen and their own log.
This post makes no claim about whether ServiceNow runs an MCP server, or what it covers. Read ServiceNow's own documentation before you compare.
There is a middle path. On Gold, an Org Owner or Org Admin can add a remote MCP server as the organization's own connector, as long as it speaks MCP over Streamable HTTP on public HTTPS. Tools from that server then meet the same restrictions, scopes and audit log as every other connector. Running vendor MCP servers through Elaichi covers the shape, and the Linear rollout works one through end to end.
What this setup does not do
Three limits, worth putting in the rollout doc rather than discovering in week three.
- Elaichi does not ask per call over MCP. The person's grant is the approval, chosen on Elaichi's consent screen for that named client. A confirmation someone sees mid-chat is their own client's prompt.
- An access grant has no revoke screen. It ends when it expires, when a later approval supersedes it, or when the member is removed.
- Removing a member ends their reach through Elaichi. It does not remove their ServiceNow account, which stays until somebody deprovisions it there or through the identity provider.
Each client words that mid-chat prompt differently. Claude's connector tool permissions are Always allow, Needs approval or Blocked, set on a whole connector, a category of its tools or a single tool (Anthropic's connectors article, checked October 2026). ChatGPT's plugin permission options include Always ask, Allow read actions and Allow low-risk actions (OpenAI's app permissions article, checked October 2026). Cursor asks for approval before using MCP tools by default (Cursor's MCP docs, checked October 2026). To any of them Elaichi is one server, so none of those settings tells ServiceNow apart from another connected app. That split stays in Elaichi, as restrictions.
The layer above this rollout is MCP governance, which covers roles, restrictions and sharing as one model. A sibling with the same shape and a different app is Intune in Claude for help desk lookups. The tool list you will be writing rules against sits on the ServiceNow connector page, beside the rest of the connector catalog.
