Returns which platforms are configured and ready to use. Call this at the very start of every session BEFORE asking the user for anything.

Credentials come from one of two places (checked in this order): 1. Session memory — set via configure_credentials (used in web Claude Code) 2. .env file on the server (used in CLI / personal deployment)

If a platform shows configured=false AND the server has no .env: → Call configure_credentials first, then re-call get_config. If a platform shows configured=false AND a .env exists: → The .env is missing that platform's values. Tell the user which vars are needed.

Never ask the user for credentials unless get_config reports a platform is not configured.

Set credentials for this session when running in web Claude Code or any context where a .env file is not present on the server.

WHEN TO CALL THIS:

• Web Claude Code (claude.ai/code): the server is deployed remotely and has no access to the user's .env. Call this once at the start of the session.

• CLI: only needed if the user wants to override their .env for this session.

SECURITY: credentials are held in memory for this session only and are never logged, stored to disk, or returned in any tool response. They are cleared when the session ends.

Only provide credentials for the platforms you actually need. After calling this, call get_config to confirm the platforms are now configured, then call connect to verify the live connections.

Connect to a ServiceNow instance in one step.

WHEN TO CALL: At the start of any session that needs ServiceNow access, or when get_config shows servicenow.configured = false.

HOW TO ASK THE USER: "To connect to your ServiceNow instance I need three things: 1. Your instance URL (e.g. https://yourcompany.service-now.com) 2. Your username 3. Your password These are held in memory for this session only — never stored or logged."

After calling this tool, tell the user whether the connection succeeded and which instance you connected to. Then proceed with their request.

Connect to a Jira Cloud instance in one step.

WHEN TO CALL: At the start of any session that needs Jira access, or when get_config shows jira.configured = false.

HOW TO ASK THE USER: "To connect to your Jira instance I need three things: 1. Your Atlassian URL (e.g. https://yourcompany.atlassian.net) 2. Your Atlassian account email 3. A Jira API token — generate one at: https://id.atlassian.com/manage-profile/security/api-tokens These are held in memory for this session only — never stored or logged."

After calling this tool, confirm the connection and proceed with the user's request.

Connect to a Salesforce org in one step.

WHEN TO CALL: At the start of any session that needs Salesforce access, or when get_config shows salesforce.configured = false.

HOW TO ASK THE USER: "To connect to Salesforce I need: 1. Connected App consumer key (client ID) 2. Connected App consumer secret (client secret) 3. Your Salesforce username 4. Your Salesforce password 5. Your security token (optional — only needed if your IP is not allowlisted) 6. Login URL — use https://test.salesforce.com for sandboxes, otherwise leave default

 To get a Connected App:
   Salesforce Setup → App Manager → New Connected App
   Enable OAuth, add 'api' and 'refresh_token' scopes

 These are held in memory for this session only — never stored or logged."

After calling this tool, confirm the connection and proceed with the user's request.

Create a ServiceNow Update Set before starting any migration setup. An Update Set captures all configuration changes (staging tables, transform maps, field maps, scripts, etc.) into a named package that can be reviewed, exported, and deployed to other ServiceNow instances (e.g. from dev → test → production).

IMPORTANT: Always ask the user for a name before calling this tool. A good name includes the source platform, project/object, and date — e.g.: "Jira KAN Migration - June 2026" "Salesforce Account Migration - v1"

Call this after connect() and before build_artifacts() so all artifacts created during setup are captured in the update set.

Also use list_update_sets to show existing in-progress update sets in case the user wants to reuse one instead of creating a new one.

List all in-progress Update Sets in ServiceNow. Use this before creating a new one — the user may want to reuse an existing update set instead of creating a new one, especially if they are continuing a previous migration session.

Mark a ServiceNow Update Set as complete when migration setup is finished. A completed update set can be exported as an XML file and deployed to other ServiceNow instances (test, UAT, production) via System Update Sets → Retrieved Update Sets. Call this after build_artifacts is done and the user has verified everything looks correct.

Inspect ServiceNow to see what migration artifacts already exist for a given source→target combination. Call this at the very start of any migration session (before build_artifacts) to avoid re-creating things. Returns a gap analysis: what exists, what's missing, and what needs to be added. Works for ANY source platform and ANY ServiceNow target table.

