Will Coffey recently published a piece titled "ClaudeNow: The Wiring Diagram," arguing that everything Salesforce just packaged as Claudeforce (skills, MCP, permission inheritance) ServiceNow already shipped as separate, vendor-supported parts, and that there's nothing to wait for if you're already on the platform. I agree with the thesis. I want to add the part his article doesn't cover, because it's the part most teams actually get stuck on: which of the two ways you wire Claude into ServiceNow determines what you can see and govern afterward, and the two paths are not interchangeable.
This isn't theoretical for us. Over the past few weeks we built both patterns end to end against real ServiceNow instances, hit the actual failure modes (not the happy path), and then went looking in AI Control Tower to see which pattern the platform actually knows about. The answer surprised us enough that it's worth writing up.
The Two Patterns
External (bring your own, or BYO): a small process you run yourself. Stdio transport, OAuth 2.0 Client Credentials grant, opaque tokens, and an explicit table allowlist in code. You own the process, you own the security boundary, and every table it can touch is a line you wrote and can review in a pull request.
Native: ServiceNow's own sn_mcp_server plugin, the MCP Server Console. Tools are Scripted REST APIs, subflows, or Knowledge Graph queries registered against a server, with no external process at all. Authorization Code Grant, JWT tokens, and, critically, every call executes as the authenticated end user, inheriting exactly the roles and ACLs they already have.
Coffey treats the native path as the Claudeforce-equivalent pattern, and functionally it is: permission inheritance, no per-user config, governed tools. What's missing is that the external pattern isn't a lesser version of that. It's a genuinely different trust model, and the platform treats it differently in ways that matter once you're running more than one developer against the same instance.
The Gotchas Nobody's Blog Post Mentions
Coffey warns that when you register Claude as an OAuth client you must set Token Format to JWT, or Claude connects but lists zero tools. That's real, and we hit a sharper version of it. Claude Code CLI (the terminal tool, not claude.ai) cannot connect to a native ServiceNow MCP server at all, for a reason that has nothing to do with configuration. ServiceNow's OAuth issuer is scoped to the whole instance, not per server, which conflicts with the issuer-matching requirement in RFC 8414 §3.3 (and the newer mix-up attack protections in RFC 9207). This isn't a toggle you flip. It looks like an architectural mismatch between how ServiceNow issues OAuth tokens and what the MCP spec now requires of the authorization server. claude.ai's connector UI works around it; the CLI, as of this writing, does not. If your team's plan is "everyone builds MCP servers from their terminal," know up front that the native path is a claude.ai or Claude Desktop connection, not a CLI one.
We also hit a Zurich-release wrinkle worth flagging for anyone still on a pre-Zurich mental model of ServiceNow security: Scripting Governance. Editing any scriptable field, including the operation script on a Scripted REST API, now requires a dedicated role (snc_required_script_writer_permission), separate from admin or security_admin, and it takes a full logout and login to apply. If you don't know to look for it, it presents as a "read-only editor" bug.
What Control Tower Actually Sees
This is the finding I wanted to verify myself rather than assume. AI Control Tower ships two inventory tables relevant here: alm_mcp_digital_asset ("MCP Digital Asset") and cmdb_ci_function_mcp ("MCP Function"). I queried both directly against a real instance rather than trusting documentation or a plausible guess.
- Native MCP servers auto-discover into Control Tower. Stand one up via the MCP Server Console and it shows up as a governed asset: visible, ownable, auditable.
- External MCP servers do not appear anywhere in Control Tower. Confirmed by direct query, not by absence of evidence. A BYO server can hold a live, authenticated connection to production data, and from the platform's own governance surface, it is invisible.
Not under-governed. Not inventoried at all. A live, authenticated connection to your data, with zero platform-level visibility that it exists.
That's the piece I'd add to the wiring diagram. Coffey's governance section (AI Gateway, catalog intake, per-tool observability) is correct and important, but it's scoped to what ServiceNow's own MCP server produces. If your team, or more likely a vendor working with your team who found a tutorial online, stands up an external MCP server against your instance, Control Tower will not tell you it exists. The gap isn't a missing feature. It's a structural blind spot in where the visibility tooling looks.
What This Means If You're Running a Team, Not a Demo
Once more than one developer is building against shared instances, this stops being an architecture preference and becomes a governance decision:
- If you standardize on native, you get automatic inventory and per-user permission inheritance for free, at the cost of the CLI limitation above and whatever the MCP Server Console's current tool types will let you build.
- If you allow external servers, you get full code-level control over exactly what's readable and writable, reviewable in a pull request, versioned, and diffable. But Control Tower can't see it, so your own code review and an explicit table allowlist become the entire governance boundary. No platform safety net, yet.
- The honest middle answer: the tool allowlist in the server's source is your first line of defense (small, reviewable, approved before merge), and branch review is your record of who approved what. That has to carry the weight, because AI Control Tower's asset inventory cannot see this pattern to help you.
Where I Land
Coffey is right that there's nothing to wait for on ServiceNow. The parts are shipped, documented, and usable today. But "wire it up" undersells how much the choice between the two paths matters once governance, not just capability, is the question. Native gets you permission inheritance out of the box. External gets you precision and code-level review, at the cost of stepping outside the platform's own visibility tooling entirely. Know which trade you're making before your team scales past one developer and one instance.
If a vendor is standing up MCP on your instance, ask them which path they're using. That answer is a governance decision, not a footnote.
The full writeup and a working starter kit for both patterns are on GitHub: nykoma/servicenow-mcp-starter-kit.
Nya Akoma. Take Heart.