overleaf-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OL_CSRF | No | Optional CSRF override | |
| OL_BROWSER | No | Explicit Chromium-family browser executable | |
| OL_BASE_URL | No | Origin; defaults to https://www.overleaf.com | https://www.overleaf.com |
| OL_HEADLESS | No | Set to 1 to disable automatic browser login explicitly (for headless servers) | |
| OL_INSECURE | No | Browser-login certificate exception; avoid normally and do not assume it fixes Node TLS | |
| OL_MCP_LOG_LEVEL | No | debug, 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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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_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 |
| 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 |
| find_and_replaceA | Replace one occurrence — or all, with |
| compileA | Triggers a LaTeX compile on Overleaf's CLSI, then fetches |
| read_logA | Returns the full LaTeX log from the most recent |
| 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_threadA | Fetches the full message history of one thread (all replies with author + timestamp). Use this when |
| reply_commentA | Adds a new message to an existing comment thread. Threads come from |
| 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_changesA | Permanently accepts the specified tracked-change suggestions. The text stays in the doc; the pending-change metadata is cleared. Pass the |
| 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 |
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 26 tools
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.
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.
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.
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.