How do I use MCP Mistral OCR Optimized?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Mistral OCR Optimized extract the tables from invoice.pdf into markdown" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

MCP Mistral OCR Optimized

by snussik

Overview Schema Related Servers Score Discussions

Python

Hybrid

MCP Mistral OCR Optimized

Optimized MCP server for OCR processing using Mistral AI with batch processing and async connection pooling.

🚀 Key Optimizations

Feature	Benefit
Batch Processing API	Up to 50% cost reduction for large file sets
Async Connection Pooling	20-30% faster processing for multiple files
Token-Efficient Defaults	`include_images=False`, `table_format=markdown` saves 30-40% tokens
Concurrent Processing	Process up to 5 files simultaneously
Cross-Platform Paths	Works on Windows, macOS, Linux, and Docker
Configurable Parameters	Fine-tune OCR output with table_format, headers, footers

Related MCP server: PDF Reader MCP

📦 Installation

Using UV (Recommended)

# Navigate to project directory
cd D:/dev/mcp_mistral_ocr_opt

# Create and activate virtual environment
uv venv
# Windows
.venv\Scripts\activate
# Unix
source .venv/bin/activate

# Install dependencies
uv pip install .

Using Docker

# Build image
docker build -t mcp-mistral-ocr-opt .

# Run container
docker run -e MISTRAL_API_KEY=your_api_key \
           -v /path/to/your/files:/data/ocr \
           mcp-mistral-ocr-opt:latest

⚙️ Configuration

Environment Variables

Create or edit .env file:

# Required
MISTRAL_API_KEY=your_api_key_here
OCR_DIR=D:/dev/mcp_mistral_ocr_opt/data/ocr

# Optional - Batch Processing
BATCH_MODE=auto                  # auto, always, never
BATCH_MIN_FILES=5                # Use batch processing for 5+ files in auto mode
INLINE_BATCH_THRESHOLD=10        # Use inline batch for <10 files
MAX_CONCURRENT_REQUESTS=5        # Max concurrent API requests

# Optional - OCR Defaults (token optimization)
DEFAULT_TABLE_FORMAT=markdown    # null, markdown, or html
INCLUDE_IMAGES=false             # Default false for token efficiency
EXTRACT_HEADER=false             # Extract document headers
EXTRACT_FOOTER=false             # Extract document footers

Claude Desktop Configuration

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "mistral-ocr-opt": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "D:/dev/mcp_mistral_ocr_opt",
        "-m",
        "src.mcp_mistral_ocr_opt.main"
      ],
      "env": {
        "MISTRAL_API_KEY": "your_api_key_here",
        "OCR_DIR": "D:/dev/mcp_mistral_ocr_opt/data/ocr",
        "BATCH_MODE": "auto"
      }
    }
  }
}

🛠️ Available Tools

1. `process_local_file` - Process a single file

Process a single local file from OCR_DIR.

{
  "name": "process_local_file",
  "arguments": {
    "filename": "document.pdf",
    "table_format": "markdown",
    "extract_header": false,
    "extract_footer": false,
    "include_images": false
  }
}

Parameters:

filename (required): Name of file relative to OCR_DIR
table_format (optional): null, markdown, or html - default: markdown
extract_header (optional): Extract document headers - default: false
extract_footer (optional): Extract document footers - default: false
include_images (optional): Include base64 images - default: false (token efficient)

Supported local file types:

PDFs: .pdf
Images: .jpg, .jpeg, .png, .gif, .webp, .bmp, .avif
Other formats (docx/xlsx/pptx) are not supported

2. `process_batch_local_files` - Process multiple files concurrently

Process multiple files with concurrent or batch processing (auto-selected).

{
  "name": "process_batch_local_files",
  "arguments": {
    "patterns": ["*.pdf", "scanned_*.jpg"],
    "max_files": 100,
    "table_format": "markdown",
    "include_images": false
  }
}

Parameters:

patterns (required): Array of glob patterns (e.g., ["*.pdf", "*.jpg"])
max_files (optional): Maximum files to process
Other parameters same as process_local_file

Auto-selection Logic:

< 5 files: Concurrent processing
5-9 files: Inline batch (if BATCH_MODE=auto)
10+ files: File batch (saves up to 50% cost)

3. `process_url_file` - Process file from URL

Process a file from a public URL.

{
  "name": "process_url_file",
  "arguments": {
    "url": "https://example.com/document.pdf",
    "file_type": "pdf",
    "table_format": "html"
  }
}

4. `create_batch_job` - Create explicit batch job

Create a batch processing job (for large file sets, cost savings up to 50%).

{
  "name": "create_batch_job",
  "arguments": {
    "patterns": ["documents/*.pdf"],
    "use_inline": false,
    "table_format": "markdown"
  }
}

Returns:

{
  "batch_type": "file",
  "job_id": "job_abc123",
  "batch_file_id": "file_xyz789",
  "files_queued": 50,
  "message": "Batch job created with 50 files. Use check_batch_status to monitor progress."
}

5. `check_batch_status` - Monitor batch job

{
  "name": "check_batch_status",
  "arguments": {
    "job_id": "job_abc123"
  }
}

Returns:

{
  "id": "job_abc123",
  "status": "SUCCESS",
  "created_at": "2026-01-22T12:00:00",
  "completed_at": "2026-01-22T12:05:00"
}

6. `download_batch_results` - Download completed results

{
  "name": "download_batch_results",
  "arguments": {
    "job_id": "job_abc123"
  }
}

7. `cancel_batch_job` - Cancel running job

{
  "name": "cancel_batch_job",
  "arguments": {
    "job_id": "job_abc123"
  }
}

8. `list_batch_jobs` - List all batch jobs

{
  "name": "list_batch_jobs",
  "arguments": {
    "status": "RUNNING"
  }
}

📊 Output

OCR results are saved in JSON format in OCR_DIR/output/:

Single files: {filename}_{timestamp}.json
Batch results: batch_results_{job_id}_{timestamp}.jsonl

Result structure:

{
  "pages": [
    {
      "index": 0,
      "markdown": "Extracted text content...",
      "images": [],
      "tables": [],
      "hyperlinks": [],
      "dimensions": {"width": 0, "height": 0}
    }
  ],
  "model": "mistral-ocr-latest",
  "usage_info": {...},
  "_metadata": {
    "source_file": "/path/to/document.pdf",
    "output_file": "/path/to/output.json",
    "file_type": "pdf",
    "processed_at": "2026-01-22T12:00:00",
    "table_format": "markdown",
    "include_images": false
  }
}

🎯 Usage Examples

Example 1: Process a single PDF with tables

{
  "name": "process_local_file",
  "arguments": {
    "filename": "invoice.pdf",
    "table_format": "html",
    "include_images": false
  }
}

Example 2: Process all PDFs in directory with batch

{
  "name": "process_batch_local_files",
  "arguments": {
    "patterns": ["*.pdf"],
    "table_format": "markdown"
  }
}

Example 3: Create explicit batch job for 100+ documents

{
  "name": "create_batch_job",
  "arguments": {
    "patterns": ["documents/**/*.pdf"],
    "use_inline": false,
    "table_format": "html",
    "extract_header": true,
    "extract_footer": true
  }
}

Then monitor:

{
  "name": "check_batch_status",
  "arguments": {
    "job_id": "job_abc123"
  }
}

And download when complete:

{
  "name": "download_batch_results",
  "arguments": {
    "job_id": "job_abc123"
  }
}

🔧 Performance Tips

Token Optimization

Set include_images=false (default) - saves 30-40% tokens
Use table_format="markdown" (default) - more efficient than HTML
Skip extract_header/extract_footer unless needed

Cost Optimization

Use batch processing for 10+ files (up to 50% cost savings)
Set BATCH_MODE=always for large recurring batches
Use max_files to limit processing if needed

Speed Optimization

Increase MAX_CONCURRENT_REQUESTS (default: 5, max: 10)
Use inline batch for 5-9 files (faster startup)
Enable BATCH_MODE=auto (default) for auto-selection

📈 Performance Benchmarks

Scenario	Old Version	Optimized	Improvement
10 files concurrent	45s	12s	4x faster
100 files batch	$5.00	$2.50	50% cheaper
With images (tokens)	100%	60%	40% fewer tokens
PDF processing (API calls)	300	100	3x fewer calls

▶️ Run via UV

uv run pytest
uv run pytest --cov=src --cov-report=term-missing
uv run python -m src.mcp_mistral_ocr_opt.main

🐳 Docker Support

Build Image

docker build -t mcp-mistral-ocr-opt .

Run Container

docker run -e MISTRAL_API_KEY=your_key \
           -e OCR_DIR=/data/ocr \
           -v $(pwd)/data/ocr:/data/ocr \
           mcp-mistral-ocr-opt:latest

Docker Compose

version: '3.8'
services:
  mistral-ocr:
    image: mcp-mistral-ocr-opt:latest
    environment:
      MISTRAL_API_KEY: ${MISTRAL_API_KEY}
      OCR_DIR: /data/ocr
      BATCH_MODE: auto
      MAX_CONCURRENT_REQUESTS: 5
    volumes:
      - ./data/ocr:/data/ocr
    restart: unless-stopped

🤝 Migration from Original

If migrating from the original mcp-mistral-ocr:

API Key: Same key works
Tools: All original tools still work
New Tools: Batch tools added (optional to use)
Defaults: More token-efficient by default

No code changes required for basic usage!

📝 Troubleshooting

Issue: "Configuration error: MISTRAL_API_KEY is required"

Solution: Add MISTRAL_API_KEY=your_key to .env file

Issue: "File not found"

Solution: Check OCR_DIR path in .env and ensure files are in that directory

Issue: "Batch job stuck in QUEUED"

Solution: Check Mistral dashboard or try cancel_batch_job and retry

Issue: Connection errors

Solution: Verify internet connection and API key is valid

📄 License

Based on the original mcp-mistral-ocr project.

🔗 Links

Available Tools

9 tools

cancel_batch_jobC

Cancel a running batch job.

ParametersJSON Schema

Name	Required	Description	Default
`arguments`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided, so description carries full disclosure burden. Mentions 'running' state but fails to explain cancellation semantics (graceful vs immediate, reversible vs permanent, data loss implications), processing time, or success/failure behaviors despite having an output schema.

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?

Extremely concise at four words, but under-specification rather than efficient communication. No wasted words, but insufficient content for a mutative operation with complex parameters and undocumented output schema.

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?

Inadequate for tool complexity: cancellation is typically a sensitive destructive operation, yet description omits parameter details (despite 0% schema coverage), output format (despite existing output schema), error conditions, and authorization requirements.

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

Parameters1/5

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

Schema has 0% description coverage with a single generic parameter 'arguments' (object with additionalProperties: true). Description fails to compensate by documenting expected fields (e.g., job_id, force flag) or providing examples of the argument structure.

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 specific verb 'Cancel' and resource 'batch job', and qualifies with 'running' to indicate state precondition. Distinguishes clearly from siblings like create_batch_job, check_batch_status, or download_batch_results through distinct action verb.

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?

Only implies usage through the word 'running', suggesting it applies to active jobs. No explicit guidance on when to use versus alternatives, prerequisites (e.g., job ID required), or side effects of cancellation.

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

check_batch_statusC

Check the status of a batch processing job.

ParametersJSON Schema

Name	Required	Description	Default
`arguments`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations provided, the description bears full responsibility for behavioral disclosure but only implies read-only safety through the verb 'check'. It omits rate limits, caching behavior, and error handling for invalid job IDs.

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 single sentence is appropriately concise and front-loaded, but the overall description is undersized given the complexity of the opaque parameter structure and the tool's position in a multi-step workflow.

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?

Despite the presence of an output schema (reducing the need to describe return values), the description is incomplete as it fails to clarify the expected contents of the nested 'arguments' parameter and lacks lifecycle context for batch job management.

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

Parameters1/5

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

The input schema has 0% description coverage for the required 'arguments' object parameter. The description fails entirely to compensate by not explaining what specific fields (e.g., job_id) must be included in the generic arguments object.

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 identifies the action (check status) and target resource (batch processing job). While minimal, it is not vague and maps directly to the tool name.

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?

No guidance is provided on when to use this versus siblings like list_batch_jobs (which may also return status) or download_batch_results, nor does it mention whether this is for polling or one-time checks.

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

create_batch_jobC

Create a batch processing job for large file sets.

ParametersJSON Schema

Name	Required	Description	Default
`arguments`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided, so description carries full disclosure burden. 'Create' implies mutation but lacks critical behavioral details: job persistence duration, polling requirements, failure modes, or lifecycle relationship to cancel_batch_job/check_batch_status siblings. With output schema present, return values needn't be described, but operational semantics are missing.

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?

Single sentence is efficient and front-loaded, but severely undersized for tool complexity. With 7 sibling tools in batch ecosystem and completely unspecified parameter schema, the description needs expansion to earn full conciseness credit (conciseness requires completeness).

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?

Inadequate for a workflow-anchored tool with lifecycle implications. While output schema presence reduces need for return value documentation, the combination of 0% schema coverage, catch-all parameter pattern, and multiple related lifecycle tools demands more contextual scaffolding than 7 words provide.

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

Parameters1/5

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

Schema coverage is 0% and the single parameter uses additionalProperties: true (catch-all pattern). Description provides zero guidance on expected argument structure, required fields, or validation rules for the 'arguments' object. Agent cannot determine what keys/values to populate without external knowledge.

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 specific verb (Create) and resource (batch processing job) with scope modifier (large file sets). Implicitly distinguishes from immediate-processing siblings (process_local_file, process_url_file) by using 'job' terminology suggesting deferred/async execution. However, 'large file sets' is vague and doesn't explicitly clarify relationship to process_batch_local_files.

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?

No explicit when-to-use guidance despite significant sibling ambiguity. The tool process_batch_local_files appears to perform similar batch operations, but the description provides no criteria for choosing between immediate processing versus creating a job. No prerequisites or workflow context provided (e.g., that check_batch_status follows creation).

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

download_batch_resultsC

Download results from a completed batch job.

ParametersJSON Schema

Name	Required	Description	Default
`arguments`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Mentions 'completed' constraint but fails to disclose: result format, idempotency, whether download is destructive/removes server-side data, size limits, or required authentication/permissions. Minimal behavioral disclosure.

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?

Single sentence with no redundancy. Appropriately front-loaded with action and target. However, excessive brevity contributes to under-documentation rather than efficient communication.

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?

Critical gaps for a batch job download tool. Despite having output schema (reducing need to describe return values), tool lacks: parameter documentation (what identifies the job?), error behaviors (what if incomplete?), and relationship to sibling tools in the batch workflow.

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

Parameters1/5

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

Complete failure. Schema has 0% coverage with generic 'arguments' object (additionalProperties: true). Description provides zero parameter guidance - doesn't specify that job_id is required, what fields belong in arguments, or expected parameter structure. Description adds no meaning beyond the schema.

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?

Clear verb 'Download' and resource 'results from a completed batch job'. Implicitly distinguishes from siblings like create_batch_job, check_batch_status, and cancel_batch_job by specifying the download action and completed state requirement.

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?

