Skip to main content
Glama
Sign In
now-sdk-ext-mcp

now-sdk-ext-mcp

by sonisoft-cnanda
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Debug Flow To Breakpoint

debug_flow_run_to
Destructive

Run a flow or subflow to its first breakpoint in one call, reporting each step's inputs and outputs at the stop, then canceling by default so no run is left open.

Instructions

Debug a flow or subflow to a breakpoint in one call: start it, run to the first of the breakpoints, report every step's inputs and outputs there, then (by default) cancel it so nothing is left open. after resume lets it run on to the end, ignoring the other breakpoints; after stay leaves it paused for debug_flow_step. The run is real: records it creates or changes are kept. Only when the user asked to debug.

Input Schema

NameRequiredDescriptionDefault
flowYesThe flow or subflow: its sys_hub_flow sys_id, or scope.internal_name (e.g. x_app.create_task_copy).
fullNoShow values in full, and the engine's internal outputs (__action_status__ and the like).
afterNoAfter the breakpoint: cancel (default), resume to the end, or stay paused.
inputsNoInputs by name. For a subflow, its declared inputs (checked before anything runs; an array for an array input is sent as Workflow Studio sends it). For a flow, its trigger outputs (e.g. current, table_name).
instanceNoThe ServiceNow instance auth alias to connect to. This is the alias configured via `snc configure` (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.
breakpointsYesSteps to break at, by the number Workflow Studio shows. The run stops at the first one reached.
timeout_secondsNoSeconds for the whole call, split across its waits (start, the breakpoint, and with resume the end). Default 30, so a cancel's settling still fits under a 60-second client timeout. A client that gives up first leaves the run open: find it with list_flow_debug_sessions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv5.5.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds the crucial fact behind that flag: 'The run is real: records it creates or changes are kept.' It also discloses the default cleanup (cancel leaves nothing open) and the failure mode where a client timeout leaves a run open, pointing to list_flow_debug_sessions for recovery.

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 outcome in the first clause, then the mode semantics, then the side-effect warning. Dense and efficient, though the parenthetical asides ('by default', the long timeout caveat) make it slightly heavier than necessary.

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?

With no output schema, the description carries the return-value burden and does so ('report every step's inputs and outputs there'). For a 7-parameter, destructive, open-world debug tool it covers outcome, statefulness, persistence of side effects, and recovery from an abandoned run.

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, but the description adds real meaning beyond the schema: it explains that resume runs past the remaining breakpoints and stay pauses for debug_flow_step, and that a breakpoint list stops at the first one reached. The timeout note clarifies how seconds are split across waits, though it largely restates the schema's own timeout text.

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?

Names a specific verb and resource ('debug a flow or subflow to a breakpoint in one call') and immediately enumerates the sequence: start, run to first breakpoint, report each step's inputs/outputs, then cancel by default. It also differentiates itself from siblings by naming debug_flow_step as the tool that continues from a 'stay' state.

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?

Gives an explicit eligibility condition ('Only when the user asked to debug') and explains the three after-modes as selection criteria (resume ignores other breakpoints; stay hands off to debug_flow_step). It stops short of contrasting with debug_flow_start or debug_flow_breakpoints by name, so a little inference remains.

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