Test live connections to one or all platforms using credentials already stored in .env. Call this after get_config to verify connections are working. Do NOT ask the user for any credentials before calling this — they are already configured. Returns connection status and instance URLs.

Call this BEFORE discover_schema when the user has not told you which ServiceNow table to migrate into. It queries the live SN instance for all tables and ranks them by similarity to the source object name. Returns a ranked list of suggestions + a custom-table fallback. Present the top suggestion(s) to the user and ask them to confirm or choose a different one. NEVER guess or hardcode a table name — always call this first if the target is unknown.

Phase 2: Discover ALL source fields and ServiceNow target fields side by side. Returns complete field lists (every source field is included — none are skipped), auto-suggested staging table definition, and field mapping proposals.

WORKFLOW:

• If sn_table is not known yet, call suggest_target_table first and confirm with the user.

• After calling this, STOP and present all fields + mappings to the user for Checkpoint 1 review.

• For UNMAPPED fields (sn_target=null): highlight them and ask the user to either map them to an existing SN field or confirm they should land only in staging.

• Show the upsert key (coalesce) fields so the user understands duplicate prevention.

• Ask: (1) Are all source fields present? (2) Any mapping corrections? (3) Approve to continue?

• Only call build_artifacts after explicit user approval.

IMPORTANT — target table changes: If the user changes the sn_table AFTER this has been called, call discover_schema AGAIN from scratch. Discard all prior suggested_mappings — target fields will be completely different.

GENERIC: platform can be any string — salesforce, jira, or any registered custom connector.

Phase 4: Create all migration artifacts in ServiceNow: staging table + columns, transform map, field maps, transform scripts, data source, REST message. Only call this after Checkpoint 1 (schema) AND Checkpoint 2 (mappings) are both approved by the user. After this completes, show the artifact summary and ask the user to verify in ServiceNow (Checkpoint 3).

Trial run: sends a small sample of records (default 5) through the full migration pipeline and produces a detailed data quality report.

The report checks three layers: 1. Source (Jira/Salesforce) — what values exist in the original data 2. Staging table — what landed in the ServiceNow staging table 3. Target table — what ended up in the final ServiceNow record (e.g. Incident)

For each mapped field it shows the fill rate (% of records with a value) and flags any field that is blank in staging (source → staging data loss) or blank in the target (staging → target mapping failure).

Only call this after build_artifacts. Only call run_full_migration after the user reviews this report and explicitly says "Approved".

Phase 3: Analyse migration dependencies before building artifacts.

For Jira: - Scans all referenced users (assignee/reporter), checks if they exist in ServiceNow - Identifies issue type hierarchy (Epic/Story → Task/Bug → Subtask) - Proposes a sequenced migration plan (Tier 1 = parents first, Tier 2 = children, etc.)

For Salesforce: - Counts records per object - Detects parent/child object relationships (e.g. Account → Contact, Account → Case) - Checks record owners (OwnerId) against ServiceNow sys_user - Warns if a parent object is not included in the migration scope - Proposes migration order (parent objects first, child objects after)

Always call this after discover_schema and before build_artifacts. If users are missing, ask the user whether to auto-create them in SN.

Inspect an existing ServiceNow transform map and report:

• Field maps (direct vs field map scripts)

• Standalone transform scripts (and whether they have field_name set)

• Issues: orphan scripts, missing field_name, scripts that should be field map scripts

• Suggestions to improve the transform map following best practices Use this to audit a transform map after build_artifacts or to review a manually built one.

Phase 6: Migrate ALL records from source to ServiceNow. For Jira: automatically migrates in dependency order (Tier 1 parents first, then children). For Salesforce: paginated bulk migration. Only call after explicit user approval at Checkpoint 4. Stops immediately on any error and reports what happened.

Remove records that were created during a migration — both from the staging table and from the target table (e.g. incidents).

Use this if: - The test migration created records you want to delete before the real run - A migration went wrong and you want to start fresh - The client asked you to roll back

IMPORTANT: Always ask the user for explicit permission before calling this tool. Show them exactly how many records will be deleted and from which tables. Only proceed after they confirm with "Yes, delete them" or similar.

Remove all migration artifacts that were created in ServiceNow during the setup phase. This deletes (in safe order): 1. Field maps (sys_transform_entry) 2. Transform scripts (sys_transform_script) 3. Transform map (sys_transform_map) 4. Staging table columns (sys_dictionary) 5. Staging table (sys_db_object) 6. Data source (sys_data_source) 7. REST message (sys_rest_message)

Use this when you want a completely clean slate — for example after a failed migration setup, or when the customer wants to restart with different field mappings.

IMPORTANT: Always discover first (confirmed=false) to show the user exactly what will be deleted. Only delete after they explicitly confirm with "Yes, delete them" or similar.

Verify that record counts match across all three layers of a migration: Source (Jira / Salesforce) → Staging table → Target table

Checks: - How many records exist in the source - How many rows landed in the staging table - How many records were created in the target table - Whether staging count matches source (no records lost in transit) - Whether target count matches staging (no records lost in transform) - Whether there are MORE records in staging or target than in source (duplicates)

Use this after a full migration to confirm data integrity. Also useful after a test migration to see how many records were actually moved.

List all active Salesforce flows with their types. Use this to show the user what flows are available before asking which to migrate. Screen Flows are flagged as manual-only.

Phase F3: Fetch and parse a Salesforce flow's full metadata. Returns structured breakdown of trigger, variables, and elements. After calling, present the analysis to the user and ask the clarifying questions required for Checkpoint F1. Only call build_flow after user confirms the understanding is correct.

Generates a clear, numbered step-by-step guide for manually building a Salesforce or Jira flow/automation inside ServiceNow Workflow Studio.

Does NOT touch ServiceNow via API — it only produces a human guide. Call this after analyze_flow or analyze_jira_automation.

The guide covers every click: where to go, what to name things, which trigger to choose, how to add each step and fill in its fields.

Query any ServiceNow table — useful for checking staging table results, verifying migrations, or fetching incidents.

Collects all data needed to produce a customer-facing field mapping sign-off report. Returns structured content (source schema, SN schema, approved mappings, staging definition, artifact sys_ids, migration stats if available) ready for Claude to render as a Word document. Call this after discover_schema and optionally after build_artifacts / run_full_migration. Claude should then use the docx skill to produce a .docx file from the returned data.

Verifies the ServiceNow integration user can read, create, update, and delete records on the target table. Call this BEFORE build_artifacts to catch permission problems early.

Shows what target fields will be set when a staging row is transformed — no record is persisted. Useful for validating the transform map after build_artifacts.

Deletes target records that were created by a migration, identified by correlation_id prefix (e.g. "jira:" or "salesforce:"). Two-phase: first call with confirm=false to see the count, then confirm=true to delete.

Copies attachments from source records to their corresponding ServiceNow target records. Matches via correlation_id (jira: or salesforce:).

Copies source comments into the ServiceNow target record's comments or work_notes journal. Each comment is appended with its original author and timestamp.

Runs a migration of records that have changed since the last delta sync (uses a stored watermark in ServiceNow). First run migrates everything and stores the current time as the watermark.

Polls the active import set runs in ServiceNow until they all complete (or 5 minutes elapse). Use after kicking off a bulk migration to watch live progress.

Deletes completed sys_import_set_run records older than the given number of days. Run periodically to keep the instance healthy.

Preview how many records will be migrated before committing to a full run. Returns the total record count and a sample (up to 5 records) matching the query. ALWAYS call this before run_test_migration or run_full_migration when the user wants to filter or scope the migration — e.g. "only migrate closed tickets" or "just the records from 2024". This prevents accidentally migrating too many records.

For Jira: filter is JQL (e.g. "status = Done AND created >= 2024-01-01") For Salesforce: filter is a SOQL WHERE clause (e.g. "Status = 'Closed' AND CreatedDate >= 2024-01-01T00:00:00Z")

Lists all Jira Automation rules visible to the authenticated user. Call this when the user wants to migrate Jira automations to ServiceNow Flow Designer. Returns a summary of each rule: name, trigger type, number of conditions/actions, enabled state. After calling this, show the list and ask which automation(s) the user wants to migrate.

Fetches and analyses a specific Jira Automation rule and produces a migration plan for ServiceNow. Returns: trigger type, conditions, actions, what can be automated vs manual. After calling this, present the plan and ask the user to confirm before building.

Builds the ServiceNow Flow Designer artifacts for a Jira Automation rule. Creates the flow record, trigger, condition blocks, and action steps. Steps that cannot be automated are skipped — the manual build guide explains what to do. Only call this after analyze_jira_automation and user confirmation.

