How to Build an MCP Server for ServiceNow

ServiceNow is where IT organizations keep tickets, the configuration management database, the service catalog, and the approval workflows that govern change. ITSM agents that bypass it create parallel records nobody trusts; agents that extend it through a permissioned integration layer become part of the platform. This playbook builds a thin MCP server over ServiceNow that does the latter. It applies how to build an MCP server, the controls in MCP security risks, and the operating model in the agentic ITSM whitepaper; the agent that will use it is described in how to build a ServiceNow AI agent.

Step 1: Which ITSM tasks should the server support?

Start from the agent roles: level-one support, incident enrichment, request fulfillment, change preparation, knowledge maintenance. Each implies a small set of tools over specific tables.

Agent task	Tools	Tables	Classification
Incident triage	get_incident, list_similar_incidents, get_recent_changes_for_ci, add_work_note, propose_priority	incident, change_request, cmdb_ci	Read; reversible write
Request fulfillment	get_catalog_item, create_request, get_request_status, add_request_comment	sc_cat_item, sc_request, sc_req_item	Reversible write; approval via platform
Change preparation	create_change_draft, attach_impact_analysis, get_change_approval_state	change_request	Reversible; execution gated
Knowledge	search_knowledge, get_article, draft_article	kb_knowledge	Read; draft is reversible
CMDB	get_ci, list_ci_relationships, propose_ci_correction	cmdb_ci and related	Read; correction creates a task
Runbook remediation	execute_runbook_step	Backed by approved automation	Consequential; runbook-bounded

Step 2: How should authentication and user context work?

ServiceNow enforces access control lists per user and role. To preserve that, calls made on behalf of a person carry that person's context through OAuth, so a requester cannot read another user's tickets through the agent. The server itself authenticates with a dedicated integration identity holding a narrowly scoped role, never an admin role. Effective permission is the intersection of the agent's role, the user's access, and the tool's classification, as described in the agent identity and access control whitepaper.

Step 3: Write precise schemas

propose_priority takes an incident identifier and a priority from the instance's actual priority values; it does not take a free-form field map. create_request takes a catalog item identifier and the item's variables with types enforced. Read tools return fixed field sets and summarize long text. Work notes, descriptions, and knowledge content are labeled as untrusted content because they can carry injected instructions.

Step 4: Implement thin tools over the REST APIs

The server translates tool calls into Table API and catalog API requests, shapes responses for the model, and leaves workflow logic to the platform. It does not reimplement assignment rules, SLAs, or approval routing; it creates and updates records and lets ServiceNow's flows run. Every write tags the agent identity in the record so reports can separate agent work from human work. Keep the server stateless: it holds no ticket data between calls, which keeps it simple to scale and removes a second copy of sensitive records that would need its own protection.

Step 5: How do approvals and change control stay in the platform?

Approvals are ServiceNow's job. The server creates the request or the change draft with the evidence attached, ServiceNow routes approval to the owner it already knows, and the server exposes a read tool for approval state that the agent checks before any dependent action. Runbook remediation tools execute only pre-approved, reversible actions that are recorded as standard changes; anything else creates a normal change draft for a person. This is the boundary that keeps change failure rate from rising, and it follows the agentic AI governance whitepaper.

Step 6: Classify and permission every tool

Class	Tools	Principal	Gate
Read	Incident, change, CI, knowledge, request reads	Read-scoped role, user context	None
Reversible write	Work notes, comments, request creation, change drafts, article drafts, CI correction proposals	Write on those tables only	Sampling
Consequential	Runbook execution, closure of incidents, CMDB writes	Separate role; runbook-bounded; CMDB writes withheld	Approval or runbook definition

Step 7: Test on a sub-production instance

• Contract tests per tool.
• Permission tests: a user without access to a record cannot read it through the server; the integration role cannot reach non-allowlisted tables.
• Injection tests: an incident description containing instructions does not trigger runbook execution.
• End-state tests: create_request produces the expected request and items, and the approval flow starts.
• Fleet regression before platform upgrades, because ServiceNow releases change APIs on their own schedule.

Step 8: Publish and operate

Register the server with its owner in the platform team that runs ServiceNow, its tools and classifications, and the agents permitted to use it. Route through the gateway, log agent identity, delegated user, tool, and record identifiers, monitor error rate and latency, and align the server's version testing with the instance's upgrade cadence.

Step 9: Roll out by agent role

Connect the level-one support agent with read tools and request creation first; add incident enrichment in propose-only mode; enable runbook remediation for a short list of known errors last. Retire bespoke integrations as agents migrate.

What are the common mistakes?

1. An admin integration user shared by all agents.
2. A generic table tool exposing everything.
3. Approvals handled outside the platform.
4. Direct CMDB writes by agents.
5. Remediation beyond runbooks.
6. No regression before instance upgrades.
7. Tools named after tables rather than tasks, which pushes the model toward guessing field maps instead of calling a precise operation with a validated schema.

How does FISTA Solutions help?

FISTA Solutions is an official Anthropic partner and builds ServiceNow MCP servers and ITSM agents as part of its AI agents and AI enablement practices, with forward deployed engineers working alongside your platform team on tool design, roles, and approval integration. FISTA has delivered 150+ projects for 50+ companies across 12+ countries.

To build your ServiceNow server with us, message FISTA on WhatsApp, or read Digital FTE for IT helpdesk for the role it enables.