Skip to main content
Glama
tedorigawa001

ServiceNow-MCP

by tedorigawa001
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

scan_vulnerabilities

Create a Vulnerability Response scan (sn_vul_scan) for a set of CIs or Vulnerable Items and hand it to the active scanner integration, the same way the "Initiate Scan" / "Rescan" actions do. Needs an active scanner (sn_vul_scanner, e.g.

Instructions

Create a Vulnerability Response scan (sn_vul_scan) for a set of CIs or Vulnerable Items and hand it to the active scanner integration, the same way the "Initiate Scan" / "Rescan" actions do. Needs an active scanner (sn_vul_scanner, e.g. Qualys/Tenable/Rapid7) unless initiate=false, which leaves a Draft scan to launch from the UI. Runs as a server script in a run-once job (SCRIPTING_ENABLED) because the scan state and target links are not writable through the Table API. [Write]

Input Schema

NameRequiredDescriptionDefault
initiateNotrue (default): set the scan to Processing so the scanner integration picks it up. false: leave it in Draft.
ci_sys_idsNocmdb_ci sys_ids to scan (max 200). Use this or vulnerable_item_sys_ids, not both.
wait_secondsNoHow long to wait for the run-once job that creates the scan (0-120, default 30). If it has not run by then the job is left scheduled and scan_scheduled is returned.
scanner_sys_idNosn_vul_scanner sys_id. Defaults to the active scanner flagged as default.
vulnerable_item_sys_idsNosn_vul_vulnerable_item sys_ids to rescan (max 200)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.15.1
    • changedInput schema / properties / ci_sys_ids / description
      Previous value: -"CI sys_ids to scan"New value: +"cmdb_ci sys_ids to scan (max 200). Use this or vulnerable_item_sys_ids, not both."
    • removedInput schema / properties / group
      Removed value: -{
-  "description": "CI group to scan (alternative to ci_sys_ids)",
-  "type": "string"
-}
    • addedInput schema / properties / initiate
      Added value: +{
+  "description": "true (default): set the scan to Processing so the scanner integration picks it up. false: leave it in Draft.",
+  "type": "boolean"
+}
    • removedInput schema / properties / scan_type
      Removed value: -{
-  "description": "Scan type: full, quick, compliance (default full)",
-  "type": "string"
-}
    • addedInput schema / properties / scanner_sys_id
      Added value: +{
+  "description": "sn_vul_scanner sys_id. Defaults to the active scanner flagged as default.",
+  "type": "string"
+}
    • addedInput schema / properties / vulnerable_item_sys_ids
      Added value: +{
+  "description": "sn_vul_vulnerable_item sys_ids to rescan (max 200)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / wait_seconds
      Added value: +{
+  "description": "How long to wait for the run-once job that creates the scan (0-120, default 30). If it has not run by then the job is left scheduled and scan_scheduled is returned.",
+  "type": "number"
+}
  2. First observedv1.0.2

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing the execution mechanism (server script in a run-once job requiring SCRIPTING_ENABLED because scan state and target links aren't writable via the Table API), the scanner prerequisite, the Draft-vs-Processing state effect of initiate, and the [Write] marker. This is exactly the operational context an agent needs before invoking a non-idempotent write.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and mechanism in the first sentence, then prerequisites and state behavior, with the [Write] tag closing it out. Dense but every clause carries information; the parenthetical detail makes it slightly heavy but not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a non-idempotent write with no output schema, the description covers prerequisites, execution model, and state side effects. It does not describe what is returned (scan sys_id, scan_scheduled), though the schema's wait_seconds note hints at the latter — a minor gap against an otherwise strong definition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all five parameters including initiate's default and wait_seconds' range. The description only reinforces initiate and the scanner requirement; it adds no syntax or mutual-exclusion detail beyond what the schema states. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (create) and resource (Vulnerability Response scan, sn_vul_scan) and names the exact table targets (CIs or Vulnerable Items), plus the analog UI actions 'Initiate Scan'/'Rescan'. An agent knows precisely what this produces without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the prerequisite (an active sn_vul_scanner such as Qualys/Tenable/Rapid7) and the alternative mode (initiate=false leaves a Draft to launch from the UI). It also clarifies the either/or selection of ci_sys_ids vs vulnerable_item_sys_ids. No sibling-tool comparison is offered, but no direct vulnerability-scan alternative appears in the sibling list, so this is close to complete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools