Skip to main content
Glama

Upstage MCP

A Model Context Protocol (MCP) server for Upstage AI's document digitization and information extraction capabilities

Overview

The Upstage MCP Server provides a robust bridge between AI assistants and Upstage AI’s powerful document processing APIs. This server enables AI models—such as Claude—to effortlessly extract and structure content from various document types including PDFs, images, and Office files. The package supports multiple formats and comes with seamless integration options for Claude Desktop.

Related MCP server: MCP-Upstage-Server

Key Features

  • Document Digitization: Extract structured content from documents while preserving layout.

  • Information Extraction: Retrieve specific data points using intelligent, customizable schemas.

  • Multi-format Support: Handles JPEG, PNG, BMP, PDF, TIFF, HEIC, DOCX, PPTX, and XLSX.

  • Claude Desktop Integration: Effortlessly connect with Claude and other MCP clients.

Prerequisites

Before using this server, ensure you have the following:

  1. Upstage API Key: Obtain your API key from Upstage API.

  2. Python 3.10+: The server requires Python version 3.10 or higher.

  3. The MCP server relies upon Astral UV to run, please install

Installation & Configuration

This guide provides step-by-step instructions to set up and configure the mcp-upstage

Using uv (Recommended)

No additional installation is required when using uvx as it handles execution. However, if you prefer to install the package directly:

uv pip install mcp-upstage

Configure Claude Desktop

For integration with Claude Desktop, add the following content to your claude_desktop_config.json:

Configuration Location

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "mcp-upstage": {
      "command": "uvx",
      "args": ["mcp-upstage"],
      "env": {
        "UPSTAGE_API_KEY": "<your-api-key>"
      }
    }
  }
}

If uvx is not available globally, you may encounter a Server disconnected error. To resolve this, run which uvx to find its full path, and replace "command": "uvx" above with the returned path.

After adding the configuration, restart Claude Desktop to apply the changes.

Output Directories

Processing results are stored in your home directory under:

  • Document Parsing Results:
    ~/.mcp-upstage/outputs/document_parsing/

  • Information Extraction Results:
    ~/.mcp-upstage/outputs/information_extraction/

  • Generated Schemas:
    ~/.mcp-upstage/outputs/information_extraction/schemas/

Local/Development Setup

Follow these steps to set up and run the project locally:

Step 1: Clone the Repository

git clone https://github.com/UpstageAI/mcp-upstage.git
cd mcp-upstage

Step 2: Set Up the Python Environment

# Install uv if not already installed
pip install uv

# Create and activate a virtual environment
uv venv

# Activate the virtual environment
# On Windows:
# .venv\Scripts\activate
# On macOS/Linux:
source .venv/bin/activate

# Install dependencies in editable mode
uv pip install -e .

Step 3: Configure Claude Desktop for Local Testing

  1. Download Claude Desktop:
    Download Claude Desktop

  2. Open and Edit Configuration:

    • Navigate to Claude → Settings → Developer → Edit Config.

    • Edit the claude_desktop_config.json file with the following configurations:

    For Windows:

    {
      "mcpServers": {
        "mcp-upstage": {
          "command": "uv",
          "args": [
            "run",
            "--directory",
            "C:\\path\\to\\cloned\\mcp-upstage",
            "python",
            "-m",
            "upstage_mcp.server"
          ],
          "env": {
            "UPSTAGE_API_KEY": "your_api_key_here"
          }
        }
      }
    }

    Replace C:\\path\\to\\cloned\\mcp-upstage with your actual repository path.

    For macOS/Linux:

    {
      "mcpServers": {
        "mcp-upstage": {
          "command": "/Users/username/.local/bin/uv",
          "args": [
            "run",
            "--directory",
            "/path/to/cloned/mcp-upstage",
            "python",
            "-m",
            "upstage_mcp.server"
          ],
          "env": {
            "UPSTAGE_API_KEY": "your_api_key_here"
          }
        }
      }
    }

    Replace:

    • /Users/username/.local/bin/uv with the output of which uv.

    • /path/to/cloned/mcp-upstage with the absolute path to your local clone.

Tip for macOS/Linux users: If connection issues occur, using the full path to your uv executable can improve reliability.

After configuring, restart Claude Desktop.

Available Tools

