Extend MCP

Get (or wait on) a workflow run

get_workflow_run

Read-onlyIdempotent

Get the state and output of a workflow run (workflows group) — resume a status: "running" run or inspect a failed one. wait: true blocks until terminal or wait-budget expiry. Workflow runs commonly take minutes to hours — repeated running responses are normal. While status is "running", call again with wait: true (same workspaceId and environment) until it is terminal; never re-submit the document. On UNAUTHORIZED or NOT_FOUND, re-call get_me for the granted targets. Statuses: PROCESSED; FAILED (retryable: true means the failureReason is usually transient and one retry is reasonable); NEEDS_REVIEW (paused for a human reviewer in the dashboard — share dashboardUrl with the user and re-check the run after they finish; do not retry or re-submit); REJECTED (a reviewer rejected the run in the dashboard — final; dashboardUrl has their reasoning); CANCELLED.

Input Schema

TableJSON Schema

Name	Required	Description
`wait`	No	Block until terminal or budget expiry. Default false.
`runId`	Yes	The run ID returned by run_workflow or list_workflow_runs.
`detail`	No	"concise" (default): status, output, failure fields, dashboardUrl. "full": adds config, confidence/citations, usage, timestamps.
`environment`	Yes	"TEST" = the Test (development) environment, "PRODUCTION" = live. Must match a granted target from get_me (an API key pins one environment).
`waitSeconds`	No	Max seconds to block waiting on the run (clamped to the server wait budget).
`workspaceId`	Yes	Target workspace (ws_...). Must be a granted workspace — get_me lists the accepted values.

Output Schema

TableJSON Schema

Name	Required	Description
`files`	No
`runId`	Yes
`status`	Yes	PROCESSED \| FAILED \| NEEDS_REVIEW \| REJECTED \| CANCELLED, or "running" (resume via the get tool).
`outputs`	No	Per-step output values from completed steps.
`runType`	No
`retryable`	No	Present on FAILED runs: true when the failureReason is usually transient and one retry is reasonable.
`stepSummary`	No
`dashboardUrl`	No
`failureReason`	No
`failureMessage`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 20, 2026

removedOutput schema / properties / llmContext
```
Removed value: -{
-  "type": "string"
-}
```

addedOutput schema / properties / retryable

Added value: +{
+  "description": "Present on FAILED runs: true when the failureReason is usually transient and one retry is reasonable.",
+  "type": "boolean"
+}

First observedSep 3, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, the description discloses wait-blocking behavior, expected run durations, repeated 'running' responses as normal, error recovery via get_me, and status-specific responses including retryability and reviewer involvement. This is substantially richer than what annotations alone convey.

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?

The description is front-loaded with the core purpose and wait behavior, then efficiently handles polling, errors, and statuses. Despite its length, every clause earns its place—there is no filler and the status list is condensed but necessary for correct agent behavior.

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?

The description covers the full run lifecycle, wait semantics, error handling, status meanings, and expected agent actions. Since an output schema exists, omitting return-value details is acceptable, and nothing an agent needs to call this tool correctly is missing.

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 params are already documented. The description adds useful semantics for wait:true blocking until terminal or budget expiry, the need to reuse the same workspaceId and environment during polling, and how statuses drive retry decisions. It earns above the baseline because it connects parameter behavior to the run lifecycle.

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 description states a clear verb and resource: 'Get the state and output of a workflow run' and scopes it to the 'workflows group', distinguishing it from sibling run-retrieval tools like get_extract_run or get_parse_run. It also adds lifecycle purpose—resume a running run or inspect a failed one—so an agent knows exactly what this tool is for.

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?

It gives a detailed polling protocol: call again with wait:true until terminal, do not re-submit, re-check after NEEDS_REVIEW, and do not retry REJECTED runs. It does not explicitly contrast this tool with sibling retrieval or cancellation tools, but the behavioral guidance is strong enough that an agent knows when and how to use it.

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

All Extend MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?