I Built a Read-Only MCP Server for Japanese LaTeX Documents

I wanted to give an AI a source document and say something ordinary like:

Turn this into a B5 Japanese lecture note. Keep the definitions precise, add two worked examples, compile it, and show me the finished pages.

The difficult part was not persuading the model to emit LaTeX. The difficult part was making the whole workflow repeatable: choosing a document structure, keeping Japanese typesetting stable, checking that every exercise has an answer, compiling locally, reading the log, and inspecting the rendered pages.

So I built TeX64, a free, open-source MCP server that gives Claude and Codex a reusable Japanese LuaLaTeX document system. (The repository retains the project's original texmcp name.)

This is an example of the output produced from one natural-language request:

The design: guidance on the server, execution on your machine

TeX64 is intentionally not a remote LaTeX compiler. Its six public tools are read-only. They return style files, document rules, scaffolds, checks, known issues, and compilation instructions as text. One of those tools, check_document, receives the .tex source for transient structural processing; the service does not persist it. Compilation and generated files stay on the client machine.

The connected AI client does the stateful work on your machine:

Your request
    ↓
Claude or Codex
    ↓  reads styles, rules, and scaffolds through MCP
TeX64 (read-only, stateless)
    ↓
Claude or Codex writes .tex/.sty files locally
    ↓
Local TeX Live compiles the PDF
    ↓
The agent renders pages to images, inspects them, and repairs problems

This split is important. A hosted service does not need permission to write into your project or run arbitrary TeX jobs. Meanwhile, the AI can use the tools it already has for editing files, running latexmk, reading logs, and checking page images.

What the MCP server provides

TeX64 currently exposes six tools:

Tool	What it returns
get_style_files	Japanese study-note or report styles, an annotated skeleton, and design notes
doc_types	Six document structures and their editing rules
scaffold_document	A compilable .tex scaffold for the selected document type
check_document	Structural checks, such as problem/answer pairing and numbering
known_issues	A searchable list of troublesome LuaLaTeX, jlreq, and LuaTeX-ja combinations
compile_guide	A local build, repair, and visual-inspection procedure for the AI agent

The six document types are lecture notes, exam summaries, exercise sets, past-exam collections, language notes, and compact short-answer sheets. Each type defines an expected section order, editing rules, automatic checks, and items that still require visual or human review.

For example, an exercise set is expected to place each solution immediately after its problem, number problems without gaps, state the relevant formulas before the questions, and include the important intermediate steps rather than only final answers.

Install it in one command

You do not need to clone the repository or install an npm package to use the hosted server.

For Claude Code:

claude mcp add --transport http tex64 https://mcp.tex64.com/

For Codex:

codex mcp add tex64 --url https://mcp.tex64.com/

If you prefer to edit the Codex configuration directly, add this to ~/.codex/config.toml:

[mcp_servers.tex64]
url = "https://mcp.tex64.com"

The public endpoint does not require an account or API key.

These commands were verified with Claude Code 2.1.227 and Codex CLI 0.145.0 on August 14, 2026. Check the current client documentation if a future CLI release changes its MCP syntax.

Local requirements

The machine running your AI client needs:

• TeX Live with lualatex and latexmk
• an agent that can write project files and run local commands
• optionally, Poppler's pdftoppm for turning PDF pages into images for visual inspection

TeX64 uses LuaLaTeX because Japanese documents need more than a generic pdflatex template. Its styles account for Japanese fonts, line breaking, page geometry, headings, boxes, and the interactions among jlreq, LuaTeX-ja, TikZ, and related packages.

Harano Aji is the safest font choice when portability matters because it is distributed with TeX Live. Other included profiles cover Hiragino, Yu, BIZ UD, Source Han, and IPAex fonts.

A complete first request

After connecting the server, try a prompt like this:

Create a B5 Japanese lecture note titled
「リーマン積分の定義と可積分条件」 from the material I provide.

Use the TeX64 lecture-note structure and the Harano Aji font profile.
Include the definitions before they are used, two worked examples,
and a short review section.

Save the source in a new local project, run the structural checks,
compile it with LuaLaTeX, render the pages to images, inspect the cover,
Japanese glyphs, headings, boxes, margins, and page breaks, and repair
any problems before showing me the PDF and previews.

The wording is deliberately about the document you want, not about internal style commands. The MCP tools give the agent the specialized implementation details.

Here is a content page from the resulting document:

And here is a page combining a theorem-style box, a warning, and a worked exercise:

Why structural checks matter

A PDF can compile successfully and still be a bad study document.

LaTeX will not tell you that problem 4 has no solution, that the numbering jumps from 6 to 8, that a formula is used before its variables are defined, or that an OCR-based language note no longer matches its sentence-by-sentence commentary.

check_document treats those as document-structure problems. The check is separate from compilation because a TeX engine and an editorial rule checker answer different questions:

• Compilation: Is this valid TeX, and can it produce a PDF?
• Structural checking: Does the document follow the rules of its intended form?
• Visual inspection: Are glyphs, boxes, margins, headings, and page breaks actually correct on the rendered page?

TeX64's workflow requires all three.

Privacy and security boundaries

The public tools are annotated as read-only, non-destructive, and idempotent. The server does not write files, run LaTeX, or retain prompts, document source, generated files, or tool results. Infrastructure providers may still process transient network and security metadata needed to operate the service; see the privacy policy and terms of use.

There is one boundary worth stating precisely: when the client calls check_document, it sends the .tex source to the server for transient structural processing. The service does not persist it, but you still should not submit secrets or sensitive personal information. Compilation and generated files remain on the client machine.

You can also self-host the MIT-licensed server and enable bearer-token authentication if you need to control access.

Current limitations

TeX64 is deliberately opinionated:

• It focuses on Japanese study materials and simple academic reports.
• It requires a local TeX installation; the hosted server does not return a compiled PDF.
• Its automatic checks cover known structural rules, not mathematical correctness.
• Visual inspection is still required. A zero-error log is not proof of a good page.
• The quality of the result depends on the connected agent actually following the compile-and-review loop.

That narrow scope is useful. Instead of trying to be a general document generator, TeX64 supplies a concrete system for one difficult class of documents and leaves the final execution visible and editable on the user's machine.

The source and self-hosting instructions are available on GitHub. The hosted endpoint is https://mcp.tex64.com/.

If you create Japanese notes with LaTeX, which document type should I add next?