MagicTeX MCP Server

by ZoeLinUTS

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.10
Disambiguation5/5
Each tool targets a distinct action in the workflow: rendering diffs, listing checkpoints, compiling previews, and managing the comment lifecycle. There is no overlap between the comment tools since they cover add, list, reply, and resolve as separate operations.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with lowercase and underscores (show_diff, list_checkpoints, render_preview, check_comments, resolve_comment, reply_to_comment, add_comment). The verbs clearly indicate the action, and nouns identify the object, making the naming pattern predictable.
Tool Count5/5
Seven tools is well-scoped for the server's purpose of LaTeX editing with preview, versioning, and comment review. Each tool has a clear role, and the count is neither too sparse nor bloated.
Completeness4/5
The tool set covers the important workflow: compile preview, view diff, list/resolve/reply/add comments. A minor gap is the lack of a checkpoint-restore tool, but list_checkpoints and show_diff provide sufficient visibility for version history. Overall, the surface is quite complete for the stated purpose.
Average 4.4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 137 commits in the last 12 weeks
- Last stable release on July 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers 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.
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 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MagicTeX-mcp MCP server](https://glama.ai/mcp/servers/ZoeLinUTS/MagicTeX-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ZoeLinUTS/MagicTeX-mcp)

Score Badge

Copy to your README.md:

[![MagicTeX-mcp MCP server](https://glama.ai/mcp/servers/ZoeLinUTS/MagicTeX-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ZoeLinUTS/MagicTeX-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ZoeLinUTS/MagicTeX-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server