The server exposes two primary tools for AI models:

  1. Document Parsing (parse_document):

    • Description: Processes documents and extracts content while preserving structure.

    • Parameters:
      file_path – the path to the document to be processed;
      output_formats (optional) – output formats such as html, text, markdown;
      mode (default standard) – standard, enhanced or auto. Use enhanced for complex tables, charts, handwriting or low-quality scans; auto lets the API decide per page;
      ocr (default force) – force always runs OCR, auto uses embedded text of digital documents when possible;
      model (default document-parse) – the latest model, or a dated version such as document-parse-260930 to pin it.

    • Applied mode: The response ends with the model and per-mode page usage reported by the API, e.g. Processed by document-parse-260930 | usage: {"pages": 1, "enhanced": [1]}. If the requested standard/enhanced mode was not applied, a WARNING line follows.

    • Cost note: enhanced (and pages that auto routes to enhanced) is billed at a higher per-page price than standard and is slower. Keep the default standard unless the document needs it.

    • Example Query:
      "Can you parse the document at C:\Users\username\Documents\contract.pdf and provide a summary?"
      "Parse the scanned form at ~/Documents/form.pdf in enhanced mode."

  2. Information Extraction (extract_information):

    • Description: Extracts structured information from documents based on predefined or auto-generated schemas.

    • Parameters:
      file_path – the document file path;
      schema_path (optional) – a JSON file with an extraction schema;
      auto_generate_schema (default true) – whether to auto-generate a schema.

    • Example Query:
      "Extract the invoice number, date, and total from C:\Users\username\Documents\invoice.pdf."

Troubleshooting

Common Issues

  • API Key Missing:
    Ensure that your UPSTAGE_API_KEY is correctly set in your claude_desktop_config.json file. Obtain a valid API key from Upstage Console.

  • File Not Found:
    Double-check the file path for correctness and accessibility. Ensure that file paths are absolute (e.g., C:\Users\name\Documents\file.pdf) and that any special characters in the path are properly escaped.

  • Server Not Starting:
    Verify that your virtual environment is activated and all dependencies are installed. Additionally, review the Claude Desktop log files for errors:

    • Windows: %APPDATA%\Claude\logs\mcp-upstage.log

    • macOS: ~/Library/Logs/Claude/mcp-upstage.log

  • Server Connection Issues:
    Restart Claude Desktop. Ensure that uvx is installed and available in your system PATH, or use its absolute path in your configuration if needed.

  • Processing Failures:
    Check that the document is in a supported format (PDF, JPEG, PNG, TIFF, etc.), its file size is under 50MB, and it contains fewer than 100 pages. Test with a simpler document to confirm functionality.

  • Invalid Document Format:
    Verify that the document is in a supported, uncorrupted format.

  • Failed to Connect to Upstage API:
    Confirm your network connection, firewall settings, and configuration details in claude_desktop_config.json. Review the logs for more detailed error messages.

Log Files

For troubleshooting, view the server logs at:

  • Windows:
    %APPDATA%\Claude\logs\mcp-upstage.log

  • macOS:
    ~/Library/Logs/Claude/mcp-upstage.log

Release / Deployment (Maintainers)

This repository publishes a Python package. MCP clients run it locally over stdio; the workflows do not deploy a hosted HTTP server.

Deployment triggers and credentials

Destination

Trigger

Workflow

GitHub environment

Secret

TestPyPI

Push to dev

Publish to TestPyPI

test-pypi

TEST_PYPI_API_TOKEN

PyPI

Publish a GitHub Release

Publish to PyPI

pypi

PYPI_API_TOKEN

Configure the secrets as GitHub Actions repository secrets or in the corresponding environment. These workflows currently use API tokens, not Trusted Publishing. UPSTAGE_API_KEY is required to run the MCP server and call Upstage APIs; it is separate from the publishing credentials.

Merging into main or pushing a tag alone does not publish to PyPI. A draft release does not publish either. Publishing a GitHub Release, including a prerelease, triggers the PyPI workflow. Use TestPyPI to validate a package before a public release.

1. Prepare a new package version

  1. Fetch the latest main and dev, reconcile changes, and review the commits included in the release.

  2. Set __version__ in src/upstage_mcp/init.py. Hatch reads the package version from this file; the release tag does not set it. Use a patch increment for fixes and a minor increment for new functionality, consistent with recent releases.

  3. Run uv lock after changing the version or dependencies, and commit the updated uv.lock when it changes.

  4. Use a version whose distribution filenames have not already been uploaded to the target index. PyPI and TestPyPI cannot overwrite existing distribution files. Additional package changes after a TestPyPI upload need a new version before another upload; do not reuse the same version for different artifacts on the same index.

