The MagicTeX-mcp server allows AI agents to collaboratively manage, edit, and review LaTeX documents with real‑time compilation and version control.
Render Live Preview: Compile LaTeX to PDF using various engines (pdflatex, xelatex, lualatex) and backends, returning a preview URL and compile status/errors.
Visual Diffs: Generate side‑by‑side diff images of changes between auto‑saved checkpoints or uncommitted edits.
List Checkpoints: Access recent auto‑saved checkpoints with SHA, timestamp, and file/line‑change statistics.
Check PDF Comments: List user‑accepted comments from the rendered PDF, each with source location, quoted passage, and instruction.
Resolve Comments: Mark a comment as resolved after making the requested edit, attaching a note.
Add Review Comments: Post a new comment anchored to a specific passage, optionally as a suggestion for human approval or immediately actionable.
Reply to Threads: Reply to existing comment threads for clarification or pushback.
All work is done locally for privacy, with AI features leveraging the Model Context Protocol (MCP).
Provides tools for editing LaTeX documents with live PDF preview, git version tracking, and visual editing capabilities.
Click on "Deploy 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., "@MagicTeX-mcp edit the introduction to include the new hypothesis"
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.
Please visit the release page to download
MagicTeX brings a modern interface to your academic writing. It connects your documents to AI assistants like Claude, allowing you to focus on your research while the software handles the formatting. You no longer need to install complex local TeX systems or manage difficult software environments. MagicTeX does the heavy lifting for you through an automated connection.
Follow these steps to set up MagicTeX on your Windows computer.
Prepare your computer: Ensure you have an active internet connection. You need roughly 200 MB of free storage space for the application files.
Visit the website: Go to the official MagicTeX download page.
Choose the file: Locate the most recent version in the list. Look for the file ending in .exe that fits your Windows system.
Download: Click the filename to save the installer to your computer.
Run the file: Open the folder where you saved the installer. Double-click the file to start the installation process. Follow the instructions on your screen.
Open the app: Once finished, look for the MagicTeX icon on your desktop or in your start menu. Click the icon to launch the software.
Related MCP server: Unofficial Overleaf MCP Server
MagicTeX provides tools to simplify how you write and edit research papers.
You see your changes in real time. As you type code or interact with the visual interface, the PDF updates on the right side of your screen. This removes the need to constantly compile your document.
You can leave comments directly on your PDF preview. The AI agent reads these comments and applies the requested changes to the underlying LaTeX code. If you want to change a section or update a reference, simply highlight the area and type your note.
If you prefer not to write raw code, use the Visual mode. This acts like a standard word processor. You make changes to the text, and MagicTeX translates those edits into correct LaTeX formatting behind the scenes.
Never lose your work. MagicTeX tracks every version of your document automatically. You can view your progress over time or revert to a previous version of your paper if you change your mind about an edit.
The software acts as a bridge for AI agents. It uses the Model Context Protocol (MCP) to let your AI assistant look at your files, understand your bibliography, and help you structure your document.
Windows 10 or 11
4 GB of RAM
200 MB of hard drive space
Stable internet connection for AI features
MagicTeX organizes your research projects into folders. When you start a new document, the software creates a project file. This file contains your text, your images, and the history of your changes. You can move these folders to any safe location on your computer, such as your Documents or OneDrive folder.
Your documents reside on your local machine. MagicTeX does not upload your private research to cloud servers unless you explicitly ask an AI agent to help with your text. Even then, only the specific text you highlight is sent to the AI service. The rest of your document stays private on your local drive.
If the software fails to open, check the following points:
Check for updates: Ensure you downloaded the latest version from the repository.
Permissions: You might need administrator rights to install the software if your computer restricts new installations.
Connection errors: If the AI features stop working, check your internet connection and verify that your AI account status is active.
Library conflicts: This software does not require a local TeX install. If you have an old program like MiKTeX or TeX Live installed, MagicTeX will ignore those, so you do not need to uninstall them.
When a new version becomes available, you simply download the new installer from the same release page. Install the program again. The new version will overwrite the old one and keep your saved project folders intact. You do not lose any data by updating the software.
Do I need to know how to code to use this? No. While MagicTeX handles LaTeX code, the visual interface allows you to write papers without looking at the raw code.
Does this work offline? You can write and edit your documents while offline. However, the AI features, such as smart edits or complex formatting requests, require an active connection to the internet.
Can I export my files? Yes. Since all files remain in your local project folder, you can copy them and open them in any standard LaTeX editor if you eventually choose to move away from MagicTeX.
Is my data tracked? The software does not collect your personal data. All tracking and history features operate locally on your computer.
Keywords: academic-writing, ai-agent, ai-agents, claude, claude-code, latex, latex-editor, llm, mcp, mcp-server, model-context-protocol, overleaf-alternative, pdf-preview, research-tools, texlive, wysiwyg-editor
Post a review comment anchored to a passage of the paper — for a reviewer agent marking up the document. Give the exact quoted text from the compiled paper (or the source prose) it refers to, and your comment/instruction. By default it is created as a suggestion the human accepts in the workspace before the author loop acts on it; pass accepted:true only in fully-autonomous ("copilot") mode to make it immediately actionable. Use this to leave many targeted comments rather than one long critique.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | PDF page the passage is on, if known (default 1; the workspace re-anchors by text anyway). | |
| role | No | Your role: "reviewer" (default) critiques and asks for changes; "defender" stress-tests claims / pushes back. | |
| quote | Yes | The exact passage the comment is about (a sentence or phrase from the paper). | |
| comment | Yes | The review comment or revision instruction for this passage. | |
| accepted | No | Autonomous mode: create it already accepted (actionable) instead of a suggestion awaiting the human. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses key behavioral traits: the default is a suggestion requiring human acceptance, and accepted:true is for autonomous mode only. It also adds the nuance that the author loop acts only after human acceptance. This goes beyond the schema's parameter description, which focuses only on the accepted field's mechanics.
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 four sentences long, front-loaded with the core purpose, and every sentence contributes value. It avoids fluff and repeats nothing from the schema. The structure flows from what → how → behavior → usage, which is ideal.
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 output schema and no annotations, the description covers the essential workflow: anchoring to a passage, providing exact quote, default suggestion behavior, and usage for targeted comments. Minor gaps exist (e.g., no mention of role parameter, but that is fully documented in the schema). Overall, it is sufficiently complete for an agent to use the tool correctly.
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 100%, so the baseline is 3. The description adds meaningful guidance beyond the schema, particularly for the 'quote' parameter (exact quoted text from compiled paper or source prose) and for 'accepted' (clarifying when to use true vs default). This elevates the score to 4.
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's function with a specific verb and resource: 'Post a review comment anchored to a passage of the paper.' It also adds context ('for a reviewer agent marking up the document') and distinguishes from sibling tools like reply_to_comment and resolve_comment, which serve 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?
Explicit usage guidance is provided in the final sentence: 'Use this to leave many targeted comments rather than one long critique.' The description also implies when this tool is appropriate (reviewer marking up the document) without explicitly naming alternatives, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the comments the user has accepted on the rendered PDF, as located work items. Each has an id, page, the quoted passage, the source file:line it anchors to (best-effort), and the user's instruction. Call this when the user asks to "address/check my comments" (or after they mention leaving comments) — or on each pass of an agent loop watching for new comments. For each item: open the source at the given location, make the requested edit (saving triggers a recompile + a checkpoint automatically), then call resolve_comment with its id and a one-line note. If it returns none, there is nothing accepted yet — reviewer suggestions awaiting the human's accept don't count.
| Name | Required | Description | Default |
|---|---|---|---|
| includeResolved | No | Also list resolved comments (default false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses what the tool returns, notes the 'best-effort' nature of source file:line anchoring, and explains the acceptance semantics (only accepted comments, not mere suggestions). It doesn't explicitly mention side effects, but as a listing tool, the absence of modification language implies read-only behavior, and the workflow description avoids conflating this tool with edits.
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 information-dense but well-structured: front-loaded purpose, then returned fields, then usage guidance, then workflow, then edge case. Every sentence serves a purpose, no filler. It is longer than average but earns its length by providing crucial operational 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 there is no output schema, the description fully specifies the return data (id, page, quote, source location, instruction) and the none-case. It also provides necessary workflow context (open source, edit, resolve_comment) and clarifies what counts as accepted. This is complete for an agent to invoke and process the tool correctly.
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 100% for the single optional parameter includeResolved, with a clear description in the schema. The tool description does not mention the parameter, but since the schema fully documents it, the description adds no additional value; baseline 3 applies.
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 'List the comments the user has accepted on the rendered PDF', specifying the verb, resource, and scope. It distinguishes this from sibling tools like add_comment or resolve_comment by focusing on listing accepted comments and enumerating the returned fields (id, page, quote, source location, instruction).
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?
Explicitly explains when to use: 'Call this when the user asks to address/check my comments' or on each pass of an agent loop. It also specifies a workflow (open source, edit, resolve_comment) and clarifies an edge case: if none returned, reviewer suggestions not yet accepted don't count. This gives clear context and practical direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent checkpoints (auto-saved on each successful compile) — sha, timestamp, and file/line-change stat, newest first. Use this to find a sha to pass into show_diff, or to cite specific saved versions when summarizing a multi-step editing session.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max checkpoints to return, newest first (default 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that checkpoints are auto-saved on successful compiles and describes the return content and ordering. It does not explicitly state that the operation is read-only, but this is strongly implied by 'list' and the absence of any mutation language.
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 sentences, front-loaded with the action and purpose. Every clause adds value—the auto-save context, the returned fields, and the specific use cases. No redundant phrasing.
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?
For a simple listing tool with one optional parameter, the description adequately covers what it returns (fields and ordering) and when to use it, including integration with show_diff. No output schema is present, but the description sufficiently describes the output structure.
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 provides 100% coverage for the lone 'limit' parameter, including a clear description. The tool description does not add extra parameter semantics, so the baseline 3 applies.
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 it lists recent checkpoints, specifying the fields (sha, timestamp, file/line-change stat) and ordering (newest first). It distinguishes itself from sibling tools by mentioning use with show_diff and summarizing multi-step sessions.
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?
It explicitly says to use this tool to find a sha for show_diff or to cite saved versions, providing clear context for when to use it. It also implies an alternative (show_diff) in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compile the current project's LaTeX to a PDF locally and update the live preview. Uses the machine's TeX install when it has one, otherwise a bundled WASM TeX Live in a headless browser — so no local TeX is required. Returns compile success/errors, which engine and backend ran, the file count, and the local preview URL — open it to see the rendered pages. Call this after editing .tex files to see and verify the rendered result.
| Name | Required | Description | Default |
|---|---|---|---|
| engine | No | TeX engine. Defaults to xelatex. | |
| backend | No | Compiler backend. Default "auto": use the local TeX install (latexmk) when there is one — full package fidelity, output matching Overleaf — else the bundled WASM TeX Live. "system" forces the local one and errors if absent; "wasm" forces the bundled one. | |
| mainFile | No | Path to the main .tex file, relative to the project root. Auto-detected (by scanning for \documentclass) if omitted. | |
| shellEscape | No | Let the document run external programs (LaTeX shell-escape) — needed by \includesvg (Inkscape), minted (Pygments) and similar. Off by default: it lets a .tex execute shell commands, so enable it only for sources you trust. Has no effect on the wasm backend, which cannot run subprocesses at all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels: it discloses backend selection logic, shellEscape security implications, return contents, and the fallback behavior when no local TeX is installed. It even notes shellEscape has no effect on the wasm backend.
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 concise at five sentences, covering purpose, backend behavior, return values, and usage context. There is slight redundancy with the backend parameter description, but each sentence earns its place.
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?
No output schema exists, but the description enumerates exactly what is returned (compile success/errors, engine, backend, file count, preview URL). It also explains mainFile auto-detection and shellEscape security, making it complete for a tool with this complexity.
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 already provides full coverage (100%) with detailed descriptions for all four parameters. The tool description adds only that it reports which engine/backend ran, offering no extra parameter semantics, so baseline 3 is appropriate.
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 first sentence states a specific action (compile LaTeX to PDF) and resource (current project) with an outcome (update live preview), clearly distinguishing it from sibling tools that handle diffs and comments.
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?
It explicitly says 'Call this after editing .tex files to see and verify the rendered result,' providing clear when-to-use guidance. It doesn't mention when-not-to-use or name alternative tools, but siblings are functionally distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a reply to a comment's thread — to ask the human a clarifying question, explain your reasoning, or (as a defender) push back on another agent's suggestion before it is resolved. Use the comment id from check_comments. This does not resolve the comment; use resolve_comment for that.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The comment id, from check_comments. | |
| role | No | Who is replying (default "author"). | |
| text | Yes | Your reply. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full load. It discloses the key side-effect boundary (does not resolve) and the intended timing ('before it is resolved'), though it does not mention permissions or behavior on resolved threads.
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?
Three tightly written sentences: the first states the action and purpose, the second gives the id source, and the third clarifies a key distinction. Every sentence earns its place with no redundancy.
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?
For a simple 3-parameter mutation tool with no output schema, the description is complete: it covers purpose, use cases, id provenance, and relationship to sibling tools, leaving no significant gap for an agent to select and invoke it.
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 100%, so the description adds little beyond the schema. It reinforces the id source and gives context for the role parameter ('as a defender'), but text and role meaning are already documented in the 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 begins with a specific verb+resource ('Add a reply to a comment's thread') and lists concrete use cases. It also explicitly distinguishes this tool from resolve_comment, making its purpose unmistakable.
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 states clear when-to-use scenarios (clarifying question, explaining reasoning, defender pushback) and gives an explicit alternative: 'This does not resolve the comment; use resolve_comment for that.' It also tells the agent to use the comment id from check_comments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a workspace comment as resolved after you have made the edit it asked for. Pass the comment id (from check_comments) and a one-line note describing what you changed — the note is shown to the user on the comment card.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The comment id, as returned by check_comments. | |
| note | Yes | One line describing the edit you made to address it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the note is shown to the user on the comment card, which is useful. However, it does not mention any irreversibility, permissions, or post-resolution behavior, leaving some gaps.
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 is front-loaded with the action, then provides necessary parameter context. No wasted words.
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?
For a simple two-parameter tool with no output schema, the description adequately covers purpose, parameter sources, and user-facing behavior. It lacks a mention of confirmation or error handling, but that is not critical given the simplicity.
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 schema already describes both parameters clearly (100% coverage). The description adds value by specifying that the id comes from check_comments and that the note is user-visible, going beyond the schema's own 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 'Mark' and the resource 'workspace comment' with the specific action of resolving. It distinguishes itself from sibling tools like add_comment and reply_to_comment by focusing on resolution after an edit.
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 provides clear usage context: use after making the edit the comment asked for. It also indicates the id comes from check_comments. It doesn't explicitly mention when not to use or alternatives, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a side-by-side git diff as an image, shown inline in the conversation. Use this when the user asks to SEE a diff visually — it returns a picture, not a text summary. Defaults to current uncommitted changes; pass a checkpoint sha for a specific saved version.
| Name | Required | Description | Default |
|---|---|---|---|
| checkpoint | No | A checkpoint commit sha (from the preview History panel) to diff. Omit to show the current uncommitted changes vs the last commit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adequately discloses key behaviors: it returns an inline image, defaults to uncommitted changes, and can target a checkpoint sha. It does not mention side effects or limitations, but for a read-only rendering tool this is sufficient.
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 sentences, front-loaded with the core action, and every clause adds value. No fluff or repetition.
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?
For a simple one-parameter tool with no output schema, the description is complete: it explains what the tool returns, the default behavior, how to get a specific version, and when to use it. No gaps for a typical use case.
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 100% and the parameter 'checkpoint' is fully described in the schema. The tool description reiterates the checkpoint behavior but adds no new semantic detail beyond what the schema already provides, so baseline 3 is appropriate.
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 'Render a side-by-side git diff as an image' with a specific verb and resource, and distinguishes it from a text summary. It also differentiates from siblings by focusing on visual diff rendering rather than previews or comments.
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?
Explicitly says 'Use this when the user asks to SEE a diff visually' and clarifies it returns a picture, not text. It provides context on default behavior and checkpoint usage, though it does not name a specific alternative tool for text diffs, so it stops short of full when-not guidance.
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.
v0.1.10add_commentcheck_commentslist_checkpointsrender_previewreply_to_commentresolve_commentshow_diffScored across 7 tools
Each tool targets a distinct action: visual diff, compilation preview, checkpoint listing, comment inspection, resolution, adding, and replying. There is no functional overlap.
All tool names follow a consistent verb_noun snake_case pattern (e.g., show_diff, list_checkpoints, resolve_comment), making the action and target clear.
With 7 tools, the server is scoped appropriately for a LaTeX review workflow. Each tool serves a clear purpose without redundancy.
The set covers the full lifecycle of a review: preview, diff, checkpoint management, and a complete comment system (list, add, resolve, reply). No obvious gaps.
Overleaf alternative online LaTeX editor. AI agents edit, comment, and chat. Keep or revert edits.
Persistent AI LaTeX workspace: edit and compile multi-file projects, export publication-ready PDFs.
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.
Edit your Overleaf LaTeX projects from Claude and ChatGPT; every change is a real Git commit.
