Skip to main content
Glama
jshsakura

mfa-servicenow-mcp

by jshsakura
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

manage_flow_designer

Read and edit ServiceNow Flow Designer flows: inspect action inputs, trigger/branch conditions, clone branches, and publish approved changes.

Instructions

Flow Designer read/edit: action inputs, trigger/branch conditions, add_branch (clone a branch). Publish via action='publish' (needs confirm + confirm_publish). (confirm='approve')

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryNo
scopeNoScope namespace
actionYesWrites (checkout/set_*/add_branch/save/publish/activate/deactivate/copy/update) need browser auth; rest are reads.
offsetNo
confirmYes
flow_idNoFlow sys_id; get_detail also accepts flow_name instead
node_idNoAction/logic/trigger instance id; on get_detail reads that ONE step in full
flow_nameNoFlow name: get_detail exact/contains lookup, or executions filter
flow_typeNoflow (default) | subflow | all | action | playbook | decision
action_refNoAction sys_id/name; discover via action=list with flow_type=action
context_idNoExecution sys_id (sys_flow_context)
count_onlyNo
exec_stateNoComplete/Error/Waiting/Cancelled/In Progress
trace_pillNoTrace data pill through flow
errors_onlyNo
flow_statusNoStatus: Draft/Published/etc
name_filterNoName contains-match
source_recordNoSource record display value
summary_formatNoCompact format; False = raw JSON
confirm_publishNo
include_inactiveNo
include_triggersNo
include_versionsNo
include_structureNo
include_subflow_treeNo
include_executions_summaryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.24.61
    • addedInput schema / properties / node_id
      Added value: +{
+  "description": "Action/logic/trigger instance id; on get_detail reads that ONE step in full",
+  "type": "string"
+}
  2. Changed1 schema field changedv1.23.8
    • addedInput schema / properties / confirm_publish
      Added value: +{
+  "enum": [
+    "approve"
+  ],
+  "type": "string"
+}
  3. Addedv1.21.20
  4. Removedv1.21.13
  5. First observedv1.18.41

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the transparency burden and does disclose the mutation/edit nature, the publish confirmation requirement, and the clone behavior of add_branch. However, it omits side effects, browser-auth requirements for writes, and reversibility details; some of this is available in the schema's action property description but not in the tool description itself.

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?

The description is compact and front-loaded with the resource and main purpose. The parentheticals are dense but efficient; there is almost no filler.

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

Completeness2/5

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

This is a high-complexity tool with 27 parameters, no output schema, and no annotations. The description covers only a small subset of operations and does not explain return values, auth constraints, or typical publish/edit flows, so an agent would need to infer much from the schema.

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

Parameters2/5

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

Schema coverage is only 52%, so the description should compensate, but it only clarifies a few parameters: action='publish', confirm='approve', confirm_publish, and add_branch's clone behavior. The remaining 27 parameters, including filters, paging, and include flags, receive no descriptive help beyond the schema.

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 description identifies the resource as Flow Designer and enumerates specific capabilities: reading/editing action inputs, trigger/branch conditions, cloning branches via add_branch, and publishing. It is reasonably specific and distinctive from siblings like manage_workflow, though 'read/edit' is a generic verb pairing rather than a precise statement of what the tool manages.

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?

Usage is implied by the resource name and the listed operations: if an agent needs to read or edit Flow Designer flows, this is the tool. No explicit alternatives or when-not-to-use guidance is given, though the publish confirmation caveat provides some task-specific direction.

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