Skip to main content
Glama
sonisoft-cnanda

now-sdk-ext-mcp

Test Flow (Flow Designer)

test_flow

Test a ServiceNow Flow Designer flow in its draft state without publishing. Provide the flow ID and trigger output values to run the test and get a context ID for monitoring.

Instructions

Test a ServiceNow Flow Designer flow without requiring it to be published. This is the PRIMARY tool to use when building and iterating on a flow — it invokes the same API as the 'Test' button in Flow Designer, running the flow in its current saved (draft) state.

Unlike execute_flow (which requires a published flow and uses sn_fd.FlowAPI), test_flow works on unpublished drafts via the ProcessFlow REST API (POST /api/now/processflow/flow/{id}/test).

Provide the flow's sys_id or scoped name in flow_id, and supply trigger output variable values in output_map. For record-triggered flows this is typically { "current": "<record_sys_id>", "table_name": "" }. Check the flow's trigger configuration in Flow Designer to determine the correct variable names.

The tool returns a context ID on success — use get_flow_context_status to poll the execution, then get_flow_outputs or get_flow_error once complete.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
instanceNoThe ServiceNow instance auth alias to use. This is the alias configured via `now-sdk auth --add` (e.g., "myinstance", "prod", "test"). The user will typically refer to this by name when saying things like "on my myinstance instance". If not provided, falls back to the SN_AUTH_ALIAS environment variable.
flow_idYesFlow sys_id (32-char hex) or scoped name (e.g., "x_myapp.my_flow"). The flow does not need to be published.
output_mapYesMaps trigger output variable names to concrete test values. Keys are the variable names defined in the flow's trigger configuration in Flow Designer. For record-triggered flows: { "current": "<record_sys_id>", "table_name": "<table>" }. Open the flow in Flow Designer and inspect the trigger to see the available variable names.
scopeNoScope sys_id for the transaction scope query parameter. If omitted, the scope is auto-resolved from the flow definition.
run_on_threadNoWhether to run the test synchronously on the current thread. Default: true.
Behavior5/5

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

With no annotations provided, the description fully covers behavioral traits: works on unpublished drafts via ProcessFlow REST API, returns a context ID, runs synchronously by default (run_on_thread), and requires non-published state. Discloses API endpoint and draft limitation.

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?

Single paragraph with front-loaded purpose, then key differentiator, then parameter guidance. Every sentence adds value; no fluff. Could be slightly shortened but overall efficient for the amount of context provided.

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

Completeness5/5

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

Given 5 parameters, 2 required, no output schema, the description fully equips an agent: explains what the tool does, how to invoke it (flow_id, output_map example), synchronous behavior, and what to expect (context ID) with pointers to next steps. Enough for correct invocation and result handling.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. Description adds value beyond schema: explains output_map as mapping trigger variable names with concrete record-triggered example, clarifies run_on_thread default (true), and mentions auto-resolution for scope. Does not redundantly repeat schema descriptions.

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?

Description clearly states it tests a ServiceNow Flow Designer flow without publication, distinguishing it from execute_flow which requires published flows. The verb 'test' and resource 'flow' are specific, and the sibling differentiation is explicit.

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?

Described as the primary tool for building/iterating flows, with explicit contrast to execute_flow. Provides a usage example (output_map structure) and suggests follow-up tools (get_flow_context_status, get_flow_outputs, get_flow_error). Lacks explicit when-not-to-use scenarios but strong context is given.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sonisoft-cnanda/now-sdk-ext-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server