Skip to main content
Glama
tobioffice

LaTeX PDF MCP Server

by tobioffice
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

LaTeX PDF MCP Server

MCP

A Model Context Protocol server that converts LaTeX source code into PDF documents using a local LaTeX distribution. It lets AI assistants generate professional, typeset PDFs - academic papers, reports, resumes - from LaTeX markup.

Features

  • LaTeX to PDF conversion via latexmk -pdf

  • Full LaTeX support: math, tables, figures, bibliographies, cross-references

  • Configurable output directory through LATEXPDF_OUTPUT_DIR

  • Download links for generated PDFs (served over local HTTP)

  • Detailed error reporting for LaTeX compilation failures

Related MCP server: MCP LaTeX Server

Prerequisites

  1. Node.js 18 or higher

  2. A LaTeX distribution with latexmk available on your PATH:

Installation

From npm

npm install -g latexpdf-mcp

From source

git clone https://github.com/tobioffice/LateXPDF-MCP.git
cd LateXPDF-MCP
pnpm install
pnpm run build

Configuration

Claude Desktop

Config file locations:

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

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

  • Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "latexpdf-mcp": {
      "command": "latexpdf-mcp",
      "env": {
        "LATEXPDF_OUTPUT_DIR": "/path/to/your/pdf/directory"
      }
    }
  }
}

Environment variable

Default

Description

LATEXPDF_OUTPUT_DIR

C:\Users\Admin\Documents\GeneratedPDF

Directory where the generated .tex and .pdf files are written

Always set LATEXPDF_OUTPUT_DIR to a directory that exists on your machine. When using Windows paths in JSON, escape the backslashes (C:\\Users\\YourName\\PDFs).

Usage

Tool: create_pdf

Parameter

Type

Required

Description

file_name

string

yes

Output file name, must end with .pdf

latex_source

string

yes

LaTeX source code to compile

Example LaTeX source:

\documentclass{article}
\usepackage[utf8]{inputenc}
\title{Sample Document}
\author{Your Name}
\date{\today}

\begin{document}
\maketitle

\section{Introduction}
This is a sample LaTeX document generated via MCP.

\subsection{Features}
\begin{itemize}
  \item Professional formatting
  \item Mathematical expressions: $E = mc^2$
  \item Cross-references and citations
\end{itemize}

\end{document}

The tool returns the output file name and a download link:

File Name: report.pdf

PDF Download LINK: http://localhost:8000/report.pdf

Accessing generated PDFs

Serve the output directory over HTTP and open the link:

python -m http.server 8000 --directory "$LATEXPDF_OUTPUT_DIR"

Development

pnpm run build   # compile TypeScript to dist/
pnpm run watch   # compile in watch mode

Project structure

LateXPDF-MCP/
├── index.ts              # MCP server implementation
├── package.json          # Package configuration
├── tsconfig.json         # TypeScript configuration
└── scripts/
    └── update-version.js # Syncs the version string in index.ts

Troubleshooting

  • latexmk not found - make sure your LaTeX distribution is installed and on your PATH

  • Permission errors - check write access to LATEXPDF_OUTPUT_DIR

  • Compilation failed / no output PDF - check the LaTeX source for errors and missing packages

  • Invalid input - file_name must end with .pdf

License

MIT (as declared in package.json).

Available Tools

1 tool
create_pdfB

Creates a PDF document from the provided LaTeX source code.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_nameYesThe name of the output PDF file (must end with .pdf)
latex_sourceYesThe LaTeX source code to convert into a PDF document.

TDQS

B3.4/5.0
Behavior2/5

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 states the tool creates a PDF, implying a write operation, but doesn't mention any behavioral traits like error handling, performance characteristics, dependencies, or what happens if the LaTeX compilation fails. This leaves significant gaps for an agent to understand how the tool behaves.

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 a single, well-structured sentence that directly states the tool's purpose without any redundant information. It is front-loaded and every word earns its place, making it highly efficient.

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 complexity of a PDF creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., success/failure, file path, errors), how to handle LaTeX compilation issues, or any system dependencies. This leaves critical context gaps for an agent to use the tool effectively.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents both parameters (file_name and latex_source). The description adds no additional parameter semantics beyond what the schema provides, such as LaTeX version compatibility or file naming constraints. This meets the baseline for high 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 clearly states the specific action ('Creates a PDF document') and the resource ('from the provided LaTeX source code'), with no sibling tools to differentiate from. It uses precise technical language that leaves no ambiguity about what the tool does.

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 context (converting LaTeX to PDF) but provides no explicit guidance on when to use this tool versus alternatives, prerequisites, or limitations. Since there are no sibling tools, this is adequate but lacks depth.

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

Tool Schema Changelog

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

  1. 1 tool updatev0.5.5
    • First observedcreate_pdf
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.4/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'create_pdf' has a clear and distinct purpose, making it impossible for an agent to misselect among alternatives.

Naming Consistency5/5

The single tool name 'create_pdf' follows a clear verb_noun pattern (create + pdf), which is consistent and predictable. Since there is only one tool, there is no inconsistency to evaluate, and the naming convention is straightforward.

Tool Count2/5

A single tool is generally too few for a server's purpose, as it limits functionality and may indicate an incomplete or overly narrow scope. For a LaTeX PDF server, one tool feels thin and inadequate for covering potential operations like editing, compiling, or managing PDFs.

Completeness2/5

The tool surface is severely incomplete for a LaTeX PDF domain. While 'create_pdf' handles PDF generation, there are obvious gaps such as editing LaTeX source, compiling with options, managing templates, or viewing PDFs, which will likely cause agent failures in broader workflows.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers