Skip to main content
Glama
marcelogdomingues

mcp-latex

by marcelogdomingues
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

mcp-latex

A Model Context Protocol (MCP) server for LaTeX. Give an AI assistant (Claude Desktop, Claude Code, Cursor…) the ability to check your LaTeX document, parse compiler logs, and compile — so it can actually fix your thesis or paper instead of guessing. Static analysis works with no TeX install required.

🌍 English · Português · 📚 Documentation

CI npm License: MIT MCP

Tools

Tool

Description

check_document

Static analysis: undefined refs, duplicate/unused labels, unbalanced environments; lists labels/refs/citations. No TeX needed.

parse_log

Turns a .log into structured errors, warnings, undefined refs/citations, over/underfull boxes.

compile

Compiles a .tex with latexmk/pdflatex if installed; returns parsed errors (graceful if no engine).

Related MCP server: Overleaf MCP

Use with Claude Desktop / Claude Code

{
  "mcpServers": {
    "latex": { "command": "npx", "args": ["-y", "mcp-latex"] }
  }
}

Then ask: "Check my thesis for undefined references and unbalanced environments," or "Compile main.tex and fix the first error."

Why

Writing a thesis in LaTeX means fighting cryptic compiler errors, dangling \refs and \begin/\end mismatches. An AI assistant is great at fixing these — if it can see the actual errors. This server gives it structured eyes on your document. Built from the pain of writing a real master's thesis.

Run locally

npm install
npm start          # stdio server
npm test           # unit + stdio integration tests
npm run build      # tsc -> dist/

Try it with the MCP Inspector:

npx @modelcontextprotocol/inspector npx -y mcp-latex

License

MIT © Marcelo Domingues

Available Tools

3 tools
check_documentCheck LaTeX documentA

Static analysis of LaTeX source: finds undefined references, duplicate/unused labels, and unbalanced environments. Lists labels, references and citations. Works without a TeX install.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoPath to a .tex file (used if source is omitted)
sourceNoLaTeX source to analyze

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral disclosure burden. It explicitly labels the operation as 'static analysis', signaling no side effects or compilation, and lists what it finds. It does not detail the exact output format or whether any files are written, but 'static analysis' strongly implies read-only behavior, which is adequately transparent.

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 two concise sentences with no redundancy. It front-loads the core purpose ('static analysis of LaTeX source'), then efficiently enumerates specific findings and a key practical detail (no TeX install required). Every word earns its place.

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?

The description covers purpose, capabilities, and operating constraints for a simple 2-parameter tool. It omits an explicit return format, but no output schema exists, and the listed outputs ('lists labels, references and citations') give adequate context for an agent to understand what to expect.

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 coverage is 100%, with clear descriptions for both 'path' and 'source'. The tool description adds no extra details about parameter semantics or relationships beyond what the schema already provides, so the baseline score of 3 applies.

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 performs static analysis of LaTeX source, listing specific checks (undefined references, duplicate/unused labels, unbalanced environments) and outputs (labels, references, citations). It distinguishes itself from siblings 'parse_log' and 'compile' by focusing on source analysis rather than log parsing or compilation.

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 implies when to use the tool (for checking LaTeX source without compiling) and adds a useful constraint ('works without a TeX install'). However, it does not explicitly compare with sibling tools or state when not to use it, missing a stronger usage guideline.

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

compileCompile LaTeXA

Compiles a .tex file with latexmk/pdflatex if a TeX engine is installed, and returns parsed errors. Returns available:false with guidance if no engine is found.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesPath to the .tex file to compile
engineNoPreferred engine (default latexmk)

TDQS

A4/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 burden. It discloses fallback behavior (available:false) and error parsing, but omits potential file system side effects of compilation and any permission requirements.

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, front-loaded with purpose, no wasted words. The description is concise yet informative.

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 no output schema and no annotations, the description covers core behavior and the no-engine fallback. The return value beyond 'parsed errors' is somewhat vague, but adequate for a straightforward compile tool.

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 coverage is 100%, so both parameters are already documented. The description adds no significant parameter semantics beyond what the schema provides; it merely references the engines already enumerated.

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 states the tool compiles .tex files with latexmk/pdflatex and returns parsed errors. It clearly distinguishes from sibling tools check_document and parse_log, which cover different stages.

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 implies use for compiling TeX files and notes the conditional behavior based on engine availability, but does not explicitly state when to prefer this over siblings or when not to use it. Still, the context is clear.

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

parse_logParse LaTeX logA

Parses a LaTeX .log file into structured errors, warnings, undefined references/citations, and over/underfull box counts.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoPath to a .log file (used if logContent is omitted)
logContentNoContents of a .log file

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the transparency burden. It clearly indicates a read-only parsing operation, which is safe and non-destructive. However, it does not disclose behavior for invalid input, missing files, or other edge cases, limiting transparency.

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, front-loaded sentence with no wasted words. It efficiently conveys the tool's action and expected outcomes.

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?

The tool is simple: two parameters, no output schema. The description covers the input source and the high-level result categories. It avoids detailing the exact output structure, which is acceptable for a parser, but it could mention error handling or prerequisites for full completeness.

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 coverage is 100%—both parameters (path and logContent) have descriptions. The tool description adds no extra parameter-level meaning, so the baseline score of 3 is appropriate.

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 action ('Parses a LaTeX .log file') and the specific outputs (errors, warnings, undefined references/citations, over/underfull box counts). This distinguishes it from sibling tools like compile (which builds documents) and check_document (which likely checks structure).

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?

No explicit when-to-use or alternatives are provided, but the purpose implies this should be used when you have a .log file and need structured diagnostics. The guidance is implied, not explicit, and there are no exclusions or prerequisites mentioned.

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. 3 tool updatesv0.1.0
    • First observedcheck_document
    • First observedcompile
    • First observedparse_log
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 3 tools

Disambiguation4/5

The three tools are largely distinct: check_document performs static analysis, parse_log consumes a log file, and compile invokes an external engine. There is minor overlap in that both check_document and parse_log can report undefined references/citations, but the input source (source file vs. log file) clarifies the intended use.

Naming Consistency4/5

Two tools use the verb_noun pattern (check_document, parse_log), while compile uses a bare verb. This is a minor deviation from an otherwise consistent naming style, but the intent is still clear.

Tool Count5/5

With only 3 tools, the server is well-scoped for LaTeX document validation and compilation. Each tool serves a distinct and necessary function without redundancy or bloat.

Completeness4/5

The toolset covers the core workflow of checking source, compiling, and parsing logs. Minor gaps exist, such as no tool for cleaning auxiliary files or managing bibliographies, but these are not essential for the server's stated purpose.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • latexmk-mcp

    coolport
    A
    license
    A
    quality
    D
    maintenance
    An MCP server that exposes LaTeX compilation, log parsing, dependency inspection, and citation checking as tools for AI agents, using latexmk under the hood.
    11
    11 npm
    1
    MIT

  • latex-mcp

    san-rat
    A
    license
    Not graded
    quality
    B
    maintenance
    An MCP server that enables LLMs to compile LaTeX documents and inspect the resulting PDF, supporting an autonomous write-compile-check-revise loop via a self-hosted Overleaf CLSI instance.
    MIT