Connecting Claude to ServiceNow: A Hands-On MCP Build Log

Connecting Claude to ServiceNow: A Hands-On MCP Build Log (No Otto Required)

I connected Claude to a live ServiceNow PDI using a community MCP server — no Otto, no Action Fabric. Here's what worked, broke, and surprised me.

My last post walked through what ServiceNow Otto and EmployeeWorks actually are, conceptually. This one is different — no keynote summaries, no vendor framing. I connected a real AI client to a real ServiceNow PDI over MCP (Model Context Protocol) and just tried things. Some of it worked cleanly. One assumption I'd made going in turned out to be wrong. That gap between "what the docs imply" and "what actually happens" is the whole point of this post.

If you're a developer sitting where I was — comfortable with ServiceNow, new to MCP — this is the walkthrough I wish I'd had.

A framing note before you read on: what follows is not a test of Otto or EmployeeWorks. Those are ServiceNow's own products, tied to specific releases and licensing, and not something you can spin up on a free PDI. What I actually connected was a third-party, community-built MCP server (nowaikit) talking to my instance over ServiceNow's REST APIs — no Action Fabric, no AI Control Tower, none of ServiceNow's own governance in the loop. Why bother, then? Because the shape of the interaction — an external AI agent asking questions and taking actions against ServiceNow data — is the same shape Action Fabric is built to govern. This post is a look at what that pattern does without any governance wrapper around it, as a baseline for comparing against the real, native version later.

1. The Setup: Isolated, Not on My Local Machine

I didn't want to install anything globally on my work laptop for a first test, so I ran the whole thing inside a GitHub Codespace — a disposable, browser-based Linux container. Nothing here ever touched my local environment.

The stack, in order

• A free Personal Developer Instance (PDI) from developer.servicenow.com — pre-loaded with demo incidents, CMDB CIs, and users.
• A GitHub Codespace as the sandbox (note: Codespaces won't launch against a completely empty repo — commit at least a README first, or tick "Add a README" at repo creation).
• Claude Code, installed inside the Codespace as the AI client (npm install -g @anthropic-ai/claude-code).
• nowaikit, a community MCP server for ServiceNow (npm install -g nowaikit, then npx nowaikit setup), which auto-detected Claude Code and wrote the connection config for me.

The only real hiccup: the setup wizard hung for a bit right after I entered the instance name, with no prompt for credentials yet. Turned out my PDI hadn't been accessed in a while and needed a moment to wake from hibernation — worth checking if you hit the same pause.

2. First Contact: What's Actually Exposed

Once connected, I asked Claude Code directly what tools it had available for ServiceNow. I expected a handful of simple read operations — get incident, list incidents, that kind of thing. What came back was different: 27 capabilities, grouped into five categories — Scan & Monitor, Review & Audit, Build & Generate, Operations, and Documentation. Slash-commands like /scan-cmdb, /review-acls, and /build-flow — this tool is leaning toward developer and governance tooling, not just a conversational query layer.

And separately — the tool also handled plain natural-language questions outside that named list. Asking "list my 5 most recent incidents" returned real data cleanly, with no slash-command needed. Two distinct capability layers stacked in the same tool, which isn't obvious until you actually poke at it.

3. Where the Slash-Commands Broke — Honestly

I tried /scan-cmdb next, expecting an AI-generated CMDB health report. It failed with two distinct errors:

• "No instance specified and no default instance configured. Run nowaikit setup first." — odd, since setup had already run successfully for the natural-language path.
• "Ollama not available."

That second one is the more architecturally interesting finding: the slash-commands aren't just querying data, they're running their own local AI reasoning step to generate the report — and they expect a local Ollama model for that, entirely separate from the Claude Code session already running. So even inside an active AI chat, this tool doesn't reuse that model for its own scan logic; it wants its own.

What impressed me here wasn't the scan succeeding — it didn't. It's that Claude Code, when the built-in scan failed, fell back to pulling the raw CMDB data directly from the instance and gave me an honest partial answer (CI records present, relationship records present, a few sample CI names) instead of pretending the scan had completed. Worth noting as a good behavior, not a given one.

4. The Write Test — Where My Assumption Was Wrong

Going into this, I expected community MCP tools to default to read-only, requiring an explicit opt-in flag before any write reached the instance. That's a reasonable design default, and it's what several tools in this space advertise. So I asked, in plain language: "Create a test incident."

It just did it. No confirmation prompt. No "are you sure." No opt-in flag to enable first.

Created a test incident in ServiceNow:
  • Incident number: INC0010001
  • Short description: "Test incident created by Copilot"

Two things stood out immediately. First, the write executed instantly, no gate at all — a meaningfully different safety posture than I'd assumed going in, and worth correcting plainly rather than glossing over. Second, and almost funnier: the short description read "Test incident created by Copilot" — not Claude, not nowaikit. Almost certainly a hardcoded default string left over in the tool's template from wherever it was originally built or copied from, rather than content actually generated from my request. A small detail, but a telling one: the write executed a canned template rather than reasoning about what to write.

5. Why This Matters More Than It Looks Like It Does

It's easy to read the above as "a demo tool did a demo thing on a demo instance, who cares." But it's worth being precise about what this does and doesn't demonstrate. It's not a flaw in Otto, EmployeeWorks, or Action Fabric — none of those were involved here. What it does demonstrate is exactly the baseline risk ServiceNow's own AI Control Tower materials describe as the reason that governance layer exists: an ungoverned agent operating with more autonomy than intended, no confirmation step, and — this is the part worth sitting with — no clearly attributable audit trail. If the "opened by" field on that incident shows a generic admin user rather than something identifying the AI agent that created it, that's the exact gap a governed setup is designed to close.

That's the actual test I want to run next: the same kind of request, but through ServiceNow's native MCP Server Console with real AI Control Tower governance attached — the genuine Action Fabric experience, not a community stand-in for it. My prediction, to be tested rather than assumed: a governed write should require an explicit permission grant, log the agent identity distinctly from the human operator, and show up in an auditable trail — none of which this community setup gave me by default.

6. If You Want to Try This Yourself

• Use a disposable environment (Codespace, Gitpod, or similar) for a first test rather than a global local install, especially on a managed work laptop.
• Don't assume "read-only by default" for any community MCP tool — verify it yourself, on a PDI, before trusting it near anything that matters.
• Be deliberate with instruction-style phrasing ("create," "update," "delete") until you've mapped out what actually executes without confirmation.
• Treat slash-command failures as information, not dead ends — the fallback behavior often tells you more about the tool's real architecture than a clean success would.

Final Thoughts

The gap between reading about MCP and actually connecting an AI agent to a live ServiceNow instance is smaller than I expected — a free PDI and an afternoon gets you a working setup, no ServiceNow product required. But the gap between "it works" and "it's safe to point at production" is exactly as real as the governance conversation around Otto and Action Fabric suggested it would be — this was the ungoverned baseline, not the real thing. The next post picks up from here: the same test, run through ServiceNow's actual governed Action Fabric setup, to see how much of what I found today gets caught.