Skip to main content
Glama
YounesBensafia

Overleaf MCP Server

by YounesBensafia
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

Overleaf MCP Server

An MCP server focused only on Overleaf projects (via Overleaf Git sync).

What This Server Does

  • Connects MCP-compatible clients to your Overleaf project through Git sync.

  • Exposes file-level tools to list, read, write, and sync project content.

  • Keeps workflow simple: pull latest files, edit, then push back to Overleaf.

Related MCP server: Overleaf MCP Server

Architecture

flowchart LR
  C[MCP Client\nClaude Desktop / other MCP host] -->|Tool Call| S[Overleaf MCP Server]
  S -->|Git Sync| O[Overleaf Git Remote]
  S -->|Read / Write| L[Local Repo Mirror]
  L -->|Commit + Push| O
  O -->|Pull / Fetch| L
  S -->|Tool Result| C

Tool Workflow

sequenceDiagram
  participant Client as MCP Client
  participant Server as Overleaf MCP Server
  participant Local as Local Mirror
  participant Overleaf as Overleaf Git

  Client->>Server: list_files / read_file
  Server->>Local: Ensure local clone
  Server->>Overleaf: git pull
  Overleaf-->>Server: latest content
  Server-->>Client: file list / file content

  Client->>Server: write_file(path, content)
  Server->>Local: update file
  Server->>Local: git commit
  Server->>Overleaf: git push
  Server-->>Client: success + metadata

Requirements

  • Python 3.13+

  • uv package manager

  • An Overleaf plan with Git integration (individual, group, or institution license). Check if your institution provides free access at Overleaf for Institutions - use your institutional email. If your institution is not listed, upgrade your plan.

Git Setup

  1. Enable Git - open your project on Overleaf → Menu → enable Git under Integrations.

  2. Copy project ID - from the browser URL (e.g. https://www.overleaf.com/project/69a4f7cc4eaf13bd56de5b04 → 69a4f7cc4eaf13bd56de5b04).

  3. Generate a Git token - Account Settings → Git integration authentication tokens → Generate new token.

  4. Configure .env - copy .env.example to .env and fill in:

OVERLEAF_TOKEN=your_git_token
PROJECT_ID=your_project_id

project_id can also be passed per tool call if you leave PROJECT_ID unset.

Quick Start

git clone https://github.com/younesbensafia/overleaf-mcp-server.git
cd overleaf-mcp-server
uv sync
cp .env.example .env   # then edit with your token/project id
uv run python -m src.main

The server listens on stdio - connect your MCP client (Claude Desktop, etc.) to it.

Available Tools

Tool

Description

list_files

Pull and list files from Overleaf project

read_file

Read file content

write_file

Update file, commit, and push to Overleaf

sync_project

Force a pull/sync from Overleaf

Claude Desktop Setup

Add to ~/.config/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "overleaf": {
      "command": "uv",
      "args": ["--directory", "/path/to/overleaf-mcp-server", "run", "python", "-m", "src.main"],
      "env": {
        "OVERLEAF_TOKEN": "your_git_token",
        "PROJECT_ID": "your_project_id"
      }
    }
  }
}

Troubleshooting

  • 403 Forbidden on git operations:

    • Your plan doesn't include Git integration - follow the Git Setup section.

    • Or the Git token is wrong - regenerate it at Account Settings → Git integration authentication tokens.

  • Wrong project content:

    • Set the correct PROJECT_ID in .env.

    • Or pass project_id explicitly in tool calls.

  • Sync conflicts:

    • Run sync_project before write_file if the remote changed.

  • Server not starting:

    • Ensure dependencies are installed with uv sync.

    • Verify Python 3.13+ is available.

License

MIT - See LICENSE

Available Tools

4 tools
list_filesA

List all files in the Overleaf project

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idNoOverleaf project ID (optional if PROJECT_ID is configured)

TDQS

