Overleaf MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OVERLEAF_BASE_URL | No | Overleaf instance to connect to. | https://www.overleaf.com |
| OVERLEAF_STATE_DIR | No | Directory for session data, downloads, and local build files. Use separate state directories for different accounts or instances. | ~/.overleaf-mcp |
| OVERLEAF_BROWSER_CHANNEL | No | Browser channel passed to Playwright. | chrome |
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
} |
| resources | {
"subscribe": true,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_session_statusA | Check the saved browser session, observed cookie renewal and keepalive schedule. Never returns cookie values. |
| list_projectsA | List projects accessible to the signed-in account, using the server response. |
| get_projectB | Get the live project file tree and main document. |
| get_collaborationA | Read explicitly invited members and current online users separately. Link collaborators may appear only in presence, so invitedMembers is not a complete participant list. Online connections are grouped by account; unavailable presence is reported as unknown. |
| get_reviewA | Read project-wide comments, replies and resolution status, plus file/line anchors and visible tracked changes. path limits the annotation scan to one text file; threads remain project-wide. Data is limited by server permissions. |
| write_fileA | Replace text using OT edits that retain unchanged regions. Requires docId/version from a recent read. Rejects stale versions; waits for server application and verifies document identity and content. An unknown write outcome blocks further writes to that document on the connection; reconnect and inspect before retrying. Concurrent edits may be merged by Overleaf. |
| replace_textB | Replace exactly one occurrence of oldText in a file, preserving surrounding content. Requires a recent document ID and version. Reports confirmed application separately from final-content verification. |
| create_fileA | Create an empty editable text file. name is a filename, not a path. Omit parentFolderId for the project root. Then use write_file to populate it. |
| upload_fileA | Upload one local file to an existing project folder. localPath must be absolute on the MCP server. path is the project-relative destination, defaulting to the local basename. overwrite defaults to false; true explicitly permits replacing a same-name text document or binary file. Returns server acceptance, actual location and content verification separately. An unverified or unknown result must be inspected before retrying. ZIPs are uploaded as files, not imported as projects. |
| download_fileC | Download a text file or binary attachment as a local artifact. Text documents come from a fresh live snapshot. |
| download_projectA | Download the complete current source ZIP, or an API-accessible historical project version. historyVersion is a project-history version, not a document OT version. |
| list_history_labelsB | Return project version labels visible to the current session, without local plan restrictions. |
| get_history_diffA | Compare two project-history versions. With path, returns file content differences; without path, returns file-tree differences. Use versions returned by list_history. |
| compile_projectA | Start compilation and return a job ID immediately. mode=auto tries Overleaf first and falls back locally for timeout/service errors. Local compilation needs latexmk and the selected engine. Poll get_compile_result for this build PDF and logs. |
| get_compile_resultA | Get compilation job state, PDF/log artifact URIs and the actual compile status. state=completed means the job finished; result.status determines whether compilation succeeded. |
| read_fileA | Read a text file directly from the live document server. Each call obtains a fresh snapshot and version, not a ZIP or disk cache. Optional 1-based line range. |
| watch_fileB | Start watching server-pushed document changes. Use wait_for_file_change or subscribe to the returned resource URI. |
| wait_for_file_changeA | Wait for a document version to change, up to 30 seconds. Returns the new content, or changed:false on timeout. Disconnections are reported explicitly. |
| unwatch_fileA | Stop a watch created by watch_file. Independent resource subscriptions and pending waits remain active. |
| list_historyC | Return the history API response unchanged. No local time-window restriction or subscription filtering is applied. Pass the server pagination cursor as before. |
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 20 tools
Most tools target a clearly distinct resource+action (compile vs. get_compile_result, watch vs. wait vs. unwatch, list_history vs. list_history_labels vs. get_history_diff). The main fuzziness is between content-retrieval tools (read_file, download_file, get_project) and between the two editing tools (write_file, replace_text), though the descriptions do draw usable boundaries between them.
Every tool is snake_case verb_noun (get_session_status, list_projects, write_file, download_project, compile_project, watch_file, unwatch_file). Even the longer forms like wait_for_file_change and list_history_labels fit the same predictable pattern, so an agent can guess names reliably.
20 tools is on the heavy side but the surface genuinely spans several sub-domains (files, history, compilation, collaboration, review, session), so most tools earn their place. A few could plausibly be merged (e.g. watch/unwatch/wait as one polling tool), keeping it just short of a 5.
Core read/write/upload/download plus history and compilation are covered, but there is no way to create or delete a project, no delete/rename/move file operation, and the review surface is read-only (no posting comments or replies). These are notable gaps for an agent trying to do end-to-end project work rather than read-and-edit.