Extend MCP

Split a multi-document file into segments

split_document

Divide a combined file, e.g. a scanned bundle of invoices or a merged PDF of statements, into typed segments with page ranges (split group), using a saved splitter or inline split classifications. Also the right FIRST step to locate one document or section inside a larger bundle — split, then parse/extract only the relevant segment instead of processing the whole file. Provide exactly one of splitter or config; inline config.splitClassifications needs a type: "other" entry. Each split includes startPage/endPage and, when Extend materializes child files, a fileId usable directly in other tools. Raw text input is not supported — splitting is page-based. Async: a status: "running" result with a runId is not an error — resume with get_split_run passing that runId, the same workspaceId and environment, and wait: true, repeating until the status is terminal; never re-submit the document. On UNAUTHORIZED or NOT_FOUND, re-call get_me for the granted targets. Output shape is documented at https://docs.extend.ai/splitting/response-format.md (get_documentation).

Input Schema

TableJSON Schema

Name	Required	Description
`file`	Yes	The bundle to split. Exactly one of id/url — e.g. { "url": "https://..." } or { "id": "file_..." }, never a bare string.
`config`	No	Inline split config: { splitClassifications: [{ id, type, description, identifierKey? }], splitRules?, advancedOptions?, parseConfig? }. Must include a type: "other" entry; ids must be unique. identifierKey names a per-segment value the splitter reads off each segment (e.g. an invoice number), surfaced as identifier on each returned split. Before authoring a config by hand, call get_documentation with https://docs.extend.ai/splitting/configuration.md and follow it.
`detail`	No	"concise" (default): status, output, failure fields, dashboardUrl. "full": adds config, confidence/citations, usage, timestamps.
`metadata`	No	Arbitrary key-value metadata stored on the run.
`priority`	No	Queue priority (1-100).
`splitter`	No	Saved splitter to run. Provide exactly one of splitter or config.
`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
`output`	No	Typed segments with page ranges (PROCESSED only).
`status`	Yes	Terminal status, or "running" (resume via the get tool).
`runType`	No
`dashboardUrl`	No
`failureReason`	No
`failureMessage`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 20, 2026
- removedOutput schema / properties / llmContext
```
Removed value: -{
-  "type": "string"
-}
```
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 async behavior ('status: "running" result with a runId is not an error'), the recovery pattern via get_split_run, the instruction to never re-submit the document, and the UNAUTHORIZED/NOT_FOUND handling via get_me. It also notes that materialized child files yield a fileId usable elsewhere. 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 contributes: purpose, alternatives, constraints, async behavior, and error handling. It is front-loaded with the core action and use case before moving to operational details. No filler or repeated schema information.

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 9-parameter, nested, async tool, the description covers invocation mode selection, config requirements, page-based limitations, async run lifecycle, error recovery, and points to external documentation for the output shape. Nothing essential for an agent 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.

Parameters3/5

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

Schema description coverage is 100%, and the schema already documents splitter/config structure, file id/url exclusivity, environment, and waitSeconds. The main description reinforces the exactly-one-of-splitter-or-config rule and the required type: 'other' entry, but adds little new parameter-level meaning. Baseline 3 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?

The description states a specific action and resource: 'Divide a combined file ... into typed segments with page ranges', with concrete examples (scanned bundle of invoices, merged PDF of statements). It also names the two invocation modes (saved splitter or inline config), which differentiates it from downstream parse/extract tools.

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 explicitly says split_document is the 'right FIRST step' for locating one document in a larger bundle, and advises splitting then parsing/extracting only the relevant segment rather than processing the whole file. It also gives hard constraints: provide exactly one splitter or config, raw text is unsupported, and async runs must be resumed rather than re-submitted.

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?