Orchestra MCP Server

Official

by orchestra-hq

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Validate Pipeline

validate_pipeline

Read-only

Validate a full pipeline definition document without creating or updating a pipeline. Use it to check a definition before create_pipeline or update_pipeline.

Instructions

Validate a full pipeline definition document without creating or updating a pipeline. Use it to check a definition before create_pipeline or update_pipeline.

Input Schema

TableJSON Schema

Name	Required	Description
`account_id`	No	Act on this account rather than the one the credential resolves to. Omit it to use the credential's own account. An API key is issued to a single account, so it may only name that account; an OAuth token may name any account its grant covers.
`canonicalize`	No	When true, a valid response also includes the pipeline serialised in Orchestra's canonical camelCase form under a 'pipeline' key.
`pipeline_definition`	Yes	Full pipeline definition document as JSON, matching the pipeline YAML structure, e.g. {"version": "v1", "name": "...", "pipeline": {...task groups...}}. Pass the whole document — version, name and pipeline are required top-level keys; the task groups go under the nested 'pipeline' key. Same document create_pipeline accepts.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.1.2Oct 2, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / account_id

Added value: +{
+  "anyOf": [
+    {
+      "format": "uuid4",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Act on this account rather than the one the credential resolves to. Omit it to use the credential's own account. An API key is issued to a single account, so it may only name that account; an OAuth token may name any account its grant covers."
+}

addedInput schema / properties / pipeline_definition / additionalProperties
```
Added value: +true
```
removedInput schema / properties / pipeline_definition / title
```
Removed value: -"Pipeline Definition"
```
addedInput schema / properties / pipeline_definition / type
```
Added value: +"object"
```

First observedv0.1.0Sep 26, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description reinforces this by stating no pipeline is created or updated, giving the agent confidence there are no side effects. It does not add further behavioral detail (e.g., error reporting shape or rate limits), but the side-effect disclosure is the key trait for a validation call.

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?

Two sentences, zero filler, with the non-mutating scope front-loaded before the routing advice. Every clause earns its place.

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?

With a rich input schema, an output schema, and a readOnly annotation, the description supplies what remains: the tool's non-persisting nature and its place relative to create/update. It is essentially complete, though it could note that validation returns diagnostics rather than a persisted object.

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters (account_id, canonicalize, pipeline_definition) are already documented in the schema, including the canonicalization behavior and account-resolution rules. The description adds no per-parameter meaning beyond what the schema provides, so the baseline of 3 applies.

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?

States a specific verb (validate) and resource (full pipeline definition document) and immediately scopes it as non-persisting: 'without creating or updating a pipeline.' This cleanly distinguishes it from the sibling write tools create_pipeline and update_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?

Explicitly states when to use it: 'to check a definition before create_pipeline or update_pipeline,' naming both alternatives by name. It lacks an explicit when-not condition (e.g., 'do not use to persist changes'), but the routing guidance is clear and actionable.

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

Deploy Server