A3.5/5.0
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. It states the tool lists all files, but does not disclose behaviors like the optional PROJECT_ID configuration or details about what file information is returned. It is minimally adequate.

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 unnecessary words. Every word contributes to understanding the tool's purpose.

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 simple tool with one optional parameter and no output schema, the description is adequate but incomplete. It does not clarify the format of the output (e.g., file names, paths) or the behavior when PROJECT_ID is configured.

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, so the parameter is already documented. The description does not add extra meaning beyond the schema's description of the project_id parameter.

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 'List all files' and the resource 'Overleaf project', using a specific verb and resource. It is distinct from siblings like read_file, sync_project, and write_file.

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?

No guidance is provided on when to use this tool versus alternatives such as read_file or sync_project. There is no mention of when not to use it or what context makes it appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_fileB

Read the content of a file in the Overleaf project

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesPath to the file in the Overleaf project
project_idNoOverleaf project ID (optional if PROJECT_ID is configured)

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description only says 'read content' without disclosing behavioral details like encoding, size limits, or side effects. The non-destructive nature is implied but not explicit.

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, no wasted words. Clearly conveys the core functionality in a concise manner.

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?

Given no output schema and no annotations, the description is too minimal. It does not specify the return format (e.g., text, binary) or mention how to obtain file paths (e.g., using list_files).

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 both parameters described in the schema. The description adds no additional semantics beyond the schema, meeting the baseline.

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 (read) and resource (content of a file in the Overleaf project), and distinguishes from sibling tools: write_file writes, list_files lists, sync_project syncs.

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?

No guidance on when to use this tool vs alternatives such as list_files or write_file. No context on prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sync_projectC

Pull latest changes from Overleaf

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idNoOverleaf project ID (optional if PROJECT_ID is configured)

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It only states 'pull latest changes' without detailing side effects (e.g., file overwriting), authentication needs, or whether it is a read-only operation. This is insufficient for an agent to understand the tool's behavior.

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 a single, concise sentence with no unnecessary words. It is front-loaded with the purpose, though it sacrifices completeness for brevity.

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?

For a tool with one optional parameter and no output schema, the description lacks important context: what 'pull' entails (e.g., return value, local state changes, error conditions). It does not fully equip an agent with the information needed to invoke it 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% with a description for 'project_id'. The tool description adds no extra meaning beyond what the schema provides, so baseline 3 is appropriate.

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 'Pull latest changes from Overleaf' clearly states a specific action (pull) on a specific resource (Overleaf). It distinguishes itself from sibling tools (list_files, read_file, write_file) which are file operations, not sync actions.

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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, typical scenarios, or when to prefer sync over direct file operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

write_fileC

Create or update a file in the Overleaf project

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesPath to the file in the Overleaf project
contentYesContent to write to the file
project_idNoOverleaf project ID (optional if PROJECT_ID is configured)

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It mentions mutation ('Create or update') but fails to detail side effects like overwriting, required permissions, or error conditions.

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 with no unnecessary words, efficiently conveying the core purpose.

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?

Given the tool's complexity (3 parameters, no output schema), the description lacks important contextual details such as overwrite behavior, file size limits, and project configuration requirements.

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 baseline is 3. The description does not add extra meaning beyond the schema's parameter descriptions, such as constraints on content size or file path format.

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?

Description specifies verb 'Create or update' and resource 'file in the Overleaf project', clearly distinguishing from sibling tools like list_files, read_file, and sync_project. However, it could more explicitly state that it can overwrite existing files.

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?

No guidance is provided on when to use this tool versus alternatives. The agent must infer usage from context; explicit conditions or exclusions are absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.0
    • First observedlist_files
    • First observedread_file
    • First observedsync_project
    • First observedwrite_file
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a distinct action: listing, reading, syncing, or writing files. No overlap in functionality, enabling clear agent selection.

Naming Consistency5/5

All tool names follow the consistent verb_noun pattern in snake_case (e.g., list_files, write_file), making them predictable and easy to parse.

Tool Count4/5

With 4 tools covering file listing, reading, writing, and syncing, the scope is narrow but sufficient for basic project management. Slightly minimal but not undercutting usability.

Completeness3/5

Core file operations (list, read, write, sync) are present, but deletion and renaming are missing. This gap could force agents to work around limitations in file lifecycle management.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers