servicenow-platform-mcp

Overview Schema Source Related Servers Score Discussions Admin

flow

Inspect ServiceNow workflow definitions, triggers, and encoded value blobs to analyze automation logic and troubleshoot configurations without modifying data.

Instructions

Inspect Flow Designer flows, triggers, and value blobs (read-only).

Args: action: 'contract' | 'inspect' | 'find_by_table' | 'decode_values' | 'list_triggers' | 'describe'. sys_id: Flow sys_id (contract/inspect; mutually exclusive with name). name: Flow name (contract/inspect; mutually exclusive with sys_id). value: gzip+base64+JSON blob to decode (decode_values). table: Target table (find_by_table; optional filter for list_triggers). trigger_type: Trigger type filter (list_triggers, e.g. 'record_update'). active: 'true' | 'false' filter (list_triggers). limit: Row cap for list_triggers (default 100). sections: Comma-separated inspect/contract sections. Empty uses the compact default; '*' returns all. section_limit: Shared cap for selected flow rows/nodes (default 100, max MAX_ROW_LIMIT).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No
`limit`	No
`table`	No
`value`	No
`action`	Yes
`active`	No
`sys_id`	No
`sections`	No
`trigger_type`	No
`section_limit`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.12.0Sep 1, 2026

addedInput schema / properties / section_limit

Added value: +{
+  "default": 0,
+  "title": "Section Limit",
+  "type": "integer"
+}

addedInput schema / properties / sections

Added value: +{
+  "default": "",
+  "title": "Sections",
+  "type": "string"
+}

First observedv0.10.0May 30, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations present, the description carries the full safety burden and explicitly declares 'read-only' up front. It also discloses defaults and caps for limit, section_limit, and sections behavior, plus the sys_id/name mutual exclusion, which are meaningful beyond the schema fields.

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

Conciseness5/5

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

The description is a compact, front-loaded docstring: one purpose sentence followed by a parameter-to-action map. No line is redundant; the actionable constraints (mutual exclusivity, defaults, wildcard behavior) are included without fluff.

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 ten-parameter, six-action tool with no schema descriptions, the description addresses almost all invocation details, and an output schema is available for return values. The main residual gap is that the 'contract' action is named and referenced by 'sections' but never defined, which leaves some ambiguity for an agent deciding to use it.

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

Parameters5/5

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

Schema description coverage is 0%, and the description compensates completely by defining the action enum, which parameter applies to which action, value encoding, defaults, and the sys_id/name exclusivity constraint. Every parameter receives semantic context that is not visible in the input schema alone.

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

Purpose4/5

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

The opening line names a specific action and resource: 'Inspect Flow Designer flows, triggers, and value blobs (read-only).' The args list clarifies it is a multi-action utility, but it does not explicitly contrast itself with sibling tools such as query, record_read, or describe, so sibling differentiation is left to the reader.

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

Usage Guidelines3/5

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

The Args section associates each parameter with the action in which it is used (e.g., 'value: gzip+base64+JSON blob to decode (decode_values)'), which implies the appropriate invocation pattern. It never states when to prefer this tool over sibling alternatives or when not to use it, leaving the selection criteria implicit.

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

Install Server