Skip to main content
Glama
NoEdgeAI

Doc2x MCP Server

by NoEdgeAI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

doc2x_convert_export_submit

Start an export (convert) job for a parsed PDF uid. After this, poll with doc2x_convert_export_wait or doc2x_convert_export_result. Do NOT call doc2x_convert_export_submit twice for the same uid+format in parallel.

Instructions

Start an export (convert) job for a parsed PDF uid. After this, poll with doc2x_convert_export_wait or doc2x_convert_export_result. Do NOT call doc2x_convert_export_submit twice for the same uid+format in parallel.

Input Schema

NameRequiredDescriptionDefault
toYes
uidYesDoc2x parse task uid returned by doc2x_parse_pdf_submit.
filenameNoOptional output filename (for md/tex only). Tip: pass a basename WITHOUT extension to avoid getting 'name.md.md' / 'name.tex.tex'.
formula_modeYes
filename_modeNoHow to treat filename. 'auto' strips the target extension and shortens names exceeding 50 Unicode characters with a stable hash suffix; 'raw' preserves the basename and rejects names over 50 characters before submission.
formula_levelNoOptional formula degradation level. Effective only when source parse uses model=v3-2026 (ignored by v2). 0: keep formulas, 1: degrade inline formulas, 2: degrade inline and block formulas.
merge_cross_page_formsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.7
    • addedInput schema / properties / filename / minLength
      Added value: +1
    • changedInput schema / properties / filename_mode / description
      Previous value: -"How to treat filename. 'auto' strips common extensions for the target format; 'raw' passes basename as-is."New value: +"How to treat filename. 'auto' strips the target extension and shortens names exceeding 50 Unicode characters with a stable hash suffix; 'raw' preserves the basename and rejects names over 50 characters before submission."
    • addedInput schema / properties / formula_level
      Added value: +{
+  "anyOf": [
+    {
+      "const": 0,
+      "type": "number"
+    },
+    {
+      "const": 1,
+      "type": "number"
+    },
+    {
+      "const": 2,
+      "type": "number"
+    }
+  ],
+  "description": "Optional formula degradation level. Effective only when source parse uses model=v3-2026 (ignored by v2). 0: keep formulas, 1: degrade inline formulas, 2: degrade inline and block formulas."
+}
  2. First observedv0.1.2

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses that this is an async job requiring polling and that parallel duplicate submissions for the same uid+format are forbidden, but says nothing about the immediate return value (task id?), whether resubmission after completion is allowed, or any cost or rate limit.

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?

Three sentences totalling roughly 30 words. The action and the follow-up polling step come first, and the concurrency warning comes last. Nothing is padded, and the next-step information is front-loaded.

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 a job-submission tool with 7 parameters, no annotations, and no output schema, the description adequately covers the workflow and the concurrency hazard. It is not complete enough to prevent wrong calls, because required-enum semantics and the return contract remain undocumented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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

Schema coverage is 57%, and the gaps matter: required 'to' and 'formula_mode' (a required enum with values normal/dollar) and optional 'merge_cross_page_forms' have no descriptions anywhere. The description mentions only 'uid+format' and adds no meaning, such as how output formats differ or what formula_mode does.

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 names a specific verb ('Start') and resource ('an export (convert) job for a parsed PDF uid'), and it names the polling siblings, so the agent can tell it apart from doc2x_convert_export_wait and doc2x_convert_export_result. The async workflow is clear from the first sentence.

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 explicitly routes the agent to doc2x_convert_export_wait or doc2x_convert_export_result after submitting, and adds a concrete negative rule ('Do NOT call ... twice for the same uid+format in parallel'). The remaining gap is that it doesn't state the precondition that the parse must be finished, or how to retry after a failure.

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