Skip to main content
Glama
Sign In
UpstageAI

mcp-upstage

Official
by UpstageAI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

parse_document

Extracts structured content and layout from PDFs, images, and Office files, using quality modes for complex tables, charts, handwriting, or low-quality scans.

Instructions

Parse a document using Upstage AI's document digitization API.

This tool extracts the structure and content from various document types,
including PDFs, images, and Office files. It preserves the original formatting
and layout while converting the document into a structured format.

Use mode='enhanced' for documents with complex tables, charts, handwriting or
low-quality scans (higher cost, slower), or mode='auto' to let the API decide
per page. The response ends with the model and per-mode page usage reported
by the API, plus a WARNING line if the requested mode was not applied.

Supported file formats include: PDF, JPEG, PNG, TIFF, and other common document formats.

Input Schema

NameRequiredDescriptionDefault
ocrNoOCR mode. 'force' (default): always run OCR. 'auto': use the embedded text of digital documents and run OCR only when needed.force
modeNoParsing mode. 'standard' (default): fast and cheapest, good for ordinary text-centric documents. 'enhanced': use for complex tables, charts, handwriting or low-quality scans; it costs more per page and is slower. 'auto': let the API decide per page whether enhanced processing is needed.standard
modelNoDocument Parse model name. Use the default 'document-parse' for the latest version, or a dated version such as 'document-parse-260930' to pin it.document-parse
file_pathYesPath to the document file to be processed
output_formatsNoOutput formats (e.g., 'html', 'text', 'markdown')

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.2.0
    • addedInput schema / properties / mode
      Added value: +{
+  "default": "standard",
+  "description": "Parsing mode. 'standard' (default): fast and cheapest, good for ordinary text-centric documents. 'enhanced': use for complex tables, charts, handwriting or low-quality scans; it costs more per page and is slower. 'auto': let the API decide per page whether enhanced processing is needed.",
+  "enum": [
+    "standard",
+    "enhanced",
+    "auto"
+  ],
+  "title": "Mode",
+  "type": "string"
+}
    • addedInput schema / properties / model
      Added value: +{
+  "default": "document-parse",
+  "description": "Document Parse model name. Use the default 'document-parse' for the latest version, or a dated version such as 'document-parse-260930' to pin it.",
+  "title": "Model",
+  "type": "string"
+}
    • addedInput schema / properties / ocr
      Added value: +{
+  "default": "force",
+  "description": "OCR mode. 'force' (default): always run OCR. 'auto': use the embedded text of digital documents and run OCR only when needed.",
+  "enum": [
+    "auto",
+    "force"
+  ],
+  "title": "Ocr",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose real behavior: enhanced mode costs more and is slower, auto decides per page, and the response ends with model/per-mode page usage plus a WARNING line when the requested mode was not applied. It omits auth/API-key requirements, file-size limits, and pagination/truncation behavior for large documents.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and then mode guidance, with no filler sentences. Minor redundancy: file types are listed twice ('PDFs, images, and Office files' then again 'PDF, JPEG, PNG, TIFF, and other common document formats'), and the second list is vaguer than the first.

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 5-parameter, unannotated, no-output-schema tool, the definition covers cost/latency tradeoffs and hints at the response tail but never explains the main return payload (structured output shape, which output_formats are produced by default) or prerequisites like credentials. Adequate but with clear gaps.

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 100%, so the schema already documents ocr, mode, model, output_formats and file_path. The description's mode guidance duplicates the enum description and it says nothing about ocr, model pinning, or output_formats choices; baseline 3 applies.

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?

States a specific verb (parse) and resource (document) plus the underlying API, and names the file types handled. However, it never distinguishes itself from the sibling extract_information, which an agent could reasonably confuse with 'extracts the structure and content'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives conditional advice for mode='enhanced' vs 'auto', but that guidance merely restates the schema enum descriptions rather than the schema's own text adding new routing logic. There is no guidance on when to choose parse_document over extract_information, or when not to use it (e.g., already-digital text files, unsupported sizes).

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