Implies proper timing via 'completed batch job', suggesting prerequisite workflow (job must finish first). However, lacks explicit guidance on when NOT to use (e.g., running/failed jobs), doesn't reference check_batch_status as a prerequisite, and omits alternatives for incomplete jobs.

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

list_batch_jobsC

List batch jobs with optional filtering.

ParametersJSON Schema

Name	Required	Description	Default
`arguments`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations provided, the description carries full disclosure burden but only minimally delivers. It notes 'optional filtering' but fails to clarify what filters are supported, whether results are paginated, or the scope of data returned (e.g., all jobs vs. user's jobs).

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?

Extremely terse at six words. While efficient and front-loaded, the brevity is inappropriate given the schema complexity—leaving critical gaps rather than being appropriately concise. No structural issues, but under-specified.

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?

Incomplete given the tool's complexity. The arbitrary 'arguments' object (allowing any properties) desperately requires documentation of valid filter fields, which is absent. While output schema exists (reducing need to describe return values), the input contract is essentially 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 0% and the single parameter 'arguments' is an opaque object with 'additionalProperties: true' (accepts arbitrary keys). Description mentions 'optional filtering' which weakly maps to the parameter's purpose, but provides no valid keys, value types, or examples to compensate for the completely undocumented schema.

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 specific verb 'List' and resource 'batch jobs', giving a clear high-level purpose. However, fails to distinguish from sibling tool 'check_batch_status' which could confuse agents about whether this returns status details or just job references.

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?

Provides no guidance on when to use this versus siblings like 'check_batch_status' or after 'create_batch_job'. Does not mention prerequisites (e.g., whether jobs must exist first) or pagination behavior despite being a list operation.

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

list_toolsB

List available OCR tools.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, yet description fails to disclose caching behavior, dynamic updates to available tools, or response format. Relies entirely on output schema (indicated in context) for return value documentation.

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?

Extremely brief (4 words) but appropriate for a zero-parameter discovery tool. No redundant information. However, single-sentence structure misses opportunity to add usage context without sacrificing clarity.

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?

Adequate for a simple discovery tool with existing output schema (per context signals) handling return documentation. Missing usage context prevents higher score, but meets minimum requirements given low complexity.

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

Parameters4/5

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

Zero parameters present, which per guidelines warrants a baseline score of 4. Description correctly implies no filtering/parameters are accepted.

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?

Clear verb+resource ('List available OCR tools') that distinguishes from processing siblings like process_local_file and create_batch_job. However, 'tools' is slightly ambiguous (could mean OCR engines vs API endpoints) and lacks the specificity seen in top-tier descriptions.

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?

No guidance on when to invoke this versus other list operations (like list_batch_jobs) or when discovery is necessary (e.g., before submitting jobs). No prerequisites or alternatives mentioned.

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

process_batch_local_filesC

Process multiple local files concurrently.

ParametersJSON Schema

Name	Required	Description	Default
`arguments`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.1/5.0

Behavior2/5

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

Mentions 'concurrently' indicating parallel execution behavior. However, with no annotations provided, the description fails to disclose error handling (partial failure vs atomic), resource costs, rate limits, or what 'processing' actually entails. Missing safety/profile info that annotations would normally cover.

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

Conciseness2/5

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

Extremely terse (6 words) and front-loaded, but given the high complexity (nested objects, opaque schema, batch operation), this constitutes under-specification rather than appropriate conciseness. Critical information is missing.

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?

While an output schema exists (reducing the need to describe returns), the combination of zero annotation coverage and a completely undocumented parameter object leaves critical gaps. Does not explain relationship to batch job lifecycle siblings or required setup.

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

Parameters1/5

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

With 0% schema coverage and a completely opaque 'arguments' object (additionalProperties: true), the description provides zero compensation. No indication of required keys, structure, or what data to pass in the arguments object.

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

Purpose3/5

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

States the resource (local files) and quantity (multiple) with a distinguishing behavioral trait (concurrently), which helps differentiate from siblings like process_local_file. However, the verb 'Process' is vague and doesn't specify what operation is performed (transform, validate, upload, etc.).

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 term 'multiple' implies usage for batch operations versus single-file processing, but provides no explicit when-to-use guidance, prerequisites, or named alternatives. No mention of when to prefer create_batch_job or other batch siblings.

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

process_local_fileC

Process a single local file from OCR_DIR.

ParametersJSON Schema

Name	Required	Description	Default
`arguments`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.1/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Mentions OCR_DIR constraint but fails to disclose critical behaviors: what 'processing' entails, whether files are modified/deleted, where output goes, or if operation is idempotent. Output schema exists but description doesn't reference it.

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

Conciseness2/5

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

Extremely brief (7 words) but undersized for tool complexity. Given nested input structure and output schema, description provides insufficient information density. Front-loaded action verb is good, but sentence doesn't earn its place due to vagueness.

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?

Inadequate for complexity level. Tool has nested objects, output schema exists, and 0% parameter coverage, yet description omits argument documentation, return value hints, and behavioral side effects. Only OCR_DIR provides domain context.

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

Parameters1/5

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

Schema has 0% description coverage with a generic 'arguments' object accepting any additionalProperties. Description completely fails to document expected argument keys, value types, or structure. Critical gap for a nested object parameter.

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

Purpose3/5

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

Mentions specific resource (single local file from OCR_DIR) and implicitly distinguishes from siblings (single vs batch in process_batch_local_files, local vs URL in process_url_file). However, 'Process' is vague and doesn't specify what operation is performed (OCR extraction, validation, conversion?).

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?

No explicit guidance on when to use this tool versus process_batch_local_files or process_url_file. The phrase 'single local file' hints at differentiation but doesn't explicitly recommend workflow or prerequisites.

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

process_url_fileC

Process a file from a URL.

ParametersJSON Schema

Name	Required	Description	Default
`arguments`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It discloses nothing about side effects, idempotency, supported file formats, size limits, authentication requirements, or what the output schema contains. The term 'process' is behaviorally opaque.

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 a single short sentence, which prevents redundancy. However, it is under-specified for the complexity involved—five words cannot adequately describe a tool with nested objects and an output schema.

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 existence of an output schema and a complex nested parameter (arguments with additionalProperties), the description is insufficient. The opaque parameter bag requires documentation that is absent from both schema and description.

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 0% and the description fails to compensate. While it mentions 'from a URL,' the actual parameter is an opaque 'arguments' object with no documented structure. The description doesn't clarify what keys (e.g., 'url', 'headers') should be included in the arguments object.

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

Purpose3/5

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

The description uses the vague verb 'process' but does specify the resource (file) and distinguishes from siblings by mentioning 'from a URL' (contrasting with process_local_file and process_batch_local_files). However, it fails to specify what processing actually occurs (download, parse, validate, etc.).

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?

No explicit guidance on when to use this tool versus process_local_file or process_batch_local_files. While 'URL' in the name/description implies remote files versus local, it doesn't state prerequisites (e.g., publicly accessible URLs) or when local processing is preferred.

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

Install Server

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

TDQS

B3.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: batch job management (cancel, check, create, download, list), tool listing, and file processing (batch local, single local, URL). The descriptions clearly differentiate between batch operations and individual file processing, eliminating any ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case throughout (e.g., cancel_batch_job, process_local_file). The naming is predictable and readable, with no deviations in style or convention across the toolset.

Tool Count5/5

With 9 tools, the count is well-scoped for an OCR server covering batch processing, individual file handling, and job management. Each tool earns its place by addressing specific needs without redundancy or excessive fragmentation.

Completeness4/5

The toolset provides strong coverage for OCR workflows, including CRUD-like operations for batch jobs (create, list, check, cancel, download) and file processing (local and URL). A minor gap is the lack of tools for configuring OCR settings or handling errors, but core operations are well-covered.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

PDF to Markdown (pdf2md.dev)
dev.pdf2md
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
AI & Machine Learning Image & Video Processing
2
Mdkit A
online.mdkit
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Developer Tools RAG Systems Data Platforms
31
Brainiall Documents A
com.brainiall
High-fidelity PDF to structured Markdown conversion and document field extraction.
Data Platforms
31
Document to JSON – PDF Invoice/Statement/Contract Parser
io.github.fashionmascherine-svg
Turn any PDF into structured JSON via AI + OCR: invoices, bank statements, contracts.
Finance AI & Machine Learning
28

Related MCP Servers

Unstructured Document
Documentation Access Developer Tools Search
MKhalusova
F
license
B
quality
D
maintenance
A Model Context Protocol server that enables LLMs to extract and use content from unstructured documents across a wide variety of file formats.
Updated a year ago (2025-03-20 17:15 UTC)
1
11
PDF Reader MCP
File Systems Documentation Access Developer Tools
BACH-AI-Tools
A
license
Not graded
quality
D
maintenance
A high-performance Model Context Protocol server that enables AI agents to extract text, images, and metadata from PDF documents using parallel processing. It features intelligent Y-coordinate content ordering to preserve natural reading flow and supports both local files and URL-based sources.
Updated 7 months ago (2026-02-16 15:56 UTC)
14
MIT
Mistral OCR MCP Server
Image & Video Processing Documentation Access File Systems
D-Diaa
F
license
Not graded
quality
D
maintenance
An MCP server that enables Claude to perform OCR on local files using Mistral AI's document processing capabilities. It converts documents and images into markdown format for seamless analysis and interaction.
Updated a year ago (2025-08-04 02:33 UTC)
Medical MCP Server
Biology & Medicine AI & Machine Learning Vector Databases
KalyankumarKonduru
A
license
Not graded
quality
D
maintenance
A comprehensive Model Context Protocol (MCP) server for medical document processing with advanced AI capabilities, including OCR, medical NER, local embeddings, and vector search.
Updated a year ago (2025-08-16 03:16 UTC)
225
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/snussik/mcp_mistral_ocr_opt'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

MCP Mistral OCR Optimized

🚀 Key Optimizations

📦 Installation

Using UV (Recommended)

Using Docker

⚙️ Configuration

Environment Variables

Claude Desktop Configuration

🛠️ Available Tools

1. process_local_file - Process a single file

2. process_batch_local_files - Process multiple files concurrently

3. process_url_file - Process file from URL

4. create_batch_job - Create explicit batch job

5. check_batch_status - Monitor batch job

6. download_batch_results - Download completed results

7. cancel_batch_job - Cancel running job

8. list_batch_jobs - List all batch jobs

📊 Output

🎯 Usage Examples

Example 1: Process a single PDF with tables

Example 2: Process all PDFs in directory with batch

Example 3: Create explicit batch job for 100+ documents

🔧 Performance Tips

Token Optimization

Cost Optimization

Speed Optimization

📈 Performance Benchmarks

▶️ Run via UV

🐳 Docker Support

Build Image

Run Container

Docker Compose

🤝 Migration from Original

📝 Troubleshooting

Issue: "Configuration error: MISTRAL_API_KEY is required"

Issue: "File not found"

Issue: "Batch job stuck in QUEUED"

Issue: Connection errors

📄 License

🔗 Links

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `process_local_file` - Process a single file

2. `process_batch_local_files` - Process multiple files concurrently

3. `process_url_file` - Process file from URL

4. `create_batch_job` - Create explicit batch job

5. `check_batch_status` - Monitor batch job

6. `download_batch_results` - Download completed results

7. `cancel_batch_job` - Cancel running job

8. `list_batch_jobs` - List all batch jobs