latexmk-mcp

by coolport

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: v1.1.3
Disambiguation4/5
Most tools have clearly distinct purposes: compile, draft_compile, watch operations, clean, check, dependencies, config, and citations. The only potential confusion is between latexmk_compile and latexmk_draft_compile, but their descriptions clarify draft as a quick single-pass syntax check vs. full compilation.
Naming Consistency3/5
All tools share a latexmk_ prefix, but the verb/noun order is inconsistent: most use verb_noun (compile, clean, list_dependencies), while watch tools use noun_verb (watch_start, watch_stop, watch_list), and draft_compile uses an adjective-noun form. This mix is readable but not a uniform pattern.
Tool Count5/5
With 11 tools, the server covers the full LaTeX latexmk workflow—compiling, watching, cleaning, dependency management, config, and citations—without bloat. Each tool addresses a distinct user need, making the count well-scoped for this domain.
Completeness5/5
The tool surface covers the essential lifecycle of LaTeX document processing: compile (draft and full), watch, clean, dependency resolution, config management, and citation checking. There are no obvious dead ends or missing operations for the announced purpose of a latexmk wrapper.
Average 3.8/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose the structured return values (errors, warnings, package hints, page count, output path), which adds useful context. However, it does not mention side effects, execution time, or failure modes (e.g., if latexmk is not installed), leaving significant 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 two sentences, front-loaded with the action and immediately followed by a concise summary of return values. Every word earns its place with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters and no output schema, the description covers the core operation and return values but lacks contextual guidance. It does not address the return_pdf option, working directory semantics, or how to interpret the structured output, and it does not position itself relative to sibling tools.
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% with all parameters having descriptions, so the baseline is 3. The tool description adds no per-parameter detail beyond the schema, though it does reiterate that both raw source and file path are accepted, which is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Compile a LaTeX document using latexmk' and lists the two input modes (raw source or file path), making the core purpose unambiguous. However, it does not explicitly distinguish itself from the sibling latexmk_draft_compile, missing the opportunity for full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like latexmk_draft_compile, latexmk_watch_start, or latexmk_check. It only mentions input options, not decision criteria for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the write action and target locations, but does not mention whether existing files are overwritten, required permissions, or any side effects. This is a significant gap for a mutation tool.
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 front-loads the action and targets, with no wasted words. It is highly concise and structurally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no annotations, and no output schema, this description is too sparse. It does not explain how parameters relate, what the generated config contains, or any prerequisites, leaving the agent without enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 57%, leaving engine, shell_escape, and output_format undocumented. The tool description adds no parameter information at all, failing to compensate for the missing schema descriptions or clarify parameter interactions.
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 action (Write a .latexmkrc config file) and specifies the two target locations (project vs global), distinguishing it from sibling tools like latexmk_read_config. The verb and resource are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and action, but there is no explicit guidance on when to use this tool versus alternatives. The sibling tools are not referenced, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the core read behavior and the optional cross-referencing, but does not mention output format, error handling, or prerequisites. It is neither misleading nor richly contextful.
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, concise sentence that front-loads the primary action (Extract) and scopes it to citation keys. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate parameter set and no output schema. The description explains the main function but does not describe return values or the relationship between tex_content and file_path. It is adequate for a simple extraction tool but leaves gaps for an agent to infer.
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%, with each parameter having a description. The tool description adds minimal value beyond the schema, simply implying the use of a LaTeX document and .bib file. Baseline 3 is appropriate because the schema already documents the parameters clearly.
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 action ('Extract') and resource ('all citation keys from a LaTeX document'), with an optional cross-reference against a .bib file. This is distinct from sibling tools like compile or watch, which have 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need citation keys), but it does not explicitly contrast with alternatives or mention exclusions. No guidance is given on when to choose tex_content vs file_path, though the schema's oneOf does provide some structure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It mentions using `latexmk -deps` but does not disclose potential side effects such as running the compiler and creating auxiliary files, nor does it describe the output format or any permissions needed. This is a significant gap for a tool that likely executes latexmk.
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 core action and resource, followed by examples and the command used. No waste; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but there is no output schema and the description does not clarify the return format, side effects, or how the tool handles the oneOf requirement when both file_path and tex_content are provided. The schema covers parameter existence, but the description misses behavioral and output context, making it minimally adequate.
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 description coverage is 100%, with each parameter (file_path, tex_content, working_dir) already described. The description adds context about what dependencies are listed, but does not add any parameter-specific semantics beyond the schema, 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 the tool lists all file dependencies of a LaTeX document, with specific examples of dependency types, and identifies the underlying command `latexmk -deps`. This is specific and distinguishes it from sibling tools like compilation or watching.
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 clearly implies the tool is for inspecting dependencies, which is a clear context. It does not explicitly mention alternatives or when not to use, but the purpose is unambiguous enough to guide selection among the sibling latexmk tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description shoulders the burden of disclosing behavior. It only states the action 'stop' without explaining side effects, error handling for invalid session IDs, idempotency, or what happens to the underlying process. This is insufficient for a mutating operation.
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 well-structured sentence, front-loaded with the verb and resource. Every word contributes meaning and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and the absence of annotations, the description is minimally adequate but lacks important behavioral details such as whether the stop is blocking, what happens if the session does not exist, or whether it only affects the specific session. It is complete enough for a basic stop operation but not fully comprehensive.
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 of the session_id parameter, including its provenance from latexmk_watch_start. The description adds no further parameter context, so it meets the baseline for high schema coverage without adding extra semantics.
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 uses a specific verb ('Stop') and a concrete resource ('running latexmk watch session'), with a clear parameter ('session_id'). It fully distinguishes this tool from sibling operations like latexmk_watch_start and latexmk_watch_list.
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 clearly implies when to use this tool: after launching a watch session with latexmk_watch_start. It provides clear context but does not explicitly mention alternatives or when not to use it, though the sibling names make that unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It explains that the tool deletes auxiliary files, optionally output files, and uses latexmk -c/-C. However, it does not mention prerequisites (e.g., working_dir existence), error conditions, or that deletion is irreversible—though 'removes output files' conveys destructiveness.
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, front-loaded sentence that efficiently conveys the core functionality and the two modes. Every word earns its place, with no filler or redundancy.
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 3-parameter tool with no output schema, the description adequately explains the two cleaning modes and their effects. It could be improved by noting return behavior or failure scenarios, but the essential information for invoking the tool correctly is present and clear.
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 description coverage is 100%, so the schema already documents all parameters. The tool description does not add additional parameter meaning beyond what the schema provides (e.g., job_name, clean_all, working_dir semantics are already in the schema). 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's function: cleaning LaTeX build artifacts in a directory, with a specific verb ('Clean') and resource. It distinguishes between two modes (auxiliary files only vs. auxiliary + output files), which also differentiates it from sibling compile/check/watch tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when LaTeX build artifacts need to be removed, and explains the two modes (auxiliary vs. output files). However, it does not explicitly compare with alternatives like latexmk_compile or latexmk_check, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It states it lists active sessions, which implies a read-only operation, but it does not explicitly confirm that it has no side effects, requires no special permissions, or describe what happens to the sessions. The behavior is minimally transparent but lacks explicit safety or scope details.
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 directly states the tool's function without any filler. Every word is necessary and it is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is somewhat sparse. It clarifies what it lists (all currently active latexmk watch sessions) but does not describe the format of the returned data or any additional behavior. Given the simplicity of the tool, it is minimally complete but could benefit from stating the return type or confirming it does not alter sessions.
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 input schema is empty, so with zero parameters the description has nothing to add beyond the schema. Per the baseline for zero-parameter tools, a score of 4 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 uses a specific verb 'list' and clearly identifies the resource 'currently active latexmk watch sessions'. It distinguishes from sibling tools like latexmk_watch_start and latexmk_watch_stop which perform different actions, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the user wants to view active watch sessions, but it does not explicitly state when to prefer this over alternative tools or provide any exclusion criteria. No context is given for when not to use it, though the simple read-only nature makes this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It conveys a read-only, non-mutating action via 'Check', but it does not disclose the return format, how it indicates absence of latexmk, or any potential side effects. For a simple check tool this is acceptable but not fully transparent.
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 one concise sentence, front-loaded with the verb 'Check', and contains no unnecessary words or redundancy.
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?
The tool is simple: one optional parameter, no output schema, and a straightforward purpose. The description is adequate for an agent to understand what to call and why, though it could benefit from stating the expected output type. Given the low complexity, this is nearly complete.
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's single parameter 'working_dir' is fully described as optional and not required for this check, achieving 100% schema description coverage. The description adds a subtle point about checking 'on this system', implying system-wide scope, but this is not a significant addition beyond 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 uses the specific verb 'Check' and clearly identifies the resources: 'latexmk is installed' and 'which TeX engines are available'. This unambiguously distinguishes it from the sibling compile, watch, and config tools, which have different actions.
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 implies clear usage: verify the TeX environment before compilation. However, it does not explicitly state when not to use it or name alternative tools, though the sibling list shows no other check tool, making the context clear.
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 burden, and it does disclose key behavioral traits: it is fast, single-pass, does not run bibliography, and surfaces errors. It does not mention side effects like file generation or cleanup, but for a compile tool the primary behavior is well covered.
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 two sentences, front-loaded with the core action, and every clause earns its place ('fast', 'single-pass', 'without running multiple passes or bibliography', 'Good for syntax/error checking'). There is no wasted wording.
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?
The tool has moderate complexity with 4 parameters and a oneOf constraint, but the schema already documents the input options well. The description adds the key contextual distinction of draft vs. full compile, which is critical given the sibling tools. It does not explain the input modes or engine defaults, but the schema covers those, so overall it is sufficiently complete.
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 description coverage is 75%, so the baseline is 3. The description does not add any additional meaning to the parameters; it doesn't explain the oneOf requirement, engine choices, or the difference between tex_content and file_path. The schema descriptions already cover most parameter meaning, so no extra value is added.
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 uses a specific verb 'Run' with a specific resource 'fast single-pass draft compile', and clearly distinguishes itself from siblings by emphasizing 'single-pass' and 'without running multiple passes or bibliography'. It also states its purpose ('quickly surface errors', 'syntax/error checking'), making it unique among the listed compile-related tools.
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 context for when to use the tool: during editing for syntax/error checking, and it explicitly says it does not run multiple passes or bibliography, implying a lighter alternative. However, it does not name alternative tools explicitly or state when not to use it, so it misses the full 'when-not/alternatives' 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, the description carries the burden. 'Read' clearly indicates a non-destructive operation, and specifying 'from the project and home directory' discloses the scope and likely precedence. However, it doesn't detail behavior such as merging or error handling, so it's not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence without redundant phrasing. It front-loads the action and resource, making it easy to parse and scan.
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 read tool with one optional parameter and no output schema, the description covers the essential information: what it reads and where. It could mention the return format or merge behavior, but given the simplicity, it is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single optional working_dir parameter. The tool description adds little beyond the schema, only confirming that both project and home directories are read. Since the schema does the heavy lifting, a baseline score of 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 the tool reads active .latexmkrc config files from the project and home directory. This distinguishes it from siblings like latexmk_compile or latexmk_write_config, as the verb 'read' and the resource 'config files' are specific and unambiguous.
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 implies when to use this tool: when you need to inspect current LaTeX configuration settings. It does not explicitly state alternatives or exclusions, but the contrast with write_config and other actions is clear from the name and description, providing sufficient context.
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 burden. It discloses the background nature, auto-recompile behavior, and the session_id return value, which are crucial for an agent to understand the tool's side effects and lifetime. However, it could add more detail about stopping the process or potential side effects like build artifacts.
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?
Single sentence, information-dense, and front-loaded. No wasted words. Balances specificity with brevity.
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 tool that starts a background process, the description gives the essential facts: it's a watch, it auto-recompiles, and it returns a session_id. The parameters are covered by the schema. It doesn't explain the full lifecycle, such as how to stop it, but the sibling tools provide that context. Overall adequate for invocation.
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 schema already covers two of three parameters with descriptions (file_path and working_dir) and the engine has an enum and default. The description itself adds no extra parameter meaning, but the schema coverage is 67%, so the description isn't required to compensate fully. The engine's semantics are self-evident from the enum.
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 uses a specific verb 'Start' and names the specific resource ('background latexmk watch process (-pvc)') with the key behavior 'recompiles automatically on file changes'. It also states the return value, clearly distinguishing it from siblings like latexmk_compile or latexmk_watch_stop.
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 clearly conveys the use case: continuous recompilation on file changes. However, it does not explicitly mention alternatives or exclusions, such as 'use latexmk_compile for one-shot builds', though the context of siblings makes this inferable.
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:

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

Score Badge

Copy to your README.md:

[![latexmk-mcp MCP server](https://glama.ai/mcp/servers/coolport/latexmk-mcp/badges/score.svg)](https://glama.ai/mcp/servers/coolport/latexmk-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/coolport/latexmk-mcp'

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