Extend MCP

Get (or wait on) a parse run

get_parse_run

Read-onlyIdempotent

Get the state and output of a parse run (parse group) — resume a status: "running" run or inspect a failed one. wait: true blocks until terminal or wait-budget expiry. Supports pageRange/maxChars/rawBlocks output slicing as in parse_document. 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. truncated: true means the markdown was cut at maxChars — re-call with pageRange for the pages you need, or rawBlocks: true for block-level output. pageRange/maxChars/rawBlocks are not remembered between calls; pass them again when resuming with get_parse_run. Output shape is documented at https://docs.extend.ai/parsing/response-format.md (get_documentation).

Input Schema

TableJSON Schema

Name	Required	Description
`wait`	No	Block until terminal or budget expiry. Default false.
`runId`	Yes	The run ID returned by parse_document or list_parse_runs.
`maxChars`	No	Truncation cap for returned text (default 50000).
`pageRange`	No	Return only these pages of the output.
`rawBlocks`	No	Return block-level chunks instead of concatenated markdown.
`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
`file`	No
`runId`	Yes
`chunks`	No	Block-level output (rawBlocks: true).
`status`	Yes	Terminal status, or "running" (resume via the get tool).
`runType`	No
`markdown`	No	Concatenated page-delimited markdown (default output).
`pageCount`	No
`truncated`	No	true when markdown was cut at maxChars; re-call with pageRange or rawBlocks for the rest.
`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 / truncated / description

Added value: +"true when markdown was cut at maxChars; re-call with pageRange or rawBlocks for the rest."

First observedSep 3, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already mark this as read-only and idempotent; the description adds substantial behavioral context: wait semantics, budget expiry, the need to reuse the same workspaceId/environment when polling, error recovery, and the non-persistence of pageRange/maxChars/rawBlocks between calls. No contradiction with annotations.

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 dense but every sentence earns its place: it covers purpose, wait behavior, error handling, output slicing, state behavior, and a doc link. The most important operational guidance is front-loaded, and there is 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?

Given the complexity (8 parameters, nested objects, output schema, many siblings), the description is complete: it explains how to poll, what to do on errors, how to handle truncation, that slicing state is not remembered, and where to find the output shape. Nothing an agent needs to invoke it correctly is missing.

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?

Although schema coverage is 100%, the description adds meaning beyond the schema: it clarifies what wait: true does, that waitSeconds is clamped, that slicing parameters must be re-passed when resuming, and how pageRange/rawBlocks address truncated output. This is valuable operational semantics, not schema repetition.

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 specific action: 'Get the state and output of a parse run (parse group)' and clearly differentiates the use cases: resuming a running run or inspecting a failed one. It is specific to get_parse_run and not confused with batch or list operations.

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?

The description gives explicit behavioral instructions: call again with wait: true until terminal, never re-submit the document, re-call get_me on UNAUTHORIZED/NOT_FOUND, and pass slicing parameters again because they are not remembered. It also explains the truncated output case with a concrete recovery path.

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?