Load all ServiceNow users and groups into memory, then resolve a list of source-platform users (Jira / Salesforce) to ServiceNow sys_user sys_ids. Returns a match report with matched/unmatched lists and the fallback user used. Call this before running a migration that has assignee / owner / reporter fields.

Run all pre-migration validation checks against the target ServiceNow table before importing any data. Checks: (1) picklist/choice values, (2) reference integrity, (3) required field coverage, (4) business rule conflicts. Returns a pass/fail report with blocking issues and warnings. Always call this before run_migration.

Apply field transformation rules to a sample set of source records and return the transformed output. Use this to verify date formats, boolean normalization, status mapping, and custom transforms BEFORE running the full migration. Supports built-in presets: jira_status, jira_priority, sf_status, sf_priority.

Convert rich text from source platforms to ServiceNow-compatible HTML. Supports Jira ADF (JSON document format), Salesforce HTML, and plain text. Use hint="auto" to auto-detect. Returns converted HTML safe for SN fields.

Sort a list of entity types / record IDs in dependency order (parents before children). Useful for relationship-aware migration — e.g. migrate Epics before Stories before Sub-tasks. Provide nodes (IDs) and edges ([parentId, childId] pairs). Returns the sorted order.

Open an audit trail log file for this migration session. All subsequent migrations will be recorded with before/after field values, timing, and error details. Call this once at the start of any production migration.

Return current audit trail statistics for the active migration session. Shows counts of created, updated, skipped, and errored records, plus average time per record.

Deep comparison between source records and ServiceNow target records to verify the migration was successful. Goes far beyond fill-rate checks:

1. COUNT CHECK — source count vs SN count (detects missing or duplicate records)

2. RECORD MATCHING — correlates each source record to its SN counterpart using a correlation field (e.g. u_jira_key, u_sf_id)

3. FIELD-LEVEL DIFF — for every matched pair, compares each mapped field value Expected vs Actual, with transform-awareness (so a Jira "In Progress" → SN state "2" is not flagged as a mismatch)

4. VERDICT — PASS / PARTIAL / FAIL with specific reasons

Returns: verdict, per-record diffs, per-field accuracy %, missing/extra records. Use after a test migration or a full migration to confirm data integrity.

Compare the ServiceNow STAGING table against the TARGET table to verify that the transform map correctly moved all records from staging into the real table.

This is the staging → target leg of the three-layer quality check: Source → [staging] → Target

Fetches the most recent N staging records, looks up their corresponding target records via sys_target_sys_id, then compares every mapped field value.

Returns: per-record diffs, per-field accuracy, missing target records.

Generate a complete end-to-end migration test report covering all three layers:

 Source (Jira/SF) → Staging Table → Target Table (ServiceNow)

Combines the existing validate tool (fill-rate check) with deep reconciliation to produce a single pass/fail report with actionable fix guidance.

Use this after a test migration of 5–50 records before running the full migration. Returns a human-readable verdict + specific fields/records that need fixing.

Analyse a user's bidirectional integration requirement and produce a complete, structured integration plan. Supports all platform combinations: servicenow ↔ jira | servicenow ↔ salesforce | jira ↔ salesforce

The plan specifies every artifact that must be created on each platform:

• Correlation table (cross-platform ID mapping)

• Retry/error table (dead-letter queue)

• Business Rules, Scripted REST APIs, Outbound REST Messages (ServiceNow)

• Apex Trigger, Queueable class, Named Credential (Salesforce)

• Webhook, Automation rule (Jira)

• Best-practice checklist (loop prevention, auth, idempotency, etc.)

Call this FIRST before any create_integration_* tool. Pass the result to the other tools to actually create the artifacts.

Create all ServiceNow-side artifacts for a bidirectional integration:

• Correlation table (cross-platform ID tracking)

• Retry/error table (dead-letter queue for failed syncs)

• Sync-in-progress flag field (loop prevention)

• sys_properties entry (field mapping config)

• Outbound REST Message + HTTP method (for SN→external calls)

• Business Rule (fires on record change, calls outbound REST)

• Scripted REST API + POST operation (inbound endpoint for external→SN)

• UI Action "Sync Now" button

• Client Script (shows sync status on form)

