Pressa - LaTeX to PDF

Name: Pressa - LaTeX to PDF
Author: pressa-dev

Server Details

Compile LaTeX to PDF without installing TeX Live. No API key needed to start.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.9% over 42 days
Last Tested: 2026-11-02 20:52
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: pressa-dev/mcp
GitHub Stars: 0
Server Listing: @pressa/mcp

TDQS

A4.4/5.0

Scored 2026-10-29 18:10 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct role: `compile` for user-authored LaTeX, `list_public_templates` for discovery, `get_public_template` for schema/source retrieval, and `render_public_template` for data-filling. The only potential overlap — compile vs. render both producing a PDF — is explicitly disambiguated in the descriptions ('edit the source and use compile' vs. 'pass the data to render_public_template').

Naming Consistency4/5

Three of four tools follow a clean verb_noun pattern with a shared `public_template` noun (list/get/render). `compile` is a bare verb, which is readable and natural here but breaks the otherwise consistent convention.

Tool Count5/5

Four tools is exactly the right size for a focused LaTeX-to-PDF service: one compile primitive plus a three-tool template workflow. No tool feels redundant or missing from the set.

Completeness4/5

The core lifecycle (discover template → read schema/instructions → render, or compile your own source) is fully covered with no dead ends. Minor gaps exist, such as no way to validate data without producing a PDF or to browse previously generated documents, but these are workable around.

Available Tools

4 tools

compileCompile LaTeX to PDFAInspect

Compile LaTeX source into a PDF. Returns a PDF URL, page count and compile time.

USE THIS WHEN: you have LaTeX source (or a \documentclass) and no local pdflatex / TeX Live installation to run it with. This is that missing compiler, available over HTTP. Also use it whenever the user asks for a document where typesetting matters - an invoice, contract, report, letter, CV, certificate, or academic paper - since you can write the LaTeX yourself and compile it here.

DO NOT USE THIS TO: convert HTML to PDF, merge, split or compress existing PDF files, or extract text from a PDF. This compiles LaTeX source and nothing else.

No API key is required. Anonymous callers get a small number of compilations per day and failed attempts do not count, so you can iterate on your LaTeX for free. Send an API key in the Authorization header to raise the limits. With a key, a document over the plan's page or size limit still returns a PDF: preview: true, the first pages the plan allows, total_pages, and plan_required naming the plan that covers the whole document. Show the user the preview and relay warning; never drop pages silently.

IMPORTANT: This tool compiles LaTeX, NOT plain text. You must generate complete, valid LaTeX source yourself before calling it. Do not pass plain text, markdown or JSON directly - convert them to LaTeX first, and never ask the user to write LaTeX.

A minimal valid document is: \documentclass{article}\begin{document}\end{document}. Escape these in body text: % & $ # _ { } and backslash.

If compilation fails the response includes a diagnosis naming the cause and a concrete suggested fix, often a missing \usepackage. Apply it and call again yourself rather than showing the user a TeX log.

Name	Required	Description	Default
`latex`	Yes	Complete LaTeX source, including \documentclass and \begin{document}...\end{document}.
`compiler`	No	Defaults to pdflatex. Use xelatex for fontspec or for Chinese, Japanese and other non-Latin scripts. lualatex needs a Pro or Business plan.

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint false, openWorld true, idempotent false): it discloses the anonymous daily quota, that failed attempts don't count, how API keys raise limits, and the exact over-limit behavior (preview PDF, total_pages, plan_required, warning that must be relayed rather than silently truncating). It also states that failures return a `diagnosis` with a suggested fix and instructs the agent to retry itself instead of surfacing a TeX log — precisely the behavioral context annotations cannot carry.

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?

Long but front-loaded and sectioned with uppercase headers, so the agent can scan purpose, when, when-not, auth/pricing, and failure handling independently. Each paragraph carries actionable information (escaping rules, retry-on-diagnosis, preview relaying) rather than restating the name or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by naming the return fields (PDF URL, page count, compile time) plus the conditional preview/plan_required shape and the diagnosis-on-failure shape. Combined with the auth and quota model, an agent has everything needed to call it, handle failure, and report results correctly.

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

Parameters4/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 (including the compiler enum guidance). The description still adds non-obvious semantics: the `latex` argument must be complete, valid source the agent generates itself, with the escaping rule for % & $ # _ { } and backslash. It does not repeat the per-compiler guidance already in the schema, which is fine.

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 first sentence states a specific verb and resource (compile LaTeX source into a PDF) plus the return values. It draws a hard boundary against the nearest confusable operations (HTML-to-PDF, merge/split/compress, text extraction), so an agent can distinguish it from any document sibling without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit three-part routing: 'USE THIS WHEN' names both the trigger (you have LaTeX source or a \documentclass and no local TeX install; or the task is a typeset-matters document like an invoice, contract, CV) and 'DO NOT USE THIS TO' names the excluded cases with the alternative family for each. Nothing is left to inference.

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

get_public_templateFetch one public templateA

Read-onlyIdempotent

Inspect

Get a public template's fields (JSON schema), sample data, filling instructions and LaTeX source. Read the instructions before collecting data from the user. To make the PDF, pass the data to render_public_template; to change the layout itself, edit the source and use compile.

Name	Required	Description	Default
`template`	Yes	Template slug from list_public_templates, e.g. classic-resume.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered; the description adds the useful workflow trait that instructions must be read before data collection. It does not mention failure behavior for an unknown slug, keeping it below 5.

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 tight sentences, front-loaded with the return contents and followed by routing guidance. Every clause carries actionable information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by enumerating exactly what the response contains. Combined with the sibling routing, an agent has everything needed to call this correctly.

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?

The single 'template' parameter is fully documented in the schema with a slug example and a pointer to list_public_templates, so the schema does the heavy lifting. The description adds no further parameter semantics beyond what the schema provides, so the baseline 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?

A specific verb and resource paired with the full list of what is returned (JSON schema fields, sample data, filling instructions, LaTeX source). It is clearly distinct from list_public_templates (enumerate) and render_public_template (produce PDF).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: read instructions before collecting data, use render_public_template to make a PDF, and edit the source plus compile to change layout. When-to-use and named alternatives are both present.

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

list_public_templatesBrowse Pressa's public document templatesA

Read-onlyIdempotent

Inspect

List Pressa's public, professionally designed document templates (invoices, purchase orders, packing slips, delivery notes, receipts, reports, certificates, resumes, CVs, cover letters), each with a one-line summary, a preview image URL and the colours it comes in. Several designs of one document (document, e.g. five resume designs) take the same data. Use this when the user wants one of these documents and has no layout of their own, or asks to see designs to choose from. Works without an API key.

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds genuinely new context: what each result contains (one-line summary, preview image URL, colour variants), that multiple designs of one document share the same data shape, and that it works without an API key — a real auth disclosure. It stops short of saying whether the list is paginated or how large it is.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with verb and resource, then the routing condition. The long parenthetical document-type list is the only bloat, but it earns its place by giving the agent vocabulary to match user requests.

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?

With no output schema, the description usefully compensates by describing the per-item fields and the shared-data relationship across designs. Only the total result size / pagination behavior is unstated, which is a minor gap for a zero-argument list tool.

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

Parameters4/5

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly frames this as a no-argument browse operation rather than implying filters exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('List') plus resource ('Pressa's public document templates') with a concrete enumeration of the template types returned. The listing behavior is distinguishable from get_public_template and render_public_template by implication, though the description never names those siblings to make the routing explicit.

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?

It states a clear selection condition: use when the user wants one of these documents and has no layout of their own, or wants to browse designs. It does not name the alternatives (get_public_template for a single design, render_public_template to produce output), so the 'when-not' half is left to inference.

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

render_public_templateFill a public template and get a PDFAInspect

Fill a public template with the user's data and return a PDF link. Data must match the template's schema (see get_public_template); a missing field comes back as a list of what to ask for, and costs nothing. The designs of one document take the same data (the five resume designs, as do the packing slip and the delivery note), so switching design is the same call with a different slug, and color prints a design in another of its colours. Works without an API key within the daily free limit.

Name	Required	Description
`data`	Yes	Values for the template's fields.
`color`	No	Optional: one of the template's colours (list_public_templates), e.g. navy. Left out, the default.
`template`	Yes	Template slug, e.g. modern-resume.

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false), the description discloses the return value (a PDF link), the failure mode (missing fields return a list of what to ask for at no cost), cross-design data portability, and the API-key/rate-limit situation. That is exactly the kind of behavior an agent can't infer from annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in sentence one and every sentence carries information. The middle sentence is dense and runs together design equivalence, colour variants, and the reason switching is cheap, which makes it slower to parse than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by describing both the success return (PDF link) and the failure return (list of missing fields, free of charge). With three fully documented parameters and a clear rendering workflow, an agent has everything needed to call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description adds real meaning by saying `data` must satisfy the template's schema from get_public_template and is portable across designs of the same document. It also restates the `color` behavior, which the schema already covers, so the gain is modest rather than decisive.

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 first sentence names a specific verb (fill), a specific resource (public template), and the concrete outcome (a PDF link). It also implicitly separates itself from the sibling readers by pointing at get_public_template and list_public_templates for their respective jobs.

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?

