Enables document processing (Markdown to PDF, text extraction, merging, URL to PDF) for Hermes Agent.
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., "@Doc MCP Server Extract text from quarterly_report.pdf"
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.
A Model Context Protocol (MCP) server for document processing ā PDF generation with Markdown rendering, text extraction, merging, and web-to-PDF conversion.
Built for AI agents. Works with Hermes Agent, Claude Code, Cursor, and any MCP-compatible client.
Tool | Description |
| Render Markdown ā PDF with headings, lists, code blocks, HR |
| Simple plain text ā PDF with custom font size |
| Fetch a URL via Jina Reader and save as PDF |
| Extract text from any PDF (file, URL, or base64) |
| Read PDF metadata (title, author, pages, size) |
| Merge multiple PDFs into a single document |
| Text format conversion & cleanup (case, whitespace) |
| Word, character, line, paragraph & reading time stats |
Related MCP server: mcp-server-convert
# From PyPI (coming soon)
pip install doc-mcp-server
# Or directly from GitHub
pip install git+https://github.com/ceeyang-ai/doc-mcp-server.git# Start as MCP server (stdio mode)
doc-mcp-serverAdd to ~/.hermes/config.yaml:
mcp_servers:
doc:
command: "doc-mcp-server"Restart ā use mcp_doc_markdown_to_pdf, mcp_doc_extract_pdf_text, etc.
Add to your MCP config:
{
"mcpServers": {
"doc": {
"command": "doc-mcp-server"
}
}
}# Via MCP tool call
result = markdown_to_pdf(
markdown="# My Report\n\n- Item 1\n- Item 2\n\n```python\nprint('hello')\n```",
title="Report",
filename="report.pdf"
)result = merge_pdfs(
sources=[
"https://example.com/doc1.pdf",
"/path/to/local/file.pdf",
]
)result = url_to_pdf(
url="https://en.wikipedia.org/wiki/Markdown",
filename="wiki-md.pdf"
)Python 3.10+
fpdf2 ā„ 2.8
PyMuPDF ā„ 1.24
mcp ā„ 1.0
doc-mcp-server/
āāā doc_mcp_server/
ā āāā __init__.py # All tools + MarkdownPDF engine
āāā pyproject.toml # Build config (setuptools)
āāā README.md
āāā LICENSE (MIT)git clone https://github.com/ceeyang-ai/doc-mcp-server.git
cd doc-mcp-server
pip install -e .
python3 -c "from doc_mcp_server import markdown_to_pdf; print(markdown_to_pdf('# Hello', 'Test'))"MIT ā free for personal and commercial use.
Text format conversion and cleanup.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| to_lower | No | ||
| to_upper | No | ||
| strip_whitespace | No | ||
| remove_empty_lines | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It only states generic purpose and does not disclose behavioral traits like side effects or required permissions.
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?
Extremely short but underspecified. Not effectively concise; it lacks necessary detail.
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 5 parameters and an output schema (not detailed), the description is insufficient. It does not clarify what operations are possible or what outputs are returned.
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?
Schema description coverage is 0%, and the description does not explain any parameters. The agent must guess parameter meaning from names alone.
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?
Description is vague: 'Text format conversion and cleanup.' It does not specify what conversions or cleanup operations are performed, and it fails to distinguish from sibling tools like extract_pdf_text or count_words.
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?
No guidance on when to use this tool versus siblings. The description does not provide any context or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count words, characters, lines, and paragraphs.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses the core actions (counting different units), but does not mention details like handling of whitespace, encoding, or edge cases. Adequate for a simple tool 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's functionality without unnecessary words. It is front-loaded and easy to parse.
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?
Though an output schema exists, it is not shown. The tool is simple, but the description could add context about return format or scope (e.g., does it count whitespace as characters?). Overall, it is minimally complete but leaves 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 0% description coverage and the tool description adds no parameter information. The single parameter 'text' is self-explanatory from its name, but the description should clarify expected format (e.g., plain text) given the lack of schema descriptions.
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 'Count' and specifies the resources: words, characters, lines, and paragraphs. This distinguishes it from sibling tools like 'convert_text' or 'extract_pdf_text', which have different purposes.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for obtaining text statistics, but lacks when-not or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract text content from a PDF file.
Args: source: File path, URL, or base64 PDF content
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose behaviors like handling encrypted PDFs, page ranges, or performance limitations.
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 short and front-loaded, but could include more actionable detail without becoming verbose.
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 an output schema exists, return values are excused, but the description still lacks usage context and behavioral traits for a simple tool.
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?
Schema coverage is 0% but the description adds meaning beyond type string by specifying allowed inputs: file path, URL, or base64 content.
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 action 'Extract text content' and the resource 'PDF file', which is specific and distinct from sibling tools like generate_pdf or merge_pdfs.
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?
No guidance on when to use this tool versus alternatives (e.g., url_to_pdf, convert_text). It only implies use for extracting text from PDFs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a simple PDF from plain text content.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Document | |
| content | Yes | ||
| filename | No | output.pdf | |
| font_size | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'simple PDF from plain text', which hints at lack of formatting but does not disclose limitations, permissions, or side effects.
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?
Single sentence is concise but lacks necessary detail about parameters and constraints.
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?
Output schema exists but description does not clarify return format. Given 4 parameters, description is incomplete.
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?
Schema description coverage is 0%. Description does not explain any parameter beyond content. No mention of title, filename, or font_size meaning.
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?
Description clearly states verb 'generate', resource 'PDF', and input 'plain text content'. Distinguishes from siblings that use markdown or URL input.
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?
No explicit when-to-use or when-not-to-use guidance. The phrase 'simple PDF' implies basic use but does not mention alternatives or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert markdown text into a formatted PDF.
Supports: # headings, bold, - lists, 1. numbered lists,
code blocks, --- horizontal rules, paragraphs.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Document | |
| filename | No | output.pdf | |
| markdown | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only lists supported markdown features but omits behavioral details like error handling, performance, size limits, or whether it's synchronous. Minimal disclosure.
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?
Description is short and includes a bulleted list of supported features. It is efficient but could front-load the key verb and resource more prominently.
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?
Despite having an output schema (reducing need to describe return values), the description lacks usage guidelines, parameter explanations, and behavioral notes. For a 3-param tool, it is incomplete.
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?
Schema coverage is 0%, yet the description adds no information about the three parameters (title, filename, markdown). It merely describes the conversion process, leaving the agent to infer parameter purposes from names and defaults.
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 converts markdown to a formatted PDF, listing supported markdown elements. It distinguishes itself from sibling tools like convert_text, extract_pdf_text, and generate_pdf by specifying markdown as input.
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?
No guidance on when to use this tool versus alternatives (e.g., generate_pdf, url_to_pdf). No prerequisites, limitations, or context for optimal use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Merge multiple PDF files into a single PDF.
Args: sources: List of file paths, URLs, or base64 PDF contents
| Name | Required | Description | Default |
|---|---|---|---|
| sources | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It only states the merge action but does not mention whether sources are modified, how errors are handled, or any side effects. Output schema exists but is not described.
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?
Extremely concise with no unnecessary words. However, it is so short that it sacrifices completeness. Still, it is well-structured and front-loaded.
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 no annotations and one parameter, the description is somewhat minimal. Output schema exists but not explained. Could mention return type or constraints on input number/size. Nonetheless, it covers the core functionality.
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?
Schema coverage is 0%, but the description adds meaning by specifying that sources can be file paths, URLs, or base64 PDF contents. This is valuable beyond the empty schema schema.
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 action (merge) and the resource (multiple PDF files into a single PDF). It is specific and distinguishes itself from sibling tools like extract_pdf_text or generate_pdf.
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?
No guidance on when to use this tool vs alternatives. Does not mention limitations, prerequisites, or exclusions. For example, it could differentiate from pdf_metadata or extract_pdf_text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read metadata from a PDF file.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states 'Read metadata,' implying a read-only operation, but does not disclose any behavioral traits such as access requirements, error conditions, or side effects. Minimal transparency.
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 a single concise sentence that front-loads the core purpose. However, it is overly brief and sacrifices completeness for brevity.
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?
Despite having only one parameter and an output schema, the description is incomplete. It does not explain what metadata is returned, how the source file is referenced, or any edge cases. The output schema exists but is not described, leaving the agent without key context.
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?
Schema description coverage is 0%, and the description adds no meaning to the 'source' parameter beyond its type. No format, constraints, or example values are provided, leaving the agent with insufficient guidance for parameter usage.
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 'Read metadata from a PDF file' clearly states the verb (Read) and resource (metadata from a PDF file). It distinguishes this tool from its siblings (e.g., extract_pdf_text, merge_pdfs) by focusing on metadata rather than content extraction or file manipulation.
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?
No guidance on when to use this tool versus alternatives. The description lacks context for usage, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a web page URL and save its content as PDF.
Uses Jina AI reader to get clean markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| filename | No | webpage.pdf |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the use of Jina AI reader for clean markdown, but doesn't mention potential failures, rate limits, or internet dependency. Adequate but not exhaustive.
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?
Two focused sentences with no fluff. Front-loaded with the core action, followed by a relevant implementation detail.
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?
Tool is simple with 2 parameters and has an output schema. Description covers main functionality and underlying technology. Minor gap: doesn't explicitly state output is PDF based on markdown conversion or need for internet access.
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?
Schema coverage is 0%, so description must compensate. It implies 'url' is the web page URL and 'filename' is the output name, but lacks details like URL format or filename restrictions.
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 action: fetching a web page URL and saving its content as PDF. The verb 'fetch' and resource 'web page URL' are specific, and it distinguishes from sibling tools like generate_pdf or merge_pdfs.
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 implies usage for converting web pages to PDF but provides no explicit when-to-use or when-not-to-use guidance, nor mentions alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0convert_textcount_wordsextract_pdf_textgenerate_pdfmarkdown_to_pdfmerge_pdfspdf_metadataurl_to_pdfEach tool has a clearly distinct purpose: text conversion, word counting, PDF extraction, PDF generation (two variants), PDF merging, metadata reading, and URL-to-PDF conversion. No two tools have overlapping functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., convert_text, extract_pdf_text, merge_pdfs). The naming is predictable and easy to understand.
With 8 tools covering text conversion, word counting, and various PDF operations (extraction, generation, merging, metadata, URL conversion), the count is well-scoped for a document processing server.
Missing some common operations like converting PDFs to other formats or editing PDF content, but the set is complete for core document tasks (create, read, merge, convert, and get metadata).
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.
Convert PDF, DOCX, HTML, and URLs to clean, LLM-ready markdown with tables preserved
Read a URL as clean markdown, screenshot a website, url to PDF. Web access for agents, no signup.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ceeyang-ai/doc-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