Requires the integration plan from design_integration.

Create Jira-side artifacts for a bidirectional integration:

• Registers a Jira webhook (calls the inbound endpoint when issues change)

• Generates a Jira Automation rule JSON (ready to import in Jira UI)

• Returns step-by-step instructions for importing the automation rule

The automation rule includes loop-prevention via issue labels. Requires the integration plan from design_integration.

Generate all Salesforce-side code and configuration for a bidirectional integration:

• Named Credential XML (paste into Metadata API or create in Setup UI)

• Apex Queueable callout class (async HTTP call to the partner platform)

• Apex Trigger (fires on insert/update, enqueues the callout class)

• Inbound Apex REST class (receives sync calls from the partner platform)

• Step-by-step deployment instructions

Note: Apex code is GENERATED and returned as strings — the user must deploy it via Developer Console, VS Code + SFDX, or Metadata API. Requires the integration plan from design_integration.

Check the health of a running bidirectional integration by querying:

• Correlation table: how many records are linked

• Retry/error table: how many failed syncs are pending

• Recent sync activity (last N records synced)

Use this to monitor the integration after it goes live.

Send a single test payload through the bidirectional integration end-to-end and verify it arrives correctly on the other side.

For SN→external: touches a specific SN record (sets a harmless field) to fire the Business Rule, then polls the correlation table to confirm the external record was created/updated.

For external→SN: POSTs a test payload directly to the SN Scripted REST API inbound endpoint and verifies the SN record was updated.

Returns: pass/fail verdict, response from both sides, correlation record state.

Pause a bidirectional integration by deactivating the Business Rule (outbound) and the Scripted REST API (inbound) without deleting them. Use this for maintenance windows, debugging, or bulk imports where you don't want sync to fire. Call enable_integration to resume.

Resume a paused bidirectional integration by re-activating the Business Rule, Scripted REST API, and retry scheduled job.

Update the field mapping configuration for an existing integration without recreating any artifacts. The mapping is stored in a sys_property record — this tool updates that property and returns the new active mapping.

Use when adding new fields to sync, removing fields, or correcting a mapping mistake. Changes take effect immediately on the next sync event.

Retry all failed sync attempts from the integration error/retry table. For each failed record, re-fires the Business Rule by touching the source record. Pass dry_run=true to see what would be retried without actually doing it.

Generate a complete, production-ready ServiceNow script with industry best practices baked in.

Supported types: business_rule — Server-side BR with guard, try/catch, async option script_include — Prototype-class SI with JSDoc and error envelope client_script — onChange/onLoad/onSubmit/onCellEdit with safe patterns ui_action — Server or client UI Action with redirect/confirm flow scripted_rest — Full Scripted REST API with auth, logging, error envelope scheduled_job — Scheduled job with timing, batch counting, error logging fix_script — One-time data fix with dry-run support and audit log widget — Service Portal widget stub (template + server + client)

Returns ready-to-deploy script code plus best-practice checklist and deploy field values.

Static analysis code review for a ServiceNow script.

Checks for:

• Critical: eval(), hardcoded credentials, SQL/SOQL injection risk, unvalidated input

• Anti-patterns: GlideRecord in loops, no setLimit, hardcoded sys_ids, gr.get in loops

• Performance: full table scans, getRowCount, sync REST in BR, GlideAggregate opportunities

• Null safety: missing gs.nil(), JSON.parse(null) risk, unchecked gr.get() return

• Best practices: gs.print vs gs.info, no error handling on REST, bulk updates without setWorkflow

Returns a score (0-10), verdict, and per-issue fix guidance.

List all code review rules with descriptions and fix guidance. Useful for understanding what review_script checks.

Full schema discovery for a ServiceNow table.

Returns:

• Table metadata (parent, scope, numbering, ACL flags)

• All fields (name, label, type, reference, mandatory, read-only)

• Active Business Rules (when, events, conditions)

• Active Client Scripts (type, field)

• ACL rules (operation, type, roles)

• Incoming relationships (which tables reference this one)

• Table hierarchy (parent chain up to Task or base)

• Summary counts

Use this before writing a BR or Client Script to understand the full context.

Search for ServiceNow tables by keyword (name or label). Returns up to 25 matches.

Get all ACL rules for a ServiceNow table, including field-level ACLs.

