Lizeur is an MCP server that extracts and processes content from PDF documents using Mistral AI's OCR technology. It can extract text from PDFs and convert content to markdown format for easier consumption. The server provides two main functions: read_pdf for retrieving full OCR metadata including bounding boxes and page information, and read_pdf_text for simplified markdown text extraction that's optimized for AI agents. It features intelligent caching to prevent redundant OCR processing and reduce costs.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Lizeur read the PDF at /Users/alex/docs/research-paper.pdf and summarize the key findings"
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.
Lizeur is a Model Context Protocol (MCP) server that enables AI assistants to extract and read content from PDF documents using Mistral AI's OCR capabilities. It provides a simple interface for converting PDF files to markdown text that can be easily consumed by AI models.
PDF OCR Processing: Uses Mistral AI's latest OCR model to extract text from PDF documents
Intelligent Caching: Automatically caches processed documents to avoid re-processing
Markdown Output: Returns clean markdown text for easy integration with AI workflows
FastMCP Integration: Built with FastMCP for optimal performance and ease of use
Related MCP server: PDF Reader MCP Server
Python 3.10
UV package manager
Mistral AI API key
pip install lizeurAnd add the following configuration to your mcp.json file:
Note: Lizeur will be installed in the python3.10 folder. If this folder is not in your system PATH, your IDE may not be able to detect the lizeur binary.
Solution: You can add the full path to the lizeur binary in the command field to ensure your IDE can locate it.
{
"mcpServers": {
"lizeur": {
"command": "lizeur",
"env": {
"MISTRAL_API_KEY": "your-mistral-api-key-here",
"CACHE_PATH": "your cache path",
}
}
}
}git clone https://github.com/SilverBzH/lizeur
cd lizeur# Create a virtual environment
uv venv --python 3.10
# Activate the virtual environment
# On macOS/Linux:
source .venv/bin/activate
# On Windows:
# .venv\Scripts\activate# Install dependencies
uv sync
# Build the package
uv build# Install the package system-wide
uv pip install --system .This will install the lizeur command globally on your system.
Once configured, the MCP server provides two tools that can be used by AI assistants:
read_pdfFunction: read_pdf
Parameter: absolute_path (string) - The absolute path to the PDF file
Returns: Complete OCR response including all pages with markdown content, bounding boxes, and other OCR metadata
read_pdf_textFunction: read_pdf_text
Parameter: absolute_path (string) - The absolute path to the PDF file
Returns: Markdown text content from all pages without the full OCR metadata (simpler for agents to process)
The AI assistant can now use the tools like this:
What the OP command looks like for this specific controller, here is the doc /path/to/document.pdfThe MCP server will:
Check if the document is already cached
If not cached, upload the PDF to Mistral AI for OCR processing This will use your MISTRAL API key and cost money
Extract the text and convert it to markdown
Cache the result for future use
Return the markdown content
Note: Use read_pdf_text when you only need the text content, or read_pdf when you need the complete OCR response with metadata. read_pdf can be confusion for some agent if the pdf file is big.
# Install in development mode
uv pip install -e .
# Run the server directly
python main.pymain.py - Main server implementation with FastMCP integration
pyproject.toml - Project configuration and dependencies
uv.lock - Locked dependency versions
mcp[cli]>=1.12.4 - Model Context Protocol implementation
mistralai>=0.0.10 - Mistral AI Python client
This project is licensed under the MIT License.
For issues and questions, please refer to the project repository or contact the maintainers.
Read a PDF document and return the complete OCRResponse as a dictionary.
Returns the full OCR response including all pages, not just the first page. The response includes pages with markdown content, bounding boxes, and other OCR metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| absolute_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some context: it describes the return format ('complete OCRResponse as a dictionary'), specifies that it includes all pages and metadata like markdown content and bounding boxes. However, it lacks details on permissions, error handling, performance, or other operational traits that would be helpful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that are front-loaded: the first sentence states the core purpose, and the following sentences add important details about the response. There's minimal waste, though it could be slightly more structured by explicitly separating purpose from output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (reading PDFs with OCR), no annotations, no output schema, and low schema coverage, the description is partially complete. It covers the output format and scope well but misses parameter explanations and behavioral context like error cases or limitations. It's adequate as a minimum viable description but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It doesn't mention the 'absolute_path' parameter at all, failing to explain what it represents or provide any usage context. Since schema coverage is low, the description adds no value beyond what the schema provides, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Read a PDF document and return the complete OCRResponse as a dictionary.' It specifies the verb ('read'), resource ('PDF document'), and output format ('OCRResponse as a dictionary'). However, it doesn't explicitly differentiate from its sibling 'read_pdf_text' beyond mentioning the full OCR response, leaving some ambiguity about the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions returning 'the complete OCR response' and not just the first page, but doesn't explain when to choose this over 'read_pdf_text' or other potential tools. There are no explicit when/when-not instructions or named alternatives beyond the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a PDF document and return only the markdown text content from all pages.
This is a simpler alternative to read_pdf that returns just the text content
without the full OCR metadata, which can be easier for agents to process.
| Name | Required | Description | Default |
|---|---|---|---|
| absolute_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 discloses the tool's behavior by stating it reads PDFs and returns markdown text, but lacks details on error handling, performance, or limitations (e.g., file size, supported PDF formats). The description adds some value but doesn't fully cover behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a concise explanation of its advantage over the sibling tool. Every sentence adds value without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and low complexity, the description is mostly complete. It clearly states the purpose, usage guidelines, and output type. However, it could benefit from more behavioral details (e.g., error cases) to be fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It doesn't explicitly mention the 'absolute_path' parameter, but implies it by referring to reading 'a PDF document.' Since there's only one parameter, the baseline is 4, as the description provides enough context to infer the parameter's purpose without detailed semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Read') and resource ('a PDF document'), specifies the output ('markdown text content from all pages'), and explicitly distinguishes it from its sibling tool ('read_pdf') by noting it's a simpler alternative that returns just text without full OCR metadata. This provides specific differentiation and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool vs. its alternative: 'This is a simpler alternative to read_pdf that returns just the text content without the full OCR metadata, which can be easier for agents to process.' It clearly defines the context for choosing this tool over its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have overlapping purposes: both read PDF documents and extract text content. While read_pdf returns full OCR metadata and read_pdf_text returns only markdown text, an agent might struggle to choose between them when only text is needed, as both could technically serve that purpose. The descriptions help clarify the difference, but the core functionality is very similar.
Both tools follow a consistent verb_noun naming pattern with snake_case: read_pdf and read_pdf_text. The naming is clear and predictable, making it easy for agents to understand the action (read) and target (pdf or pdf_text). There are no deviations or mixed conventions in this small set.
With only 2 tools, this server feels under-scoped for a PDF processing domain. While the tools cover reading and extracting text, there are obvious gaps like creating, editing, or converting PDFs. A typical PDF server would benefit from more operations, making this count too low for comprehensive functionality.
The tool surface is severely incomplete for PDF processing. It only includes reading operations (two variants of the same basic function) and lacks essential capabilities such as creating PDFs, merging/splitting files, converting formats, or editing content. This will likely cause agent failures when more complex tasks are required.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate and read PDFs for AI agents: a generate_pdf and a read_pdf tool, priced per document.
High-fidelity PDF to structured Markdown conversion and document field extraction.
Extract PDFs to Markdown, RAG chunks and cited tables; publish tracked Doc Links with read stats.
Read PDFs and images as markdown or text, with exact costs and hard spend caps. $0.75/1k pages.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SilverBzH/lizeur'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