2. Validate and publish to TestPyPI

Run these checks from the repository root before pushing release changes to dev:

uv lock --check
uv sync --frozen --extra dev
UPSTAGE_API_KEY=dummy uv run --frozen pytest -q
uv build

A dummy key is sufficient for the automated tests, but not for real API calls. CI also tests fresh installations without the lockfile on Python 3.10 and 3.12, plus a locked installation.

After pushing to dev, confirm both CI and Publish to TestPyPI succeeded for the intended commit, and check that the expected wheel and source distribution exist on TestPyPI. CI and publishing run independently; a successful upload does not prove CI passed. Inspect the built package and test its MCP behavior before promoting it.

3. Promote dev to main

Create a release PR with dev as the head and main as the base. The branch-policy workflow automatically closes newly opened PRs to main unless their head is this repository's dev branch.

gh pr create --base main --head dev --title "release: <version>"

Describe the included changes and validation results in the PR description.

Wait for the release PR's checks and required reviews to pass, then merge it. Verify that the merged commit contains exactly the version and changes you intend to publish. CI is not a dependency of the PyPI publishing workflow, so complete this verification before publishing the release.

4. Publish the GitHub Release

Use the merged release PR's exact commit as the tag target. Replace the placeholders below; the version must match __version__ and must be unused on PyPI. Existing releases use tags without a v prefix, such as 0.2.0.

RELEASE_VERSION="<new-version>"
RELEASE_PR="<merged-release-pr-number>"
RELEASE_SHA=$(gh pr view "$RELEASE_PR" --json mergeCommit --jq '.mergeCommit.oid')

git fetch origin main --tags
git show "$RELEASE_SHA:src/upstage_mcp/__init__.py"

# Run only after confirming the commit and version above.
gh release create "$RELEASE_VERSION" \
  --target "$RELEASE_SHA" \
  --title "Upstage MCP v$RELEASE_VERSION" \
  --generate-notes \
  --latest

Confirm that the tag points to the intended commit. If the tag already exists, --target does not move it; verify the existing tag before publishing. Do not retag a published release to repair a package.

5. Verify the public package

  1. In GitHub Actions, wait for both build and publish in Publish to PyPI to finish successfully. Check the run's commit SHA against the release commit; a queued run or a published GitHub Release alone is not deployment proof.

  2. Confirm the version, wheel, and source distribution on PyPI.

  3. Install the exact version from the public index, without loading the local checkout:

uv run --no-project --index-url https://pypi.org/simple \
  --refresh-package mcp-upstage --with "mcp-upstage==$RELEASE_VERSION" \
  python -c 'from importlib.metadata import version; print(version("mcp-upstage"))'

Configure an MCP client with the following command and arguments, replacing <version> with the released version. Supply a real UPSTAGE_API_KEY through the client's environment settings.

{
  "command": "uvx",
  "args": ["--index-url", "https://pypi.org/simple", "--refresh-package", "mcp-upstage", "mcp-upstage==<version>"]
}

Restart the client, initialize the MCP connection, and list tools. Confirm parse_document and extract_information are available and the parsing schema exposes mode, ocr, and model.

For an end-to-end check, use a small synthetic document with known values. Verify default/standard, enhanced, and auto parsing, the API-reported model and per-mode usage, information extraction, and the saved result files under ~/.mcp-upstage/outputs/. Test automatic schema generation and an explicit schema. These calls use the real Upstage API and incur normal usage charges; enhanced processing can cost more than standard. Import or tool-list checks alone do not verify document processing.

Known limitation observed with mcp-upstage 0.2.0 and mcp 1.30.0: passing a JSON object encoded as a schema_json string fails MCP argument validation before the extraction API is called. Automatic schema generation and schema_path with a JSON schema file were verified successfully. Record this limitation when validating 0.2.0; do not count the failing path as passed.

If publishing fails, inspect the failed job before retrying. Check token access, the version, and whether either distribution was already uploaded. Do not assume a failed workflow means no files reached the index. For a faulty published package, fix the code and release a new version rather than overwriting the existing one.

