Wiring Claude into ServiceNow
Skills, tool use, MCP, and Managed Agents — what each is, when to reach for it, and how to host Claude-powered actions inside Employee Center with a human approval gate.
Four ways to give a ServiceNow action predefined behavior. Not interchangeable — pick by what the action needs to touch and where compute should run.
01 / LandscapeThe four building blocks
Agent Skills
hosted containerskill_id. Loaded only when relevant.Messages API + tool use
you host the loopMCP connector
remote tool bridgeManaged agents
Anthropic runs everything02 / DecisionWhich one for ServiceNow?
| If the action… | Use | Why |
|---|---|---|
| Reads / writes SN records | Tool use | Your loop, your auth, PII never leaves your boundary |
| Generates a branded doc/deck | Skill | Reusable formatting + code; pptx/docx skills exist |
| Reaches Slack / HubSpot / SaaS | MCP connector | No client code to maintain |
| Applies a fixed procedure | Tool use or Skill | Determinism over autonomy here |
| Runs long, multi-step, stateful | Managed agent | Anthropic hosts loop + session container |
| Just classifies / summarizes | Plain Messages call | One request, one response — no machinery |
Skills and Managed Agents execute in Anthropic-hosted containers. Per Ondaro policy, client/customer PII must not appear in responses or artifacts — and shouldn't transit a hosted sandbox either. For any action handling records with PII, prefer tool use so data stays in your environment. Route policy questions to people@ondarowave.com; contract questions to contracts@ondarowave.com.
03 / DirectionTwo architectures, opposite arrows
Claude → ServiceNow
Claude (or an external app) reaches into SN via tool use / MCP. SN is a data source & action target.
Good for assistants living outside SN.
ServiceNow → Claude → ServiceNow
An Employee Center widget triggers Claude to reason over SN data, propose changes, then SN acts on approval.
SN owns the loop, the data, and the gate.
04 / The loopSN → Claude → SN, step by step
Tap any node to read what happens at that stage. The gate sits between Claude's proposal and any write-back.
Claude proposes; ServiceNow disposes. Claude returns a structured intent (a tool_use block). It does not touch records. SN validates, shows it to the user, and only approval triggers the actual GlideRecord write.
Where does the loop live?
| Option | How | Trade-off |
|---|---|---|
| SN-orchestrated | Flow / scripted REST builds the request, loops on tool_use, gates writes | ✓ PII stays in SN · any deployment |
| Managed agent | Provision once, open a session per request; Anthropic runs the loop | ⚠ 1P API only · data transits container |
05 / Skills setupUpload once, reference by ID
You do not ship the SKILL.md from ServiceNow on every call. Upload once; Anthropic stores it; reference by skill_id.
Author the skill folder
SKILL.md at root (YAML + markdown), optional scripts/ and resources/. No hardcoded credentials.
Upload via the Skills API
POST to /v1/skills; get back a skill_id and version. Runs from a build/admin job, never SN runtime.
Store the skill_id in SN
Keep an action → skill_id map in a config table. This is your routing layer.
Reference at call time
Include in container.skills, add the code-execution tool, set three beta headers. Up to 8 per request.
# reference a stored skill at call time response = client.beta.messages.create( model="claude-opus-4-8", max_tokens=4096, betas=["code-execution-2025-08-25", "skills-2025-10-02", "files-api-2025-04-14"], container={"skills": [ {"type": "custom", "skill_id": "skill_01J...", "version": "latest"} ]}, tools=[{"type": "code_execution_20250825", "name": "code_execution"}], messages=[{"role": "user", "content": "Draft the SOW..."}], )
Skills won't run without all three: skills-2025-10-02, code-execution-2025-08-25, files-api-2025-04-14. Forget code execution and the skill silently never activates.
06 / Skills + connectorsCan a skill use connectors?
Short answer: yes — but a skill doesn't own a connector. They compose at the request level.
A skill is just instructions + scripts running in the code-execution container. What it can reach depends on the tools you attach to the same Messages request. Include container.skills, the code_execution tool, and an MCP connector in one call, and the skill's instructions can direct Claude to call those MCP tools. The MCP side handles connectivity; the skill side ensures the procedure and output are right.
Same session
A skill and your connected apps share one session — the same Claude can follow a skill and call a connector. Orthogonal by design.
Compose per request
Skills + code execution + MCP connector all attached to one call. The skill orchestrates; the connector provides access.
Code execution + MCP
MCP servers exposed to the container as code APIs. Claude writes code to call only the tools it needs — cuts token cost.
# skill + connector in a single request response = client.beta.messages.create( model="claude-opus-4-8", max_tokens=4096, betas=["code-execution-2025-08-25", "skills-2025-10-02", "mcp-client-2025-11-20"], container={"skills": [ {"type": "custom", "skill_id": "skill_01J..."} ]}, tools=[{"type": "code_execution_20250825", "name": "code_execution"}], mcp_servers=[{ "type": "url", "url": "https://your-mcp-server/mcp", "name": "servicenow-mcp", }], messages=[{"role": "user", "content": "..."}], )
Neither Skills nor the MCP connector is ZDR-eligible — data exchanged with MCP servers (tool definitions and execution results) is retained per Anthropic's standard policy, and runs through the hosted container. There's a tokenization pattern that swaps sensitive fields for placeholders inside the container, but that's a mitigation, not a guarantee.
A skill can drive a connector in one call — but for PII-bearing SN records that routes data through the hosted container and MCP path, which is what the SN-orchestrated tool-use loop was designed to avoid. Keep tool use for record access; reserve skills (with or without connectors) for the non-sensitive generation half. The MCP header recently moved (mcp-client-2025-04-04 → mcp-client-2025-11-20) and tool config now lives in the tools array — confirm the current shape before wiring.
07 / ApprovalTwo gate models for Employee Center
Custom portal modal
Claude's proposed action renders in the widget. User taps Approve/Reject inline; SN executes immediately on approve.
✓ Fast self-service · great UX · low ceremony
Native approval record
SN creates a sysapproval_approver record routed to a manager/queue. Action fires when approved — full audit trail.
✓ Governed changes · delegation & SLA · audit-ready
Let the proposed action's risk decide the gate: low-impact self-service → portal modal; anything touching cost, access, or another person's record → native approval. Claude can suggest the tier; ServiceNow makes the final call.
08 / RecommenderWhat does your action need?
Pick an option to see the recommendation.
09 / Bottom lineFor Ondaro × ServiceNow
- Default to tool use for actions touching SN records or PII — data stays in your boundary.
- Use Skills for stateless, reusable generation where the input isn't sensitive.
- Skills + connectors compose per request, but route PII-bearing access through SN tool use, not the hosted MCP path.
- Add MCP only to reach external SaaS you don't want to hand-code, and only on the first-party API.
- Reserve Managed Agents for long-running stateful workflows, after confirming you're not on Bedrock/Vertex/Foundry.
- Always store skill_ids / agent_ids in SN config and reference by ID — provision once, call many.
These are beta features with dated headers that move fast. Confirm header strings, model IDs, and ZDR/data-retention terms against platform.claude.com before committing architecture.