overleaf-mcp

by NiccoloSalvini

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools serve distinct purposes, but overleaf_compile and overleaf_download_pdf both involve compilation, and overleaf_push_file / overleaf_push_dir are closely related. Descriptions clarify the differences, so ambiguity is low.
Naming Consistency4/5
All tools share the overleaf_ prefix and use lowercase snake_case, but the pattern is not perfectly uniform: some are verb_object (delete_file, list_projects) while others are just verbs (compile, pull). This is mostly consistent and predictable.
Tool Count5/5
With 8 tools, the server is well-scoped for its purpose, covering essential Overleaf operations without unnecessary redundancy. The count is appropriate for a focused integration.
Completeness3/5
Core workflows like pulling, pushing, compiling, and downloading PDFs are covered, but there is no way to create or delete projects, and no direct file listing (only via pull). These gaps may require workarounds.
Average 3.8/5 across 8 of 8 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It states the action 'Delete' but does not mention that deletion is likely permanent, whether it requires specific permissions, or any side effects. This lack of safety context is significant for a destructive 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, clear sentence with no wasted words. It is appropriately concise and front-loaded, with the action verb 'Delete' leading.
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?
Although the schema is complete and an output schema exists, the description lacks essential contextual information for a destructive tool—such as permanence, safety warnings, or when to use it relative to other tools. The tool is simple, but the absence of behavioral or usage context makes it incomplete.
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% for both parameters ('project' and 'remote_path'), so the schema fully documents parameter semantics. The description adds no additional parameter information, matching the baseline of 3.
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 'Delete a file from an Overleaf project.' uses a specific verb 'Delete' and clearly identifies the resource (file) and context (Overleaf project). It distinguishes itself from sibling tools because none of the siblings (download, compile, list, push, etc.) perform deletion.
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, nor does it mention any prerequisites or exclusions. It is a bare statement of functionality without usage context.
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 carries full responsibility for behavioral disclosure. It mentions compilation and download but does not disclose potential side effects such as overwriting an existing dest_path, network/compilation failures, or permission requirements. This is a significant gap for a tool that writes to the filesystem.
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 is front-loaded with the action and resource. Every word earns its place, with no filler or repetition.
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 (2 params) and has an output schema, so return values are covered. The description tells the agent what the tool does end-to-end. However, it lacks behavioral details (e.g., failure modes, overwrite behavior) that would make it fully complete given the absence of annotations, so it does not merit a 5.
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 with descriptions for both parameters. The description adds context about the overall operation but does not add meaning beyond the schema, so the baseline 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 action ('Compile ... and download') and the resource (the resulting PDF), with a specific destination. It distinguishes itself from siblings like overleaf_compile (which only compiles) and overleaf_pull (which pulls project files), 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like overleaf_compile (if compilation only is needed) or overleaf_pull (if source files are needed). It implies usage for obtaining a PDF but does not explicitly state scenarios or exclusions.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a status and includes an error log on failure, which is useful. However, it does not mention side effects, authentication requirements, or whether the compile is asynchronous, leaving some behavioral 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, front-loaded sentence that conveys the action and return behavior without any unnecessary words. It is highly concise and well-structured.
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 the tool's simplicity, one parameter, and presence of an output schema, the description is largely complete. It covers what triggers and what is returned. Minor details like prerequisites or potential delays are omitted, but overall it is 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?
The input schema already fully describes the single 'project' parameter (24-char hex or exact name), so schema coverage is 100%. The description adds no additional parameter semantics, matching the baseline of 3.
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 action: 'Trigger a compile' and its return behavior (status and error log). This distinguishes it from sibling tools like overleaf_pull or overleaf_download_pdf, which handle different operations.
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 the tool's use case (compiling an Overleaf project) but does not provide explicit guidance on when to use it vs alternatives or mention any exclusions. The name and description make the purpose obvious, but explicit guidance is absent.
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 carries the full burden. 'List' clearly implies a read-only operation with no side effects, but the description does not disclose default filtering behavior (e.g., trashed/archived excluded by default) or any other operational nuances. This is adequate for a simple list 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, front-loaded sentence that directly states the tool's purpose and output fields. Every word earns its place, with no filler or redundant information.
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 listing tool, the description covers the essentials: what it lists and the key output fields. The presence of an output schema further offloads return-value details. However, it could briefly mention default filtering behavior for clarity, but this is adequately handled by the parameter schema.
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 has 100% coverage with clear descriptions for both parameters (include_trashed, include_archived). The description adds no further parameter details, so it does not exceed the baseline set by 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 clearly states the tool's function with a specific verb ('List') and resource ('your Overleaf projects'), and even enumerates the return fields (id, name, owner, last-updated timestamp). This clearly distinguishes it from sibling tools like overleaf_download_pdf or overleaf_delete_file.
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 for retrieving an overview of projects, but it does not explicitly state when to prefer this tool over alternatives, nor does it mention any exclusions or prerequisites. It provides enough context for a straightforward listing operation, but lacks explicit 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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explicitly discloses a critical side effect: overwriting existing files in dest_dir. This is valuable and better than a generic 'download' statement, though it omits other details like permissions or error behavior.
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 entire description is one sentence that leads with the action, specifies the destination, and includes an important caveat. Every word earns its place, with zero redundancy or filler.
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 focused tool with only two well-documented parameters and an output schema, the description covers the core operation and a key destructive consequence. It is concise but leaves out explicit alternative guidance, which is minor given the simplicity of the operation.
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 both parameters, including clear descriptions for 'project' and 'dest_dir'. The description adds no additional parameter-level meaning beyond what the schema states, which aligns with the baseline score of 3 for full schema coverage.
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 ('Download') and resource ('Overleaf project') plus a destination ('dest_dir'), clearly distinguishing this from siblings like overleaf_download_pdf (PDF only) and overleaf_push_file/push_dir (uploads). It accurately conveys the pull/extract operation.
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 a full project download is needed, and the overwrite warning hints at caution, but it does not explicitly state when to prefer this over siblings or mention exclusions. Clear context exists, but no direct alternatives or when-not guidance is provided.
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 and does well: it discloses side effects (overwrite, creating missing folders), explains the realtime channel join, and notes performance trade-offs. It omits auth requirements or error behavior, but the provided details are valuable and not contradicting any structured data.
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 primary action, and no wasted words. Every clause adds functional or behavioral context. Ideally concise.
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 an output schema exists, return values need no explanation. The tool's complexity—single file upload with folder creation and performance notes—is well covered. Some edge cases (e.g., invalid paths, overwrite confirmation) are not mentioned, but they are not critical for core selection and 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?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific detail beyond the schema—it mentions folder creation for remote_path but does not explain parameters in depth. The schema already documents default and example, so the description neither elevates nor detracts.
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 ('Upload or overwrite') and resource ('a single file in an Overleaf project'). It also distinguishes from siblings by emphasizing 'single file', which contrasts with overleaf_push_dir. The mention of creating missing folders adds scope specificity.
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 for single-file uploads, but does not explicitly state when to use this tool versus alternatives like overleaf_push_dir. The performance comparison to overleaf_pull is a behavioral note rather than clear usage guidance. No exclusions or 'when not to use' are provided.
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 bears the full burden of behavioral disclosure. It states the check condition but does not describe what the tool returns on success/failure, whether it has side effects, or how it behaves if the cookie is invalid. This is a minimal behavioral disclosure.
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 directly states the tool's purpose with no redundant wording or extraneous details.
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, with no parameters, and an output schema exists to document return values, so the description need not explain them. The description fully captures the tool's purpose, though it lacks explicit use-case context that would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts no parameters, and the input schema confirms an empty object. Per rubric, zero parameters receive a baseline score of 4; the description adds no parameter details but none are needed.
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: checking whether the OVERLEAF_COOKIE environment variable is set and represents a valid logged-in session. This distinguishes it from sibling tools that perform file operations or compilation.
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 the tool is for verifying authentication status, but it does not explicitly state when to use it relative to sibling tools or provide exclusions. The context of sibling tools suggests it is a pre-flight check, but that is not spelled out.
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. It transparently discloses core behaviors: byte-for-byte diffing, uploading only changed/new files, and the absence of deletion. It does not mention overwriting behavior or the dry_run flag's effect, but the most critical behavioral traits are 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 compact and front-loaded: the first sentence states the primary action, and the second elaborates on behavior and the deletion caveat. Every sentence earns its place; there is no redundancy or filler.
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 directory sync tool, the description covers what gets uploaded, how diffs work, and what it does not do. It does not describe return values or edge cases (e.g., project not found), but the output schema existence and the clarity of core usage keep it reasonably 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 100%, and the schema already documents all three parameters with clear descriptions. The tool description adds no additional parameter-level meaning beyond what the schema provides, so the baseline score of 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 uses a specific verb ('Push') and resource ('Overleaf project') and clarifies scope as 'every locally-changed file under local_dir'. It also distinguishes itself from sibling overleaf_push_file by emphasizing it handles a directory of files, and from overleaf_delete_file by explicitly stating what it does not do.
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 provides an explicit when-not scenario: 'Does not delete remote files that were removed locally — use overleaf_delete_file for that.' This names the alternative tool for a specific situation. It also implies when to use it (syncing a directory of changed files), though it does not directly compare to overleaf_push_file, the name and scope make the distinction clear.
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:

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

Score Badge

Copy to your README.md:

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

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