FlexOrch MCP

Reprocess Document

document.reprocess

Re-queue an already-uploaded document through the pipeline.

Use this to re-run extraction/PII detection/quality scoring on a document you've
already processed — e.g. after a document_type_hint change, without downloading and
re-uploading the original file. Returns immediately with a job_id — poll with
job.status the same way as after document.process.

Only works for documents whose original file is still stored on the server (locally
uploaded, not connector-sourced). If the file is no longer available, re-upload it
with document.process instead.

Args:
    document_id: ID of a previously processed document.
    pipeline_config: Optional pipeline config overrides, e.g. {"document_type_hint": "invoice"}.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`document_id`	Yes
`pipeline_config`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No
`job_id`	No
`status`	No
`isError`	No
`poll_hint`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 3, 2026

TDQS

A5/5.0

Behavior5/5

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

Discloses the asynchronous behavior (returns immediately with a job_id), the polling mechanism, and the storage-dependent failure mode. These behavioral details go well beyond the sparse annotations and give the agent accurate expectations about side effects and follow-up calls.

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 action, then covers usage scenario, constraints, fallback, and return behavior in a tight sequence. The Args list is minimal and each sentence adds essential 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 tool with a simple two-parameter schema but async behavior and preconditions, the description covers invocation, response pattern, limitations, and alternative routing. The output schema exists, so not detailing the return payload is acceptable.

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?

Schema description coverage is 0%, so the description carries all parameter meaning. It clarifies document_id as a previously processed document ID and explains pipeline_config as optional overrides with a concrete JSON example, fully compensating for the bare schema.

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 opens with a specific verb+resource ('Re-queue an already-uploaded document through the pipeline') and clearly scopes the action to reprocessing existing documents. It also distinguishes itself from document.process by positioning reprocess as the follow-up for already-processed documents.

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?

Provides explicit when-to-use context (after a document_type_hint change, avoiding download/re-upload), a hard precondition (original file must still be stored; connector-sourced docs excluded), and a named alternative fallback (re-upload with document.process). Also tells the agent to poll with job.status after the immediate job_id return.

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

All FlexOrch MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

Each tool maps cleanly to a distinct pipeline stage or resource: document submission, reprocessing, job polling, result retrieval, dataset build, export, index, search, and chunk retrieval. Even the similar document.process and document.reprocess are clearly separated by whether a new file is involved or an existing stored document is re-queued.

Naming Consistency4/5

Most tools follow a consistent noun.action dot-namespace pattern like document.process, dataset.build, and job.status. dataset.chunks and job.result deviate by using nouns rather than action verbs, and one description references get_job_status/build_dataset instead of the actual tool names, creating minor inconsistency.

Tool Count5/5

Nine tools is well within the ideal range and each tool earns its place in the document processing and dataset export lifecycle. There are no redundant or filler tools, and the count matches the complexity of the workflow.

Completeness5/5

The full documented pipeline is covered: submit, poll, read results, build dataset, export, index, search, and retrieve chunks, with reprocessing available as an alternative to re-upload. No described workflow step dead-ends, and optional RAG features are supported through dataset.index and dataset.chunks.

Resources

Need Help?