Generate ATF (Automated Test Framework) test cases for ServiceNow artifacts.

Supported test targets: business_rule — positive, negative, and field-change trigger tests script_include — unit tests per method (happy path + null/invalid input) scripted_rest — auth, validation, and custom scenario tests form — Client Script / UI Policy field behaviour tests table — mandatory field, uniqueness, and basic CRUD smoke tests

Returns ATF test suite JSON with steps ready to import + deploy instructions.

Analyse ServiceNow instance performance. Supported modes:

slow_scripts — Find slow Business Rules and scripts from syslog (last N minutes) scheduled_jobs — Audit scheduled job durations suggest_indexes — Suggest DB indexes for a table based on BR query patterns error_patterns — Cluster recent system log errors by pattern audit_business_rules — Full BR performance audit for a table (no conditions, sync REST, etc.)

Search ServiceNow system logs (syslog table) by keyword, source, or level. Useful for debugging Business Rules, integrations, and scheduled jobs.

Execute a server-side script in ServiceNow using the Background Scripts table (sys_script_fix).

IMPORTANT: Creates a Fix Script record and marks it for execution. The script runs as admin. Only use for safe, tested scripts. Always dry_run first to preview the record that will be created.

Generate Markdown documentation for ServiceNow artifacts.

Supported doc targets: script_include — Full API reference with method signatures and usage examples business_rule — Metadata, risk analysis, script preview table — Field catalogue, BR list, ACL list, relationships scripted_rest — Endpoint reference, parameters, error codes application — Full component inventory

Returns Markdown text ready to paste into Confluence, GitHub, or a wiki.

Generate a complete application scaffold for a new ServiceNow application.

Creates a recommended file/artifact structure with:

• Main application table (u_)

• Number prefix and auto-numbering

• Core Business Rules (set number, state management)

• Script Include for business logic

• UI Action for state transitions

• ACL rules (read/write/delete)

• ATF test suite

• Documentation

Returns all scripts ready to create in ServiceNow.

Run a comprehensive health check on the connected ServiceNow instance.

Checks:

• Instance connectivity and response time

• Recent error count in syslog

• Scheduled jobs with no recent success

• Tables with no indexes on commonly-queried fields

• Business Rules with no conditions (fires on every record)

• Failed integration sync records

• System properties health

Returns an overall health score and prioritised action list.

Explain a ServiceNow API, class, or method with examples and best practices.

Topics you can ask about: GlideRecord, GlideAggregate, GlideScopedEvaluator, GlideSystem (gs), RESTMessageV2, GlideAjax, GlideDateTime, GlideUser, GlideFlow, ServiceNow Table API (REST), Scripted REST API pattern, Business Rule lifecycle, Script Include class pattern, Client Script event types, ATF step types

Analyze a complete Service Portal — pages, widgets, theme, widget usage counts.

Provide the portal's URL suffix (e.g. "sp" for the default portal) or its sys_id.

Returns:

• Portal metadata (title, theme, homepage)

• All pages (title, ID, public/private, roles)

• Widgets available on the instance

• Widget usage counts across pages

• Theme details (CSS variables)

• Summary statistics

Use this before starting portal development to understand what already exists.

Search for Service Portal widgets by name, ID, or keyword. Returns up to 20 matches with sys_ids.

Clone an existing Service Portal widget with a new name and optional modifications.

Fetches all 4 widget sections (template, CSS, client script, server script) plus option schema from the source widget, then produces a ready-to-deploy payload for the cloned version with your modifications applied.

Modifications you can apply at clone time: template, css, client_script, server_script, option_schema, demo_data, description

Returns: POST-ready payload for sp_widget table + provenance comment in each section.

Generate a complete, production-ready Service Portal widget from a requirement description.

Generates all 4 sections with best practices baked in:

• HTML template: panel layout, loading/error states, AngularJS binding

• CSS: theme-variable-based styling (no hardcoded colors)

• Client script: c.data pattern, c.server.update(), spUtil feedback

• Server script: try/catch, input dispatcher, GlideRecord with limit

• Option schema: title + limit + any custom options

Returns deploy-ready payload + best practices + deploy instructions.

Build a PATCH payload to update specific sections of an existing widget.

Provide the widget sys_id and only the sections you want to change. Returns a PATCH payload ready to send to /api/now/table/sp_widget/{sys_id}.

