How do I use ocr-mcp?

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., "@ocr-mcp OCR this scanned invoice and show me the text with confidence scores." 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.

ocr-mcp

by Prekzursil

Overview Schema Related Servers Score Discussions

Python

Local

abbyy-finereader-ocr-mcp — Multi-Engine OCR MCP Server

A Model Context Protocol server that gives AI assistants (Claude Code, Codex, Cursor, …) OCR with first-class accuracy handling and evaluation. It wraps three engines behind one interface and can score and compare them:

Engine	Backend	Local?	Confidence	Notes
RapidOCR (default)	PaddleOCR models on onnxruntime	✅ fully local/headless	per-line	No GPU/torch needed; great default
Tesseract	Google Tesseract via `pytesseract`	✅ local	per-word	Needs `tesseract.exe` on PATH
ABBYY FineReader 16	local FineReader Regular CLI (`/send Clipboard`)	✅ local	—	Best accuracy; GUI flashes, 1 doc at a time. Headless file output needs ABBYY's paid Extended CLI

Why multi-engine? No single OCR engine wins on every document. This server lets the model run several, compare their agreement, and score them against ground truth (CER/WER) — so you can pick the right engine per job instead of guessing.

Features

📄 OCR images and PDFs (PDFs rasterized via PyMuPDF, per-page OCR).
🎯 Confidence scores per line/word, with low-confidence flagging.
⚖️ compare_engines — run every available engine on one document and report pairwise agreement + a consensus pick (no ground truth required).
📏 evaluate_accuracy — CER / WER, char/word accuracy %, and edit breakdown (substitutions/deletions/insertions) against a ground-truth text file.
🧹 Optional preprocessing (grayscale / denoise / deskew via OpenCV).
🧱 Fails soft: an unavailable engine is reported, never crashes the server.

Related MCP server: Local Documents MCP Server

Tools

Tool	Description
`list_engines()`	Which engines are usable on this machine + status. Call first.
`ocr_image(path, engine="auto", lang="en", preprocess=False)`	OCR one image.
`ocr_pdf(path, engine="auto", lang="en", pages="all", dpi=300)`	OCR a PDF.
`batch_ocr(paths_or_glob, engine="auto", lang="en")`	OCR many images (glob or JSON list).
`compare_engines(path, lang="en")`	Run all engines, compare agreement + consensus.
`evaluate_accuracy(ground_truth_path, ocr_text="" \| ocr_path="", engine, lang)`	CER/WER vs ground truth.

engine ∈ auto (=RapidOCR) · rapidocr · tesseract · finereader. lang is an ISO-639-1 code (en, de, fr, ro, zh, …), mapped per engine.

Requirements

Python ≥ 3.12 (3.12 recommended — all wheels mature; 3.14 also works for the core RapidOCR path but OpenCV/PyMuPDF wheels may lag).
Tesseract (optional): install Tesseract-OCR and add tesseract.exe to PATH for that engine.
ABBYY FineReader 16 (optional): a local install enables the FineReader engine (Regular-CLI clipboard mode). Headless file output requires ABBYY's Extended CLI license.

Install

git clone https://github.com/Prekzursil/abbyy-finereader-ocr-mcp
cd abbyy-finereader-ocr-mcp
uv venv --python 3.12
uv pip install -e .
# (first OCR call downloads the small RapidOCR ONNX models, ~?? MB, cached locally)

Configure

Claude Code

claude mcp add ocr -s user -- "/abs/path/abbyy-finereader-ocr-mcp/.venv/Scripts/python.exe" "/abs/path/abbyy-finereader-ocr-mcp/index.py"

Codex (`~/.codex/config.toml`)

[mcp_servers.ocr]
command = "D:\\path\\abbyy-finereader-ocr-mcp\\.venv\\Scripts\\python.exe"
args = ["D:\\path\\abbyy-finereader-ocr-mcp\\index.py"]
startup_timeout_sec = 60
tool_timeout_sec = 300

[mcp_servers.ocr.env]
PYTHONUTF8 = "1"
PYTHONUNBUFFERED = "1"

Generic MCP client (`mcp.json`)

{
  "mcpServers": {
    "ocr": { "command": "/abs/path/.venv/bin/python", "args": ["/abs/path/index.py"] }
  }
}

Usage examples

> OCR this scan and tell me how confident you are.
  → ocr_image("C:/scans/invoice.png")  → text + mean_confidence + low-confidence lines

> Which engine reads this receipt best?
  → compare_engines("C:/scans/receipt.jpg")  → per-engine text + agreement + consensus

> How accurate is RapidOCR on this page vs my transcript?
  → evaluate_accuracy("truth.txt", ocr_path="page.png", engine="rapidocr") → CER/WER

Evaluation methodology

evaluate_accuracy uses jiwer for CER (character error rate) and WER (word error rate). Lower is better; char_accuracy_pct = (1 − CER)·100. Keep ground-truth .txt files next to your test images to track engine accuracy over time. compare_engines is the no-ground-truth fallback: it reports how much the engines agree and which one is the consensus.

Development

uv pip install -e ".[test]"
pytest        # renders known text → OCR → asserts recovery + low CER

Security

This server reads any file path the MCP client gives it — i.e. any file readable by the server process. There is no sandbox by default. Run it only with a trusted MCP client, and be aware that an LLM driving the tools could be prompted to read arbitrary local files.

For defense-in-depth, set OCR_MCP_ALLOWED_DIRS (an os.pathsep-separated list of directories) to restrict all tools to files under those roots:

[mcp_servers.ocr.env]
OCR_MCP_ALLOWED_DIRS = "D:\\scans;D:\\documents"

Also note: batch_ocr with a recursive glob (**/*.png) can match very large file sets — scope your globs. The FineReader engine shells out to the local FineReaderOCR.exe (list-form args, no shell) and reads the OS clipboard.

License

MIT — see LICENSE.

Acknowledgements

RapidOCR · Tesseract · ABBYY FineReader · jiwer · PyMuPDF · MCP

Available Tools

6 tools

batch_ocrA

OCR many images. paths_or_glob is a glob (e.g. 'C:/scans/*.png') or a JSON list of absolute paths. Returns JSON: {count, results:[...]}.

ParametersJSON Schema

Name	Required	Default
`paths_or_glob`	Yes
`engine`	No	auto
`lang`	No	en

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description must convey behavior. It explains the input format (glob or JSON list) and return format (JSON with count and results), which is essential. However, it does not disclose potential side effects, concurrency limitations, or error handling, leaving gaps in behavioral understanding.

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 extremely concise: two sentences with no wasted words. It front-loads the purpose ('OCR many images') and packs essential parameter and output format details into the second sentence.

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 tool with 3 parameters, 1 required, and no annotations, the description provides input/output format basics but omits engine options, language support, performance considerations, and error behavior. The output schema exists but the description still adds the return structure, making it adequate but not comprehensive.

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 description coverage is 0%, so the description should compensate. It explains the 'paths_or_glob' parameter format in detail but provides no semantics for 'engine' or 'lang' parameters, which have defaults but no description. Only one of three parameters is adequately documented.

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 starts with 'OCR many images,' which clearly states the tool's purpose as a batch OCR operation. It distinguishes itself from siblings like 'ocr_image' (single image) and 'ocr_pdf' (PDF).

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?

The description implies usage for multiple images via 'many images' and the glob/list input, but it does not explicitly guide when to use this tool versus alternatives like 'ocr_image' for single images or 'ocr_pdf' for PDFs. No when-not-to-use or exclusion criteria are provided.

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

compare_enginesA

Run ALL available engines on one image and compare them — the core accuracy tool when you have no ground truth.

Returns JSON: per-engine {text, mean_confidence, ok}, plus pairwise text similarity, average agreement, and a 'consensus_engine' (the one whose output best agrees with the others).

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`lang`	No		en

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description bears full burden. It discloses the return JSON structure in detail, including per-engine fields and consensus engine. It does not explicitly state read-only or destructive nature, but it's implied.

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?

The description is two sentences: first defines purpose, second details output. No unnecessary text. Slightly more could be added for parameter context, but it remains efficient.

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

Completeness4/5

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

Given the presence of an output schema (not shown), the description explains return values well. It does not cover error cases or prerequisites (e.g., engines must be available). Siblings provide context, but missing parameter info reduces completeness.

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%, but the description adds no information about parameters. It does not explain 'path' or 'lang' beyond what the schema provides (name, type, required). This is a missed opportunity to clarify what image path is expected or language usage.

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 uses specific verb-resource ('Run ALL available engines on one image and compare') and distinguishes from siblings like batch_ocr and ocr_image. It clearly states it's the core accuracy tool when no ground truth exists.

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?

The description explicitly states when to use ('when you have no ground truth'), implying contrast with evaluate_accuracy. However, it does not explicitly mention when not to use or list alternatives beyond the inferred context.

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

evaluate_accuracyA

Score OCR output against a ground-truth text file (CER/WER).

Provide EITHER ocr_text (already-extracted text) OR ocr_path (an image/PDF to OCR now with engine). Compares against the UTF-8 text at ground_truth_path.

Returns JSON: {cer, wer, char_accuracy_pct, word_accuracy_pct, substitutions, deletions, insertions, hits}.

ParametersJSON Schema

Name	Required	Default
`ground_truth_path`	Yes
`ocr_text`	No
`ocr_path`	No
`engine`	No	auto
`lang`	No	en

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It describes the output JSON format and the two input modes, but it doesn't address edge cases (e.g., what happens if both ocr_text and ocr_path are provided, or if files don't exist) or error behavior. Some ambiguity remains.

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 very concise with two focused paragraphs. It front-loads the core purpose, then systematically explains parameters and output. No unnecessary words.

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

Completeness4/5

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

Given the tool's complexity and the presence of an output schema (though not shown in full), the description covers the return format and parameter semantics. It lacks details on error conditions and parameter exclusivity, but it is otherwise complete.

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

Parameters5/5

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

The description adds rich context to all five parameters: ground_truth_path is a UTF-8 text file, ocr_text is pre-extracted text, ocr_path triggers on-the-fly OCR, engine defaults to 'auto' and is used with ocr_path, and lang defaults to 'en'. This compensates for the 0% schema coverage.

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 explicitly states the tool scores OCR output using CER/WER metrics. It clearly distinguishes itself from sibling OCR tools by focusing on evaluation, not OCR extraction.

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 specifies when to use each input parameter (ocr_text vs ocr_path) and mentions the required ground_truth_path. However, it doesn't explicitly state when not to use this tool or mention alternatives among siblings, though the differentiation is clear.

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

list_enginesA

List OCR engines and whether each is currently usable on this machine.

Returns JSON: for each engine -> {available, status}. Call this first to see which engines compare_engines will actually run.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description discloses the tool's behavior well: it returns availability and status for each engine, and checks usability on the current machine. It does not cover error handling, but for a simple list tool this is sufficient.

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?

Two sentences, no wasted words. The first sentence states the core purpose, the second adds output format and usage guidance. Highly efficient and front-loaded.

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

Completeness5/5

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

Given zero parameters and sibling tools, the description is complete. It explains the output structure and the tool's role in a workflow (called before compare_engines), which is sufficient.

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?

There are no parameters, and schema coverage is 100%. The description adds meaning by explaining what the tool does and its output, which meets the baseline for zero-parameter tools.

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 clearly states the tool lists OCR engines and their usability. It uses a specific verb ('List'), a resource ('OCR engines'), and distinguishes itself from siblings by mentioning compare_engines.

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?

The description explicitly says 'Call this first to see which engines compare_engines will actually run,' providing clear context for when to use. It lacks explicit when-not or alternatives, but the guidance is strong.

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

ocr_imageA

OCR a single image file (PNG/JPG/TIFF/BMP).

Args: path: absolute path to the image. engine: 'auto' (RapidOCR), 'rapidocr', 'tesseract', or 'finereader'. lang: ISO 639-1 code ('en','de','fr','ro',...). Mapped per-engine. preprocess: if true, apply grayscale/denoise/deskew first (needs opencv).

Returns JSON: {engine, ok, text, mean_confidence, line_count, low_confidence_count, lines:[{text,confidence,bbox}], warnings}.

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`engine`	No	auto
`lang`	No	en
`preprocess`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavior: return format (JSON with fields like engine, ok, text, mean_confidence, lines with confidence and bbox), preprocessing requirement of opencv, and language mapping per engine. No contradictions.

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 efficiently structured as a docstring with Args and Returns. Every sentence adds value without redundancy, front-loading the core action.

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

Completeness5/5

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

Given the presence of an output schema, the description still provides a detailed breakdown of the return JSON, covering all parameters and behavioral nuances. Complete for a 4-parameter tool.

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

Parameters5/5

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

Schema coverage is 0%, but the description compensates by explaining each parameter: path as absolute path, engine as list of options, lang as ISO code with per-engine mapping, preprocess as boolean. Adds significant meaning beyond the schema.

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 clearly states the tool's purpose: 'OCR a single image file (PNG/JPG/TIFF/BMP).' This is a specific verb+resource combination that distinguishes it from sibling tools like ocr_pdf and batch_ocr.

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?

The description explains parameters and options (e.g., engine choices, preprocessing) but does not explicitly state when to use this tool versus siblings. It implies usage context but lacks explicit alternatives.

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

ocr_pdfA

OCR a PDF by rasterizing pages (PyMuPDF) then running an engine per page.

Args: path: absolute path to the PDF. engine/lang: see ocr_image. pages: 'all' or a range like '1-3,5'. dpi: rasterization DPI (default 300; higher = slower, more accurate).

Returns JSON: {page_count, pages:[{page, ...ocr_image result...}], full_text}.

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`engine`	No	auto
`lang`	No	en
`pages`	No	all
`dpi`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It explains the rasterization process, parameter defaults (DPI=300) and trade-offs (higher = slower, more accurate), and the structure of the JSON output. However, it omits potential error conditions or file size limits.

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 concise (5 lines) with a clear Args section and Returns section. Every sentence adds value; no redundancy or fluff.

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

Completeness4/5

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

Given 5 parameters, no annotations, but a defined output, the description covers purpose, process, parameters, and return structure. It references ocr_image for engine/lang details. Minor gaps: no error handling or constraints on path validity, but generally complete.

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

Parameters5/5

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

Schema description coverage is 0%, but the description adds full meaning for all five parameters: path (absolute path), engine/lang (refers to ocr_image), pages (range syntax), dpi (with default and performance trade-off). This significantly exceeds the schema's bare parameter names.

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 clearly states the verb 'OCR', the resource 'PDF', and the process 'rasterizing pages then running an engine per page'. This distinguishes it from siblings like ocr_image (single image) and batch_ocr.

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?

Usage is implied for PDFs, but there is no explicit guidance on when to use this tool versus alternatives like ocr_image or batch_ocr. No when-not-to-use or exclusions are provided.

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. Dates show when Glama detected each change.

6 tool updatesv0.1.0Jun 10, 2026
- First observedbatch_ocr
- First observedcompare_engines
- First observedevaluate_accuracy
- First observedlist_engines
- First observedocr_image
- First observedocr_pdf

Install Server

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

TDQS

A4.1/5.0

Disambiguation5/5

Each tool serves a clearly distinct purpose: listing engines, OCR on single image, PDF, batch, cross-engine comparison, and accuracy evaluation. There is no overlap or ambiguity.

Naming Consistency4/5

Tool names follow a verb_noun pattern in snake_case, though some use 'ocr' as a verb prefix (ocr_image, ocr_pdf) while others use descriptive verbs (list_engines, compare_engines, evaluate_accuracy). This is mostly consistent and readable.

Tool Count5/5

Six tools is well-scoped for an OCR server, covering essential operations without bloat. Each tool earns its place.

Completeness4/5

Core OCR workflows are covered: single image, PDF, batch, engine listing, comparison, and accuracy evaluation. Minor gaps (e.g., no tool for engine configuration) but the surface is complete for typical use.

Maintenance

ActivityStale

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

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
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
mcp AOAuth
io.scorecard
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
RAG Systems Monitoring Testing & QA Tools
3

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
-
Local Documents MCP Server
File Systems Text Summarization App Automation
Baronco
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server that allows AI assistants to discover, load, and process local documents on Windows systems, with support for multiple file formats and OCR capabilities for scanned PDFs.
Updated a year ago (2025-07-07 00:46 UTC)
2
-
WebSurfer MCP
Web Scraping Browser Automation Search
crybo-rybo
A
license
B
quality
D
maintenance
A Model Context Protocol server that enables AI assistants to securely fetch and extract readable text content from web pages through a standardized interface.
Updated 6 months ago (2026-03-12 21:20 UTC)
1
MIT
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)
152
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/Prekzursil/abbyy-finereader-ocr-mcp'

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

abbyy-finereader-ocr-mcp — Multi-Engine OCR MCP Server

Features

Tools

Requirements

Install

Configure

Claude Code

Codex (~/.codex/config.toml)

Generic MCP client (mcp.json)

Usage examples

Evaluation methodology

Development

Security

License

Acknowledgements

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Codex (`~/.codex/config.toml`)

Generic MCP client (`mcp.json`)