ServiceNow and Jira change verification with rConfig MCP: prove only approved lines changed

ServiceNow and Jira change verification with rConfig MCP: prove only approved lines changed

A change request says what will change. rConfig records what did. Comparing the two by hand is tedious, so it often gets skipped: the implementer says “done”, and the ticket closes. An agent connected to rConfig and your ITSM tool can compare the approved plan with the actual diff for every device in the change, and write the result back to the ticket as evidence.

Best for: change managers, CAB evidence, regulated environments where “what actually changed” has to be shown, not asserted. Tools: rConfig, plus a ServiceNow or Jira MCP server. rConfig tools used: get_devices, get_config_history, get_config_diff.

How it flows

sequenceDiagram
    participant A as Agent
    participant T as ITSM MCP<br/>(ServiceNow / Jira)
    participant R as rConfig MCP
    A->>T: Read the change: devices, planned config, window
    loop each device
        A->>R: get_config_history (running config)
        A->>R: get_config_diff (last version before window, first after)
    end
    A->>A: Planned lines vs changed lines
    A->>T: Work note: matched, missing, unplanned

Before the window

The check needs a stored config either side of the change.

• Before: a backup just before the window opens. A scheduled task timed to the window, or a manual download by the implementer, both work.
• After: a backup as soon as the window closes.
• In the ticket: list the affected devices by their rConfig hostnames, and put the planned config lines in a field or attachment the agent can read. A plan written as prose (“tidy up the NTP settings”) can’t be verified line by line.

The prompt

Read change CHG0034512 from ServiceNow. For each device in it, use rConfig to diff the last running-config version before the window start with the first version after the window end. Compare each diff with the planned config in the change. Report three lists per device: planned and done, planned but missing, changed but not planned. Quote the config versions and backup times you used. Then add the report as a work note on the change. Don’t change the change’s state.

An illustrative result:

CHG0034512: NTP server migration (window 22:00-23:00)

dub-core-01  versions 211 -> 212 (21:52, 23:06)
  Planned and done:      ntp server 10.10.0.5 / ntp server 10.10.0.6
  Planned but missing:   none
  Changed but not planned:
    + logging host 10.20.0.9            <- not in the plan

dub-core-02  versions 198 -> 198
  No config change in the window. Planned NTP lines are absent.

Two findings a person would likely miss: an extra logging line slipped into one device, and the second device wasn’t touched at all.

ServiceNow or Jira

Tool names and capabilities differ between releases. Check what your ITSM server exposes before you rely on a write.

Limits to know

• Backup timing defines the window. If another change ran on the same device inside the window, the diff includes both. The agent should say so when the diff contains more than the plan explains.
• Plans have to be specific. The comparison is line by line. Ask implementers to paste the exact config they’ll apply.
• Interface ordering and defaults. Some platforms rewrite or reorder lines when they’re applied. Expect the agent to flag these as differences; a short note in its instructions (“treat reordered lines as matched”) cuts the noise. Diff exclusions in rConfig remove timestamps and counters from diffs at source.

Related reference

• Config diffs
• Diff exclusions
• Scheduled tasks
• Using rConfig with other MCP servers