This is Chapter 5 in a series walking through ServiceNow's AI stack from the ground up. Chapter 4 covered agents — goal-driven systems that decide their own sequence of tool calls. This chapter covers the layer underneath that: how those tools actually get exposed and called in the first place. That's Action Fabric and MCP (Model Context Protocol), and it's the layer where an agent stops being a conceptual diagram and starts being something with real, executable access to your instance.
This chapter ends with a real hands-on finding from testing a community MCP server against a PDI — not a hypothetical risk, but something that actually happened during testing.
1. MCP vs. REST — the Same Integration, Built Two Ways
The clearest way to understand MCP is to see the same integration task built the traditional way and the MCP way, side by side.
Task: let an external AI tool look up and update incident records.
Built as a traditional REST integration:
GET /api/now/table/incident?sysparm_query=number=INC0010001
PATCH /api/now/table/incident/{sys_id}
Body: { "state": "6", "close_notes": "Resolved via automation" }
Here, the external system needs to know the table API shape, the correct sys_id lookup pattern, and the exact field names and value mappings (state 6 = Resolved) in advance. Every capability it has is whatever the integrating developer explicitly wired up and documented. An AI model consuming this would need those specifics fed into its context as documentation or examples every time.
Built as an MCP server:
Tool: get_incident(number: string) → returns incident record
Tool: resolve_incident(number: string, notes: string) → sets state to
Resolved and applies notes
Description exposed to the model: "resolve_incident: Marks the given
incident as Resolved with the provided close notes. Use this only after
confirming the underlying issue is fixed."
The MCP server does the translation work — the model never sees a raw table API or a state code. It sees a named, described action and calls it with plain arguments. This is the actual value proposition: MCP standardizes how a model discovers and invokes capabilities, so the same model can work against ServiceNow, a ticketing tool, and a monitoring platform through the same protocol shape, rather than needing bespoke integration knowledge baked into its prompt for each one.
What to actually learn: MCP isn't a replacement for REST underneath — most MCP servers call REST APIs internally, this one included. What MCP replaces is the need to hand-document and hand-feed API specifics into a model's context every time. The tradeoff, covered next, is that the server now decides on the model's behalf what's "safe" to expose as a callable action — and that decision can be wrong.
2. How Action Fabric Exposes Capabilities
Action Fabric is ServiceNow's own layer for defining what capabilities are callable by agents and external tools — conceptually similar to the MCP tool definitions above, but native to the platform and integrated with its role and ACL model rather than sitting outside it.
Example — one action defined and called:
- Define the action's inputs and outputs explicitly — for a "resolve incident" action, that's an incident number in, a success/failure status and updated record out. No open-ended access to arbitrary tables.
- Attach the action to a scoped role, the same discipline from Chapter 1 and Chapter 4 — the account executing this action should have exactly enough access to resolve incidents, not general write access to the incident table.
- Write the action's description for the consuming agent, not for a developer reading the code — this is the same lesson from Chapter 4's tool-scoping discussion, because Action Fabric actions and Agent Studio tools are ultimately the same kind of artifact wearing different names.
- Test the action being called with an invalid or already-resolved incident number before trusting it inside an agent's tool set — the failure behavior here becomes the agent's problem to reason about once it's live.
What to actually learn: Action Fabric and MCP are solving the same underlying problem — giving a model a well-defined, well-scoped action instead of raw API access — from two different directions. Action Fabric is ServiceNow-native and governed by the platform's own role model; MCP is protocol-level and platform-agnostic, meant to work the same way regardless of what system sits behind it.
3. Hands-On Caution: a Real Finding From Testing an MCP Server Against a PDI
Everything above is the theory. Here's what actually happened testing a community MCP server — nowaikit — connecting Claude Code to a ServiceNow PDI inside GitHub Codespaces.
Finding 1 — write operations executed without confirmation prompts. Section 2 above described a well-designed action model as one where the exposed action's description and scope are deliberate, tested guardrails. In this hands-on test, that guardrail was missing at the point that matters most: when the connected AI tool issued a write operation against the PDI, it went through directly, with no confirmation step in between the model's decision and the actual change landing on the instance. This is precisely the failure mode Chapter 4 warned about in the abstract — an agent composing its own action sequence is only as safe as the friction (or lack of it) between "the model decided to do this" and "this actually happened." A missing confirmation step removes that friction entirely.
Finding 2 — a hidden local dependency. nowaikit's slash-commands required a local Ollama instance running separately from Claude Code itself. This is a practical, easy-to-miss setup gap: the MCP server's advertised capabilities weren't fully available through Claude Code alone, and the dependency wasn't obvious until testing the slash-commands specifically. Worth calling out because it's exactly the kind of gap that "reading the documentation" doesn't always surface — it surfaces from actually running the thing.
What to actually learn: before connecting any community MCP server to an instance that matters — even a PDI — test write operations specifically and deliberately, with data you can afford to lose, and confirm whether a confirmation/approval step exists before the server can execute a change. Don't assume it does just because a well-designed system in principle would have one. And separately, budget testing time for a server's full advertised feature set, including anything gated behind local tooling that isn't part of the core install.
Checkpoint Before Moving to Chapter 6
You should be able to: explain what MCP standardizes versus what it doesn't, using the get_incident/resolve_incident example rather than protocol jargon; define an Action Fabric action with a properly scoped role and a description written for the consuming agent, not a developer; and — most importantly — know to test any new MCP server's write behavior explicitly before trusting it near real data, because "it should have a confirmation step" is a design assumption, not a verified fact. Chapter 6 takes this same skepticism and applies it at the governance level — data residency, licensing, audit trails, and the infrastructure underneath all of it.
Next in this series: Chapter 6 — Governance & Platform Impact, including a data-residency decision tree and how AI-generated changes actually show up in the audit log.
