Skip to main content
Glama
orchestra-hq

Orchestra MCP Server

Official
by orchestra-hq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Diagnose Task Run

diagnose
Read-only

Investigate a failed task run by retrieving its status, messages, parameters, upstream dependencies, log tail, and artifact filenames for troubleshooting. Runs are queryable for 7 days.

Instructions

Deep dive on one failed task run: its status and messages, taskParameters and runParameters, the statuses of the upstream tasks it depends on, the tail of its newest log, and its artifact filenames. Task runs are queryable for 7 days only. Over-long parameter values, the log tail and the artifact list are capped, and the response says which parts were cut. Use download_task_run_log or download_task_run_artifact when the tail is not enough.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
account_idNoAct 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.
task_run_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.1
    • 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."
+}
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, it discloses a retention limit (7 days), truncation caps on parameter values, log tail and artifact list, and — importantly — that the response self-reports which parts were cut. That is a strong, agent-relevant behavioral disclosure that annotations do not provide.

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?

Front-loaded with purpose, then payload contents, then retention/truncation caveats, then a fallback pointer. Every clause carries information; no filler.

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 an output schema present the description needn't enumerate return structure, yet it still summarizes what comes back, notes retention limits, truncation behavior, and alternative tools. Nothing an agent needs to call or interpret this correctly is missing.

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?

Two parameters at 50% schema coverage. account_id is fully documented in the schema (including API-key vs OAuth scoping), and task_run_id is self-evident from its name, but the description adds nothing about either parameter. Baseline 3 for schema-heavy coverage is appropriate.

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 and resource ('Deep dive on one failed task run') and then enumerates the exact payload — status/messages, taskParameters, runParameters, upstream task statuses, log tail, artifact filenames. This clearly separates it from list_task_runs and get_pipeline_run_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes to the alternatives ('Use download_task_run_log or download_task_run_artifact when the tail is not enough') and states the eligibility window ('queryable for 7 days only'). When-to-use and when-not-to-use are both present.

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