Skip to main content
Glama
NoEdgeAI

Doc2x MCP Server

by NoEdgeAI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

doc2x_parse_pdf_wait_text

Wait for a PDF parse task until success and return merged text. Prefer passing uid (no re-submit). If only pdf_path is provided, it will (a) reuse an in-process cached uid if available, otherwise (b) submit a new task then wait.

Instructions

Wait for a PDF parse task until success and return merged text. Prefer passing uid (no re-submit). If only pdf_path is provided, it will (a) reuse an in-process cached uid if available, otherwise (b) submit a new task then wait.

Input Schema

NameRequiredDescriptionDefault
uidNoDoc2x parse task uid returned by doc2x_parse_pdf_submit.
modelNoOptional parse model used only when submitting from pdf_path. Supported values: 'v2' and 'v3-2026'. Omit this field to use default v2.
pdf_pathNoAbsolute path to a local PDF file. If uid is not provided, this tool will reuse cached uid (if any) or submit a new task.
join_withNo
max_wait_msNo
max_output_charsNoMax characters of returned text (0 = unlimited). Useful to avoid LLM context overflow. Default can be set via env DOC2X_PARSE_PDF_MAX_OUTPUT_CHARS.
max_output_pagesNoMax pages to merge into returned text (0 = unlimited). Default can be set via env DOC2X_PARSE_PDF_MAX_OUTPUT_PAGES.
poll_interval_msNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.7
    • addedInput schema / properties / model
      Added value: +{
+  "description": "Optional parse model used only when submitting from pdf_path. Supported values: 'v2' and 'v3-2026'. Omit this field to use default v2.",
+  "enum": [
+    "v2",
+    "v3-2026"
+  ],
+  "type": "string"
+}
  2. First observedv0.1.2

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description usefully discloses that it may submit a new task when only pdf_path is provided and that it may reuse an in-process cached uid. However, it omits important behavior around timeout/failure handling despite the max_wait_ms parameter, and does not describe polling or error outcomes.

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 short, front-loaded, and every sentence contributes needed information. The uid preference and pdf_path fallback are expressed compactly without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an eight-parameter blocking/waiting tool with no annotations and no output schema, the description covers the core purpose and key uid/pdf_path behavior. It is still incomplete regarding timeout/failure behavior, polling, join semantics, and how the returned merged text is structured.

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 coverage is 63%, and the description adds meaningful conditional semantics for uid versus pdf_path, including cache reuse and resubmission behavior. It still says nothing about join_with, max_wait_ms, or poll_interval_ms, so it does not fully compensate for the remaining schema coverage gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (wait for a PDF parse task), the condition (until success), and the result (merged text). It is clearly distinguishable from a submit or status tool, though it does not explicitly name sibling alternatives.

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 clear routing guidance: prefer passing uid to avoid resubmission, and if only pdf_path is given, it will reuse a cached uid or submit a new task before waiting. It does not explicitly compare this tool to doc2x_parse_pdf_status or doc2x_parse_pdf_submit, leaving some alternative-selection guidance implicit.

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