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 "Install 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, the description carries the burden. It discloses that by default the comment is a 'suggestion' awaiting human acceptance, and only with accepted:true in copilot mode is it immediately actionable. It mentions the workspace and author loop. It does not cover edge cases or side effects, but the main behavioral trait is well explained.
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 three sentences, front-loads the core action, and every sentence adds necessary context. No fluff or repetition. Efficient and to the point.
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 is provided, but the description does not mention what the tool returns (e.g., a comment ID). It also doesn't clarify that the page parameter defaults to 1 (though schema says so). For a creation tool, omitting return value information is a gap. However, the description sufficiently covers invocation behavior.
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 baseline is 3. The description adds value by explaining the accepted parameter's effect and default behavior, which goes beyond the schema description. It also implies the role parameter implicitly with 'reviewer agent' but does not elaborate on the enum values, so not fully compensating but still adding value.
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 action (post a review comment), the resource (anchored to a passage of the paper), and the agent (reviewer). It distinguishes from leaving 'one long critique' and implies this tool is for targeted comments, separating it from siblings like reply_to_comment.
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 says when to use: 'leave many targeted comments rather than one long critique.' It explains the accepted parameter's context: only in fully-autonomous mode. However, it doesn't explicitly contrast with siblings like reply_to_comment or resolve_comment, though the name and description imply this is for new comments.
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?
Describes return fields (id, page, passage, source location, instruction) and behavioral nuance (only accepted comments, not pending). With no annotations, the description fully carries the burden and is transparent about scope and limitations.
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?
Front-loaded with purpose and usage. Slightly verbose due to embedded workflow steps, but each sentence adds value. Could be more concise by separating workflow from tool description.
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?
Provides sufficient context for the tool's return value and usage scenario. Lacks error handling or pagination info, but adequate for a simple list tool with one optional parameter and no output schema.
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?
Single optional boolean parameter with schema coverage 100%. The description does not add extra meaning beyond the schema description. 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?
Clearly states the tool lists accepted PDF comments as work items. Distinguishes from siblings like resolve_comment and add_comment by specifying it only returns accepted comments (not pending suggestions).
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 tells when to call: when user asks to 'address/check my comments' or in an agent loop watching for new comments. Also clarifies that pending suggestions don't count, and provides step-by-step post-processing instructions.
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?
No annotations provided, so description carries full burden. It discloses the tool is a read operation, returns recent checkpoints auto-saved on compile, with specific fields and ordering. Lacks mention of permissions or idempotency, but adequate.
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: first describes output and order, second gives usage context. No unnecessary words, front-loaded with key information.
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, description provides return field names and sorting. It explains the auto-save context and ties to sibling tools. Lacks mention of pagination or filtering beyond limit, but fairly complete for a simple list tool.
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 single parameter 'limit' is fully described in the input schema. The description does not add additional semantic value beyond what the schema provides, so baseline score of 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, specifies their content (sha, timestamp, file/line-change stat), and ordering (newest first). It distinguishes itself from sibling tools like show_diff and comment tools by focusing on checkpoints.
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 guides when to use: to find a sha for show_diff or cite versions during multi-step editing. Does not mention exclusions, but positive guidance is clear and helpful.
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 provided, the description fully carries the burden. It reveals key behaviors: uses local TeX or WASM, updates live preview, returns compile success/errors, engine, backend, file count, and preview URL. There is no mention of destructive actions, but that aligns with a preview tool.
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 efficiently structured: first sentence states purpose, second explains backend, third lists returns, fourth gives usage advice. It contains no fluff, though some sentences are slightly long. Every sentence contributes value.
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, the description adequately explains return values (success/errors, engine, backend, file count, preview URL). It also covers the live update behavior. It does not detail error formatting or edge cases, but covers the essentials.
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 description coverage is 100%, so the schema already documents all parameters well. The description adds no significant parameter-specific detail beyond the schema; it only provides general context. 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 the tool's action: 'Compile the current project's LaTeX to a PDF locally and update the live preview.' It identifies the specific resource (LaTeX project) and verb (compile/preview), and is well differentiated from sibling tools which are about comments and diffs.
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 explicitly says 'Call this after editing .tex files to see and verify the rendered result,' giving clear usage context. It does not specify when not to use it or provide alternative tools, but siblings are distinct enough to avoid confusion.
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?
The description discloses that the action does not resolve the comment, which is key behavioral context. However, with no annotations provided, it could further describe side effects, permissions, or response format. Still, the provided note about non-resolution is valuable.
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 two sentences plus a parenthetical, all front-loaded with essential information. Every sentence adds value without 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?
Given the tool's simplicity (3 params, no output schema), the description adequately covers invocation context. It could mention that the reply is appended to the thread, but overall it supplies enough for an agent to decide and use 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 baseline is 3. The description adds meaning by specifying the source of 'id' (from check_comments) and the role options (especially for defender). This goes beyond the schema documentation.
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 action 'Add a reply to a comment's thread' and provides specific use cases (ask clarifying question, explain reasoning, push back). It distinguishes from the sibling tool 'resolve_comment', making the purpose unambiguous.
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 gives explicit when-to-use scenarios and explicitly states what this tool does not do ('This does not resolve the comment; use resolve_comment for that.'). It also tells the source of the required 'id' parameter, aiding correct invocation.
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 burden. It discloses that the note is 'shown to the user on the comment card,' which is useful. However, it omits whether the action is reversible or if there are side effects (e.g., notifications). For a state-changing tool, more detail would be helpful.
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 two sentences with no wasted words. It front-loads the action and then provides the necessary parameter context. Every 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?
For a simple mutation tool, the description covers the input semantics and usage workflow. It does not mention the return value (no output schema provided), but that is a minor gap given the action's simplicity. An experienced agent would likely infer a success/error response.
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 description adds meaningful context: for 'id,' it specifies 'as returned by check_comments'; for 'note,' it explains its purpose and that it is displayed to the user. This enhances understanding beyond the schema's 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 action ('Mark a workspace comment as resolved') and the resource ('workspace comment'). It distinguishes from sibling tools like add_comment and reply_to_comment by specifying this is about resolution after making 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 gives clear when-to-use guidance: 'after you have made the edit it asked for' and references check_comments to obtain the id. It does not explicitly mention when not to use (e.g., if already resolved) or alternatives, but the workflow context is sufficient.
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?
No annotations are provided, so the description carries full burden. It discloses that the tool returns a picture (not text) and is shown inline, but it does not discuss potential limitations (e.g., empty diffs, large outputs), permissions, or side effects. The disclosure is adequate but not exhaustive.
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 two sentences long, highly efficient, and front-loaded with the core purpose. Every sentence adds value without redundancy or unnecessary elaboration.
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 the single optional parameter, complete schema coverage, and no output schema (returns an image), the description covers the essential usage. It explains how the result is displayed ('shown inline'). It could mention what happens if the diff is empty, but the overall completeness is high for a straightforward tool.
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 only parameter (checkpoint) is described in the schema as 'A checkpoint commit sha', with 100% schema coverage. The description adds meaningful context: where to obtain the sha (preview History panel) and the behavior when omitted (shows current uncommitted changes), improving usability beyond the schema alone.
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 'Render a side-by-side git diff as an image', specifying a concrete verb and resource. It distinguishes itself from siblings by indicating it returns a visual picture, not text, and defaults to uncommitted changes.
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 explicitly says 'Use this when the user asks to SEE a diff visually', providing clear guidance on when to invoke. It also explains the default behavior (current uncommitted changes) and the parameter for a specific checkpoint. However, it does not explicitly mention when not to use it or alternative tools for text diffs.
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. Dates show when Glama detected each change.
v0.1.10add_commentcheck_commentslist_checkpointsrender_previewreply_to_commentresolve_commentshow_diffEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Edit your Overleaf LaTeX projects from Claude and ChatGPT; every change is a real Git commit.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Still-chowline394/MagicTeX-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server