It gives a clear prerequisite chain: fetch the schema via get_public_template before calling, and fetch colours via list_public_templates. It also explains the design-switching pattern (same call, different slug) and the no-API-key free-limit condition. It never states when to prefer the sibling `compile` instead, so it stops short of full alternatives coverage.

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 tool updateOct 22, 2026

Changedcompile1 field changed

changedInput schema / properties / compiler / description

Previous value: -"Defaults to pdflatex. Anonymous callers may only use pdflatex."New value: +"Defaults to pdflatex. Use xelatex for fontspec or for Chinese, Japanese and other non-Latin scripts. lualatex needs a Pro or Business plan."

1 tool updateOct 18, 2026

Changedrender_public_template1 field changed

addedInput schema / properties / color

Added value: +{
+  "description": "Optional: one of the template's colours (list_public_templates), e.g. navy. Left out, the default.",
+  "type": "string"
+}

3 tool updatesSep 25, 2026
- Addedget_public_template
- Addedlist_public_templates
- Addedrender_public_template
1 tool updateSep 22, 2026
- First observedcompile

Related MCP Connectors

LetX A
app.letx
A hosted LaTeX editor your assistant can actually use. Search 1,019 free templates, create and edit projects, and compile them to PDF on a real TeX Live farm, getting back the PDF or the compile log when a build fails. Thirteen tools behind OAuth 2.1, with nothing to install and nothing to run locally.
Education & Learning Tools Workplace & Productivity
131
https://api.letx.app/mcp
Samskrift
com.samskrift
Collaborative LaTeX editor: edit, compile and share PDFs, with full version history.
Workplace & Productivity Content Management Systems Version Control
1
https://samskrift.com/mcp
latex
app.ofia
Persistent AI LaTeX workspace: edit and compile multi-file projects, export publication-ready PDFs.
Workplace & Productivity Developer Tools Research & Data
2
https://ofia.app/api/mcp
oJo — HTML to image and PDF
so.ojo
Fill an HTML template with JSON and get a hosted PDF or image link. Free previews, no key.
Image & Video Processing Multimedia Processing Developer Tools
1
https://mcp.ojo.so/mcp

Related MCP Servers

OverleafSkill MCP
Developer Tools Version Control Workplace & Productivity
yunyangge
A
license
Not graded
quality
B
maintenance
Enables AI assistants to read and precisely edit LaTeX projects, review diffs, sync with Overleaf and GitHub, and compile locally or online with returned PDFs and diagnostics.
Updated 3 days ago (2026-10-30 15:15 UTC)
MIT
MagicTeX MCP Server
Developer Tools File Systems Workplace & Productivity
ZoeLinUTS
A
license
A
quality
B
maintenance
Enables AI agents to edit LaTeX documents with a live PDF preview, source editor, and PDF-anchored comments that become edit instructions. Requires no local TeX install, using a WASM TeX engine.
Updated 2 days ago (2026-10-31 15:32 UTC)
7
119 npm
4
AGPL 3.0
resume-pdf-mcp
Documentation Access File Systems Code Execution
shashimehta03
A
license
B
quality
D
maintenance
Compiles LaTeX resumes into PDFs via MCP tools, including validation, preview, template compilation, and LaTeX export, with security defaults like path isolation and no shell escapes.
Updated 3 months ago (2026-08-03 19:28 UTC)
7
MIT
docwriter-mcp-server
Developer Tools Documentation Access
cyanheads
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server for programmatic creation, modification, and compilation of structured LaTeX documents.
Updated a year ago (2025-07-22 08:14 UTC)
8 npm
3
Apache 2.0

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources