Skip to main content
Glama

debug_pipeline

Set breakpoints, resume snapshots, or trace full runs to debug pipeline configurations. Dry-run enables side-effect-free testing.

Instructions

Runs a pipeline configuration in debug mode: pin a breakpoint, resume a snapshot, or trace a full run.

Debugs a pipeline configuration directly (not a saved pipeline by name) -- pass the YAML you want to test, e.g. from get_pipeline_version, create_pipeline_version, or a local draft. The inline run trace is always returned, so a failure is visible even for a run that never reaches a breakpoint.

One call carries at most one of:

  • break_at_component_name (with break_at_visit_count) -- run from inputs until the breakpoint is hit, then stop and return a resumable snapshot in the 'snapshot' field. Pass that back as resume_from to continue the run.

  • resume_from -- replay a snapshot returned by a previous debug run to completion; inputs are ignored, they come from the snapshot.

  • neither -- run the pipeline from inputs to completion as a plain debug run. :param yaml_configuration: The pipeline YAML configuration to debug. :param inputs: Named pipeline inputs keyed by the input name declared under the pipeline config's 'inputs' mapping (e.g. {"query": "What is love?"}). Ignored when resume_from is set. :param break_at_component_name: Name of the component to break at. Mutually exclusive with resume_from; omit both to run to completion as a plain debug run. :param break_at_visit_count: Break when the target has been visited this many times (0 breaks before the first visit; relevant for loops/cycles). Only used if break_at_component_name is set. :param resume_from: A snapshot returned by a previous debug run (its 'snapshot' field), replayed to completion. Mutually exclusive with break_at_component_name. :param files: File IDs to download and inject into the inputs declared under the pipeline config's 'inputs.files' mapping. :param pipeline_id: Optional ID of the pipeline this debug run is associated with. :param pipeline_version_id: Optional ID of the pipeline version to associate the run with (requires pipeline_id). :param dry_run: Best-effort stateless run: state-modifying components (e.g. DocumentWriter) are replaced with no-op equivalents so the pipeline can be inspected without side effects. Required for indexing pipelines (their document store carries no index until deploy time); harmless for query pipelines. Set it on resume too if the original run used dry_run, otherwise the run is rejected.

:returns: PipelineDebugResult with status, result/snapshot, and the run trace, or an error message.

All parameters accept object references in the form @obj_id or @obj_id.path.to.value.

Examples::

# Direct call with values
debug_pipeline(data={'key': 'value'}, threshold=10)

# Call with references
debug_pipeline(data='@obj_123', threshold='@obj_456.config.threshold')

# Mixed call
debug_pipeline(data='@obj_123.items', threshold=10)The output is automatically stored and can be referenced in other functions.

Returns a formatted preview with an object ID (e.g., @obj_123). Use the object store tools in combination with the object ID to view nested properties of the object. Use the returned object ID to pass this result to other functions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesNo
inputsNo
dry_runNo
pipeline_idNo
resume_fromNo
yaml_configurationYes
pipeline_version_idNo
break_at_visit_countNo
break_at_component_nameNo
Behavior5/5

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

With no annotations, the description fully carries behavioral disclosure: it explains resumable snapshot behavior, the always-returned inline run trace, state-modifying dry_run substitutions, and the resume rejection on dry_run mismatch. It also notes that outputs are auto-stored and can be referenced via object IDs.

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?

Although long, the description is well structured: a clear overview, mode breakdown, parameter definitions, and examples. Each section adds essential operational detail, and the first sentence front-loads the core purpose.

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?

For a tool with 9 parameters, no annotations, and no output schema, the description is remarkably complete. It covers return shape, side effects, dry_run behavior, error visibility, object-reference usage, and example calls, leaving almost no operational ambiguity.

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?

The input schema has zero descriptions, but the description documents all 9 parameters, including mutual exclusions, defaults (break_at_visit_count=0), ignored inputs when resume_from is set, and the requirement that pipeline_version_id requires pipeline_id. This fully compensates for the schema coverage gap.

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?

The first sentence states a specific action and scope: 'Runs a pipeline configuration in debug mode: pin a breakpoint, resume a snapshot, or trace a full run.' It also explicitly distinguishes from saved pipelines ('directly (not a saved pipeline by name)'), which separates it from siblings like run_component or deploy_pipeline.

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?

The description defines three mutually exclusive usage modes and tells users to pass YAML from get_pipeline_version/create_pipeline_version or a local draft. It provides concrete when-to-use guidance for dry_run ('Required for indexing pipelines... harmless for query pipelines') and warns to set it on resume too. However, it does not explicitly name alternative tools, so it stops short of full explicit exclusion guidance.

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/deepset-ai/deepset-mcp-server'

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