Contributing

Contributions are welcome! If you wish to enhance the project or add new features, please fork the repository and submit a pull request. For major changes, please open an issue first to discuss what you would like to change.

License

This project is licensed under the MIT License.

Available Tools

2 tools
extract_informationC

Extract structured information from documents using Upstage Universal Information Extraction.

This tool can extract key information from any document type without pre-training.
You can either provide a schema defining what information to extract, or let the system
automatically generate an appropriate schema based on the document content.

Supported file formats: JPEG, PNG, BMP, PDF, TIFF, HEIC, DOCX, PPTX, XLSX
Max file size: 50MB
Max pages: 100

Args:
    file_path: Path to the document file to process
    schema_path: Optional path to a JSON file containing the extraction schema
    schema_json: Optional JSON string containing the extraction schema
    auto_generate_schema: Whether to automatically generate a schema if none is provided
NameRequiredDescriptionDefault
file_pathYesPath to the document file to process
schema_jsonNoJSON string containing the extraction schema (optional)
schema_pathNoPath to JSON file containing the extraction schema (optional)
auto_generate_schemaNoWhether to automatically generate a schema

TDQS

C2.9/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 discloses supported file formats, maximum file size (50MB), and maximum pages (100), which are useful constraints. However, it does not mention whether the operation is read-only, what happens on failure, or any rate limits. Given that the tool is non-destructive, the transparency is adequate but not comprehensive.

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

Conciseness3/5

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

The description is reasonably structured with a brief intro followed by bullet points for constraints and a list of arguments. However, it is somewhat verbose, especially the 'Args' section which duplicates the input schema. Not all sentences earn their place; the 'without pre-training' phrase is extraneous.

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

Completeness2/5

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

Given the tool has 4 parameters, no output schema, and no annotations, the description should cover output format and error behavior. It does not explain what the extracted information looks like or how to interpret the result. It also does not mention any prerequisites (e.g., valid document content) or edge cases, leaving significant gaps for the agent.

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%, so the baseline is 3. The description adds context that the schema can be provided via file path, JSON string, or auto-generated, which clarifies the relationship between the parameters. However, it largely repeats the schema descriptions without adding significant new meaning beyond explaining the optionality.

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 clearly states the tool extracts structured information from documents, using a specific technology (Upstage Universal Information Extraction). It mentions key capabilities like schema provision and auto-generation. However, it does not explicitly differentiate itself from the sibling tool 'parse_document', which could cause confusion about which tool to use for what.

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

Usage Guidelines2/5

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

The description explains the flexibility of providing a schema or auto-generating one, but it lacks guidance on when to use this tool versus its sibling 'parse_document'. There are no 'when to use' or 'when not to use' statements, nor prerequisites or context about the expected input document types.

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

parse_documentA

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.
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')

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.2.0
    • Changedparse_document3 fields changed
      • 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. 2 tool updatesv0.1.0
    • First observedextract_information
    • First observedparse_document

TDQS

B3.4/5.0

Scored across 2 tools

Disambiguation4/5

parse_document and extract_information both consume documents, but they target different outputs: layout-preserving digitization versus schema-driven structured extraction. The descriptions make the boundary reasonably clear, though an agent may briefly hesitate because both operate on the same document inputs.

Naming Consistency5/5

Both tool names follow a clear snake_case verb_noun pattern: parse_document and extract_information. The verbs accurately signal the action and the nouns identify the object, with no mixed naming conventions.

Tool Count3/5

Only two tools are exposed, each quite broad. This is borderline thin for a document AI server; while the tools are substantial, the surface does not reach the typical 3-15 well-scoped range.

Completeness4/5

The core document workflows are covered: parsing/digitizing documents and extracting structured information with a provided or auto-generated schema. Minor gaps may remain around batch processing, page-range control, or explicit schema utilities, but agents can likely work around them.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables Claude Desktop to search and query personal document collections (PDF, Word, Markdown, text) using semantic search and conversational AI with full context preservation across exchanges.
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    Enables document processing through Upstage AI services including parsing various document formats, extracting structured information with custom schemas, auto-generating extraction schemas, and classifying documents into categories.
    4
    256 npm
    3
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables querying enterprise documents (DOCX, PDF, PPTX) using natural language, with hybrid search and MCP integration for Claude Desktop and other agents.
    MIT