Skip to main content
Glama
deepghs

overleaf-mcp

by deepghs

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
OL_CSRFNoOptional CSRF override
OL_BROWSERNoExplicit Chromium-family browser executable
OL_BASE_URLNoOrigin; defaults to https://www.overleaf.comhttps://www.overleaf.com
OL_HEADLESSNoSet to 1 to disable automatic browser login explicitly (for headless servers)
OL_INSECURENoBrowser-login certificate exception; avoid normally and do not assume it fixes Node TLS
OL_MCP_LOG_LEVELNodebug, info, warn, error; logs go to stderr

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
pingA

Health check. Returns 'pong' and the server version. Does not contact Overleaf.

list_projectsA

Lists projects on the configured Overleaf account, sorted by most recently updated. Returns each project's id, name, last update time, and owner. Use the returned id with open_project to start working on a project.

open_projectA

Joins the project's real-time Socket.IO session and caches its file tree. Must be called before list_files / read_file / edit_file. Switching projects automatically closes the previous session.

list_filesA

Returns the file tree of the currently open project as a flat list of project-relative paths. Cheap — uses cached data from open_project, no network. Each entity has a path (e.g. 'chapters/intro.tex'), an id, and a kind ('doc' | 'file' | 'folder').

read_fileA

Reads the contents of a file by project-relative path. For text docs (.tex, .bib, .md, etc.) the full text appears in both the content array and structuredContent.text; metadata (version, line/byte counts, ranges, tracked-change/comment counts) is in structuredContent. For binary files (images, PDFs) base64 is in content and structuredContent.base64, with MIME type alongside.

edit_fileA

Replaces the contents of a doc by computing a minimal diff and submitting it as an OT operation over the live Socket.IO connection. The change lands in the web editor in real time. By default the edit appears as a pending suggestion in the Review panel (track:'on'); pass track:'off' to write directly. If path is omitted, defaults to the project's root doc. Only .tex / .bib / .md / similar text docs are editable — binary files are not.

find_and_replaceA

Replace one occurrence — or all, with replace_all: true — of old_string with new_string in a doc, without re-emitting the rest of the file. By default old_string must be unique; ambiguous matches are returned with line:column locations so you can extend the match. Submits the minimal OT operation through the same pathway as edit_file, so by default it lands as a pending suggestion in Overleaf's Review panel (track:'on'). If path is omitted, defaults to the project's root doc. USE WHEN: a SINGLE targeted edit (one typo, one label rename, one heading change) in a large doc — saves tokens vs. re-emitting the body and avoids accidental whitespace drift. AVOID FOR BATCH WORK: for multiple substitutions (e.g. converting many words, applying a style guide across a chapter) prefer ONE edit_file call with all changes computed client-side. Each find_and_replace is its own round-trip with its own race window, its own tracked-change entry, and its own cache-sync cycle — calling it N times for N small changes amplifies the failure modes that one batched edit_file would avoid.

compileA

Triggers a LaTeX compile on Overleaf's CLSI, then fetches output.log and returns a unified summary: status, whether a PDF was produced, error_count (parsed ! -prefixed log lines), warning_count, first error lines, output file list, timings. Note: Overleaf returns status:"success" even when LaTeX has errors (PDF is still generated under nonstopmode). The truthful 'did it build cleanly?' check is error_count === 0. Use read_log for the full log when more context is needed.

read_logA

Returns the full LaTeX log from the most recent compile call. compile already includes the error count + first few errors in its response — use this only when you need more context (full log, line numbers, package warnings, etc.). The content array shows a summary of !-prefixed error lines at the top, then the log truncated to the last 8000 chars for display. structuredContent.log contains the FULL untruncated log so programmatic callers can grep / parse it.

list_commentsA

Returns all review-panel comment threads in the open project, sorted by most recently updated. Each entry includes the thread id, the doc path it's anchored on, the quoted text it refers to, the latest message preview, and whether it's resolved. Use read_comment_thread for full content.

read_comment_threadA

Fetches the full message history of one thread (all replies with author + timestamp). Use this when list_comments shows a thread that looks relevant.

reply_commentA

Adds a new message to an existing comment thread. Threads come from list_comments. The message appears immediately in Overleaf's review panel for collaborators.

resolve_commentA

Marks a thread as resolved. Use after addressing the comment (e.g. by editing the doc and replying).

reopen_commentB

Reopens a previously-resolved thread.

list_tracked_changesA

Enumerates every pending tracked-change suggestion in the open project (across all docs), with author name + email, doc path, op kind ('insert' | 'delete'), position, inserted/deleted text, and a stable change_id. Use this to plan an accept_changes or reject_changes call: filter the result by author / doc / kind / text, collect the matching change_id values, then pass them. Tracked changes only — review-panel comments are listed by list_comments.

accept_changesA

Permanently accepts the specified tracked-change suggestions. The text stays in the doc; the pending-change metadata is cleared. Pass the change_id values from list_tracked_changes. Changes that span multiple docs are grouped automatically. Irreversible.

reject_changesA

Rejects the specified tracked-change suggestions. For tracked inserts the inserted text is removed; for tracked deletes the strikethrough is cleared and the text stays. Implemented as an OT update with u:true flags on the inverse ops — same pathway Overleaf's web client uses. Pass the change_id values from list_tracked_changes. Irreversible.

download_fileC

Download a document snapshot or binary file from the open project.

download_projectB

Download the open project as a ZIP archive (no extraction).

download_outputA

Download an artifact from the last compile. Run compile first. Defaults to output.pdf.

create_folderA

Create one folder in the open project. Parent must exist.

create_fileA

Create an empty text document. Use edit_file for tracked content insertion.

upload_fileA

Upload a NEW binary asset only. Existing targets and text files are refused; use create_file and OT edits for text. Do not run concurrently with other tree changes.

rename_entityA

Rename a file or folder within its current parent; refuses existing targets.

delete_entityA

Delete a file or folder. Requires explicit confirmation; recursive folder deletion is refused.

add_commentA

Create a native anchored comment on unique selected text. expected_version must come from read_file. Refuses stale versions. Does not change document text.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4/5.0

Scored across 26 tools

Disambiguation5/5

Each tool has a clearly distinct purpose. Comment operations (list, read, reply, resolve, reopen, add), tracked changes (list, accept, reject), file operations (create, read, edit, delete, rename, upload), downloads (file, project, output), and compile/log functions are all non-overlapping. Even similar-sounding tools like edit_file and find_and_replace are clearly differentiated.

Naming Consistency5/5

Tool names follow a consistent verb_noun pattern throughout (read_comment_thread, list_projects, open_project, list_files, read_file, edit_file, compile, read_log, list_comments, reply_comment, resolve_comment, reopen_comment, list_tracked_changes, accept_changes, reject_changes, download_file, download_project, download_output, create_folder, create_file, upload_file, rename_entity, delete_entity, add_comment). The slight deviation of find_and_replace and ping does not break the overall pattern.

Tool Count4/5

With 26 tools, this server is above the typical 3-15 range but is justified by the breadth of Overleaf's feature set. The tools cover project management, editing, comments, tracked changes, compilation, and downloads, each earning its place. It could be trimmed slightly (e.g., consolidating download_* tools) but is reasonably scoped.

Completeness5/5

The tool surface covers the full lifecycle of working with an Overleaf project: listing/opening projects, navigating and editing files, creating and managing entities, compiling and reading logs, handling comments and tracked changes, and downloading artifacts. No obvious gaps exist for typical agent workflows; the only missing operations would be administrative tasks like sharing or project deletion, which are out of scope for an MCP server.

Maintenance

ActivityMaintained
ResponsivenessNo issues