Updatable sections: template, css, client_script, server_script, option_schema, demo_data

Scaffold a new Service Portal with theme, default pages, and best-practice CSS variables.

Generates:

• Portal record (url_suffix, title)

• Theme with full CSS variable set (brand colors, typography, spacing, borders)

• Default pages: Home, Login, Profile, Catalog + any custom pages

• Deploy order and instructions

Returns all payloads in correct deployment order.

Generate a complete Service Catalog item definition with variables, client scripts, and UI policies.

Variable types supported: single_line, multi_line, multiple_choice, yes_no, reference, date, date_time, checkbox, select_box, numeric, email, url, phone, masked, file_attachment, container_start, container_end, label

Returns:

• Catalog item payload (deploy to sc_cat_item)

• Variable payloads (deploy to item_option_new)

• Client script payloads (deploy to catalog_script_client)

• UI policy payloads (deploy to catalog_ui_policy)

• Deployment order and best-practice checklist

Clone an existing Service Catalog item — fetches live data from ServiceNow and returns a deploy-ready copy.

Copies:

• Catalog item fields (name, description, category, price, workflow, etc.)

• All variables (name, type, mandatory, default, order)

You can override any field via modifications.

Create a Service Catalog category (sc_category). Returns deploy-ready payload.

Fetch a catalog item and its variables from ServiceNow for inspection or cloning.

Create a ServiceNow email notification with an HTML template, recipients, and conditions.

Recipients can be specified as:

• field: a field on the record (e.g. "caller_id.email")

• group: an assignment group sys_id

• role: a role name (all users with that role)

• user: a specific user sys_id

The tool generates:

• Notification record payload (sysevent_email_action)

• Responsive HTML email template with ServiceNow field tokens

• Plain text fallback

• Best practice checklist

Analyze all active email notifications for a ServiceNow table.

Checks for:

• Notifications with no condition or event (fires on every record)

• Notifications with no recipients (goes nowhere)

• Notifications with weight = 0 (potential conflicts)

• Missing subjects

Returns a notification inventory plus issues and recommendations.

Create a ServiceNow push notification for the Now Mobile app.

Returns deploy-ready payload for sys_push_message table. Supports ${field} tokens in title and body — same as email notifications.

Generate a ServiceNow Email Script (sys_script_email) for dynamic notification logic.

Email Scripts are used when a notification needs:

• Dynamic recipients (e.g. add manager as CC)

• Conditional subject lines

• Dynamic body content based on record state

• Loop-prevention logic

Returns deploy-ready payload with best-practice template.

Generate comprehensive technical documentation for a ServiceNow application by pulling live data from the instance.

Produces a full Markdown document with:

• Executive overview and architecture diagram

• Data model (fields, mandatory markers, reference links)

• Business logic (BRs, Script Includes with method listing)

• UI layer (Client Scripts, UI Actions by table)

• Integration points (Scripted REST APIs)

• Automation (Scheduled Jobs, Notifications)

• Security (ACLs per table, scope isolation)

• Operations guide (monitoring, maintenance, common issue matrix)

• Change log template

The document is ready to paste into Confluence, GitHub Wiki, or any Markdown renderer.

Generate a quick one-page technical spec for a specific feature or change.

Covers affected tables, Business Rules, Script Includes, notifications, and test plan. Use this for sprint documentation, change requests, or PR descriptions.

Diagnose a ServiceNow issue from a symptom description and get a guided step-by-step fix.

Covers 60+ known issues across: business_rule, client_script, scripted_rest, portal_widget, catalog, notification, performance, security, atf, deployment, general

Examples: "Business Rule not firing on update" "Widget shows blank white box" "Email notification not being received" "Catalog item not visible in portal" "Infinite loop in BR" "GlideAjax callback not called"

Returns: root causes, diagnosis steps, copy-paste fix code, prevention tips, and suggested MCP tools to use.

Get the full guided fix for a specific known issue by its ID (e.g. "BR001", "CS002", "SP001").

Use list_common_issues first to find the ID of the issue you want.

List all known ServiceNow issues in the guide, optionally filtered by category.

Categories: business_rule, client_script, scripted_rest, portal_widget, catalog, notification, performance, security, atf, deployment, general

Returns grouped issue IDs and titles. Use get_issue_guide(id) to get the full fix.

Get all choice list values for a field on a ServiceNow table (e.g. state, priority, category).

Add a new choice value to a field's choice list in ServiceNow.

Returns deploy-ready payload for the sys_choice table. Common use: adding custom states, priorities, categories, or types.

Create or update a ServiceNow Dictionary Override on a child table.

Dictionary overrides let you change how an inherited field behaves in a child table WITHOUT modifying the parent table's dictionary entry. This is the correct SN best practice for table extensions (e.g. incident extends task).

IMPORTANT: Each override requires BOTH a value AND its matching override_X=true flag. This tool sets them correctly — doing it manually often silently fails.

Supported overrides (specify any combination): mandatory — Make the field required in the child table (true/false) default_value — Set a different default value for the child table column_label — Rename the field label in the child table only read_only — Make the field read-only in the child table (true/false) display — Show or hide the field in the child table (true/false) calculation — Override a calculated field formula (script string) choice — Override the choice list (use create_choice to add child-table choices, then set this) dependent — Override the dependent field name

Examples: Make "business_service" mandatory on incident (but not on task): table="incident" field="business_service" overrides={mandatory: true}

Set a different default priority on change_request than task: table="change_request" field="priority" overrides={default_value: "3"}

Rename "caller_id" label to "Requested By" on sc_request: table="sc_request" field="caller_id" overrides={column_label: "Requested By"}

Hide a parent field on a specific child table: table="hr_case" field="parent" overrides={display: false}

List all dictionary overrides on a table, or find overrides for a specific field.

Use this to audit what a child table has customised vs its parent, or to check whether an override already exists before creating one.

Examples: table="incident" — all overrides on incident table="incident" field="priority" — override for one specific field field="mandatory" override_type="mandatory" — find all tables overriding mandatory

Delete a dictionary override, restoring the child table field to its parent table defaults.

SAFETY: Requires confirm=true. Deleting an override immediately restores parent behaviour — e.g. if the override made the field mandatory, it will become optional again after deletion.

Find the sys_id first with get_dictionary_overrides.

Create a record in any ServiceNow table via the Table API.

Examples: table="incident" fields={short_description:"Server down", priority:"1", category:"hardware"} table="sc_task" fields={short_description:"Provision laptop", assigned_to:"john.doe"} table="sys_user" fields={user_name:"jsmith", first_name:"John", last_name:"Smith", email:"j@co.com"} table="u_my_custom_table" fields={u_field:"value"}

Returns the created record including its sys_id.

Read one or many records from any ServiceNow table.

• Provide sys_id to fetch a single record by ID

• Provide query (encoded query string) to search multiple records

• Leave both blank to get the first N records

Examples: table="incident" sys_id="abc123..." table="incident" query="active=true^priority=1^assigned_to=javascript:gs.getUserID()" limit=10 table="sys_user" query="active=true^email=john@company.com" table="sc_cat_item" query="active=true^nameLIKElaptop" fields="name,short_description,price"

Update a ServiceNow record by sys_id (PATCH — only the fields you provide are changed).

Examples: table="incident" sys_id="abc123" fields={state:"6", close_notes:"Resolved by restart"} table="sys_user" sys_id="xyz456" fields={title:"Senior Engineer", department:"Engineering"} table="sc_task" sys_id="def789" fields={assigned_to:"jane.doe", state:"2"}

Returns the updated record.

Delete a ServiceNow record by sys_id.

SAFETY: You must pass confirm=true explicitly — this cannot be undone.

Examples: table="incident" sys_id="abc123" confirm=true table="u_staging_jira_kan" sys_id="xyz456" confirm=true

To preview what will be deleted without actually deleting, pass confirm=false (default).

Create any Jira resource. Set resource_type to choose what to create.

resource_type options: issue — Create an issue/ticket (most common) comment — Add a comment to an issue subtask — Create a sub-task under a parent issue component — Add a component to a project version — Create a version/release in a project label — Labels are set on issues, not created separately

Issue example: resource_type="issue" project_key="KAN" issue_type="Task" summary="Set up monitoring for prod servers" description="Install Datadog agent on all prod nodes" priority="High" assignee="jsmith" labels=["ops","monitoring"]

Comment example: resource_type="comment" issue_key="KAN-42" body="Picked up — will update by EOD"