Overleaf Web MCP

by mhmdaskari

Not rated
GitHub

About

MCP server for revision-checked Overleaf editing, compilation, and review threads

Details

Author
mhmdaskari
Categories
Productivity

Configuration, authentication, and security

An advertisedol-maxDocLengthvalue takes precedence over the fallback. Target content at or above the limit returnsDOC_TOO_LARGE; an oversized serialized update returnsUPDATE_TOO_LARGEand must be split into smaller independently revisioned writes.

compile_project.timeoutMsaccepts 1 second through 15 minutes. It changes only how long the MCP call waits, not the account's server-side compile allowance.

The login command uses a separate browser profile and does not inspect the normal Chrome profile. Session files are stored underoverleaf-web-mcpin the platform configuration directory:

- Linux:${XDG_CONFIG_HOME:-~/.config}/overleaf-web-mcp
- macOS:~/Library/Application Support/overleaf-web-mcp
- Windows:%APPDATA%\overleaf-web-mcp

The entries below are representative rather than exhaustive, and their capabilities may change over time.

Review-range investigation was informed byOverleaf Comment Exporter. Real-time protocol behavior was informed byOverleaf Workshop.

- The collaboration adapter implements the Socket.IO 0.9 wire format used by the targeted Overleaf client family. Project bootstrap rejects unsupported protocol versions.
- ShareJS text OT and history-OT are normalized behind one document interface. Tracked ShareJS writes carry the authenticated author in update metadata; tracked history-OT writes carry author and timestamp metadata on inserted and retained-deletion components.
- Visible history-OT offsets account for tracked deletions retained in the raw snapshot.
- At most two project sockets are cached by default. Active sockets are never evicted, and idle sockets disconnect after 90 seconds. While a project socket remains open, the account may appear online to collaborators.
- All document sessions and tree mutations share a project-wide FIFO because Overleaf's join/leave epoch is socket-wide. Documents are joined for one queued operation and then left.
- A write succeeds only after acknowledgement, matchingotUpdateApplied, leave/rejoin, and content-hash verification.
- If a write times out, the intended hash means success, the unchanged original revision means timeout, and any third observable state means conflict. The write is never submitted again automatically.
- A comment is created as a REST thread and then attached through OT. Timed-out attachment recovery checks the new thread ID and exact range; orphan cleanup occurs only after the unchanged document proves attachment did not apply.
- A timed-out reply is accepted only when current author, exact normalized content, and the request-time window identify the refreshed message.
- ShareJS comment status uses the dedicated REST action. History-OT comment status is part of the document operation and snapshot.
- History monitoring reads one 25-group update window, strips email fields, and keeps no cursor or background state on the server.

Thread messages, authors, and resolution state come from/project/:id/threads. When the deployment exposes/project/:id/ranges, that project-wide index identifies the documents containing filtered threads. Only those documents are joined to calculate line and column positions and quoted context.

If a usable project-wide range index is unavailable, a project-wide call returns threads withpositionsUnavailable: true; it never scans every document silently. SupplyingfilePathjoins only that document and resolves its ShareJS ranges or history-OT comment state. Threads without a document range are returned asunlocated.

The discussion record and source range are separate Overleaf objects. The thread endpoint provides messages, while live document state provides attachment and status metadata.

npm run check npm run lint npm test npm run build npm pack --dry-run

Unit and deterministic integration tests cover revision identity, Unicode positions, section parsing, tracked and untracked OT operations, history normalization, update limits, queue/cache behavior, Socket.IO frames, timeout recovery, comment attachment, file-tree events, and MCP registration.

Live tests are disabled by default and must target a disposable project:

RUN_OVERLEAF_LIVE_TESTS=1 \ OVERLEAF_LIVE_TEST_PROJECT_ID=0123456789abcdef01234567 \ npm test -- test/live

AddRUN_OVERLEAF_LIVE_REVIEW_TESTS=1for review reads,RUN_OVERLEAF_LIVE_TRACKED_WRITE_TESTS=1for a disposable tracked file create/delete, orRUN_OVERLEAF_LIVE_HISTORY_TESTS=1for read-only history normalization. Feature availability depends on the deployment and account. Keep request volume low and treat cleanup failures as test failures.

Git workflows, collaborator/account administration, billing, chat, background history watching, backward history pagination, version diffs and restoration, label mutation, and editing or deleting individual comment messages are outside the current release. Private API compatibility is version-specific and maintained on a best-effort basis.

The 1Password MCP server creates a bridge that allows MCP clients such as Codex and Kiro to manage your 1Password Environments with secure authorization prompts.

This is the 1st, easiest, and cheapest PPT, slides, presentation AI generation MCP Server in the world.

Persistent memory for any AI assistant. Zero token cost until recall. Stores memories in local SQLite, ranks by 6-factor scoring, returns results 79% smaller than JSON. Works with Claude, ChatGPT, Grok, Cursor, Windsurf, and any MCP client.

A MCP server that enables AI assistants to interact with Anki, the spaced repetition flashcard application.

Enables LLM clients to interact with macOS applications through AppleScript. Built using the @beyondbetter/bb-mcp-server library, this server provides safe, controlled execution of predefined scripts with optional support for arbitrary script execution.

An MCP server for WordPress plugin audits

Turn your AI assistant into a digital marketing hub that creates, organizes, and analyzes links and QR Codes on demand.

Connect AI clients to Cal.com scheduling through the Model Context Protocol using the hosted server at mcp.cal.com or a local instance.

Sync Calendars, Scheduling Links, AI Executive Scheduling Assistant, Unified Calendar

MCP server for revision-checked Overleaf editing, compilation, and review threads

Unofficial MCP server for browsing, tracked writing, organizing, compiling, reviewing, and monitoring version history in Overleaf projects through an authenticated web session.

Overleaf Web MCP is an independent Node.js Model Context Protocol server for complete Overleaf project workflows. It uses browser-facing private REST endpoints plus Socket.IO/OT through a saved web session, without requiring Overleaf Git integration.

[!CAUTION] This is an unofficial client for unsupported private APIs. Overleaf may change these interfaces without notice, and automatingwww.overleaf.commay carry Terms-of-Service and account risk. Start with a disposable project, keep live-test volume low, and review Overleaf's current terms before using an important account.

- Node.js 20 or newer
- Google Chrome, Chromium, Brave, or Microsoft Edge for browser-assisted login
- An Overleaf account with access to the target projects

Configure an MCP client to start the package over stdio:

{ "mcpServers": { "overleaf": { "command": "npx", "args": ["-y", "overleaf-web-mcp", "serve"] } } }

Theservecommand is the default and can be omitted.

npm install npm run build npm run login npm start

Use the same origin for login and the MCP server:

OVERLEAF_BASE_URL=https://overleaf.example.org npx overleaf-web-mcp login
{ "mcpServers": { "overleaf": { "command": "npx", "args": ["-y", "overleaf-web-mcp", "serve"], "env": { "OVERLEAF_BASE_URL": "https://overleaf.example.org" } } } }

Private API and feature availability varies by Overleaf deployment and edition.

The server registers 19 tools. Expand only the areas you need.

write_fileand non-emptycreate_filecontent acceptwriteMode: "untracked" | "tracked". The default is"untracked"for backward compatibility. Tracked file creation requires non-empty initial content; creating the file entity itself remains a normal project-tree operation.

Section parsing is single-file only. It recognizes starred headings and optional titles, ignores%comments and common verbatim-like environments, and never follows\inputor\include.

add_commentuses 1-based line and UTF-16 column positions. The normalized live selection must exactly equalexpectedText.

This is stateless client-driven polling, not a background watcher. Results includecurrentVersion,nextSinceVersion,hasEarlierHistory, andgapDetected, plus normalized update groups with authors, paths, file-tree operations, labels, and origin metadata. Author emails and raw private response fields are omitted.

- Reads normalize CRLF and lone CR to LF and reportnewline: "LF".
- Revisions are opaque concurrency tokens containing project and document identity, OT protocol, version, and a SHA-256 content hash. Callers should retain but never construct them.
- Content writes use minimal OT edits and are verified against a freshly joined document. Ambiguous writes are observed during a bounded recovery window and are never retried automatically.
- Explicit tracked writes never silently fall back to untracked writes. They require an authenticated user ID, whiletrackChangesActiveseparately reports the project state observed at connection time.
- manage_entitydeletion requiresconfirmPathto exactly equalpath.
- Calllist_projects, thenget_project_tree.
- Usecreate_filefor text, ormanage_entityto create folders and rename, move, or confirmed-delete entities.
- Useupload_filefor local binaries anddownload_fileto save documents or binaries to explicit local paths.
- Callread_fileand retain itsrevision.
- Modify the LF-normalized content.
- Callwrite_filewith the unchanged revision, complete replacement content, and the desired mode:

{ "projectId": "0123456789abcdef01234567", "filePath": "main.tex", "revision": "opaque-revision-from-read-file", "content": "\\section{Introduction}\nRevised text.\n", "writeMode": "tracked" }

- IfREVISION_CONFLICTis returned, read again and reconcile against the new content; never reuse the stale revision.

create_fileandwrite_sectionaccept the samewriteModechoice and return the resulting revision. A no-op write returns successfully but creates no tracked record.

Callmonitor_project_historywithout a cursor to establish the current window:

{ "projectId": "0123456789abcdef01234567" }

On the next poll, pass the previousnextSinceVersionassinceVersion. Only update groups whosetoVersionis newer are returned. IfgapDetectedis true, the cursor predates the single returned window; the tool deliberately does not page backward or calculate diffs.
- Callcompile_projectwith the selected root document.
- Usestop_compileto stop an active compile.
- Calllist_comments; it defaults to open threads and accepts file, status, and author filters.
- Usereply_to_commentfor an existing thread.
- To anchor a new thread, callread_file, select an exact range, then pass its revision, UTF-16 positions,expectedText, and message toadd_comment.
- Pass the latest revision toset_comment_statuswhen resolving or reopening an anchored thread.

All review-panel threads include available author metadata. Overleaf does not expose a reliable separate reviewer classification. Review comments and tracked changes require an Overleaf deployment and account entitlement that supports them.

Configuration, authentication, and security

An advertisedol-maxDocLengthvalue takes precedence over the fallback. Target content at or above the limit returnsDOC_TOO_LARGE; an oversized serialized update returnsUPDATE_TOO_LARGEand must be split into smaller independently revisioned writes.

compile_project.timeoutMsaccepts 1 second through 15 minutes. It changes only how long the MCP call waits, not the account's server-side compile allowance.

The login command uses a separate browser profile and does not inspect the normal Chrome profile. Session files are stored underoverleaf-web-mcpin the platform configuration directory:

- Linux:${XDG_CONFIG_HOME:-~/.config}/overleaf-web-mcp
- macOS:~/Library/Application Support/overleaf-web-mcp
- Windows:%APPDATA%\overleaf-web-mcp

The entries below are representative rather than exhaustive, and their capabilities may change over time.

Review-range investigation was informed byOverleaf Comment Exporter. Real-time protocol behavior was informed byOverleaf Workshop.

- The collaboration adapter implements the Socket.IO 0.9 wire format used by the targeted Overleaf client family. Project bootstrap rejects unsupported protocol versions.
- ShareJS text OT and history-OT are normalized behind one document interface. Tracked ShareJS writes carry the authenticated author in update metadata; tracked history-OT writes carry author and timestamp metadata on inserted and retained-deletion components.
- Visible history-OT offsets account for tracked deletions retained in the raw snapshot.
- At most two project sockets are cached by default. Active sockets are never evicted, and idle sockets disconnect after 90 seconds. While a project socket remains open, the account may appear online to collaborators.
- All document sessions and tree mutations share a project-wide FIFO because Overleaf's join/leave epoch is socket-wide. Documents are joined for one queued operation and then left.
- A write succeeds only after acknowledgement, matchingotUpdateApplied, leave/rejoin, and content-hash verification.
- If a write times out, the intended hash means success, the unchanged original revision means timeout, and any third observable state means conflict. The write is never submitted again automatically.
- A comment is created as a REST thread and then attached through OT. Timed-out attachment recovery checks the new thread ID and exact range; orphan cleanup occurs only after the unchanged document proves attachment did not apply.
- A timed-out reply is accepted only when current author, exact normalized content, and the request-time window identify the refreshed message.
- ShareJS comment status uses the dedicated REST action. History-OT comment status is part of the document operation and snapshot.
- History monitoring reads one 25-group update window, strips email fields, and keeps no cursor or background state on the server.

Thread messages, authors, and resolution state come from/project/:id/threads. When the deployment exposes/project/:id/ranges, that project-wide index identifies the documents containing filtered threads. Only those documents are joined to calculate line and column positions and quoted context.

If a usable project-wide range index is unavailable, a project-wide call returns threads withpositionsUnavailable: true; it never scans every document silently. SupplyingfilePathjoins only that document and resolves its ShareJS ranges or history-OT comment state. Threads without a document range are returned asunlocated.

The discussion record and source range are separate Overleaf objects. The thread endpoint provides messages, while live document state provides attachment and status metadata.

npm run check npm run lint npm test npm run build npm pack --dry-run

Unit and deterministic integration tests cover revision identity, Unicode positions, section parsing, tracked and untracked OT operations, history normalization, update limits, queue/cache behavior, Socket.IO frames, timeout recovery, comment attachment, file-tree events, and MCP registration.

Live tests are disabled by default and must target a disposable project:

RUN_OVERLEAF_LIVE_TESTS=1 \ OVERLEAF_LIVE_TEST_PROJECT_ID=0123456789abcdef01234567 \ npm test -- test/live

AddRUN_OVERLEAF_LIVE_REVIEW_TESTS=1for review reads,RUN_OVERLEAF_LIVE_TRACKED_WRITE_TESTS=1for a disposable tracked file create/delete, orRUN_OVERLEAF_LIVE_HISTORY_TESTS=1for read-only history normalization. Feature availability depends on the deployment and account. Keep request volume low and treat cleanup failures as test failures.

Git workflows, collaborator/account administration, billing, chat, background history watching, backward history pagination, version diffs and restoration, label mutation, and editing or deleting individual comment messages are outside the current release. Private API compatibility is version-specific and maintained on a best-effort basis.

The 1Password MCP server creates a bridge that allows MCP clients such as Codex and Kiro to manage your 1Password Environments with secure authorization prompts.

This is the 1st, easiest, and cheapest PPT, slides, presentation AI generation MCP Server in the world.

Persistent memory for any AI assistant. Zero token cost until recall. Stores memories in local SQLite, ranks by 6-factor scoring, returns results 79% smaller than JSON. Works with Claude, ChatGPT, Grok, Cursor, Windsurf, and any MCP client.

A MCP server that enables AI assistants to interact with Anki, the spaced repetition flashcard application.

Enables LLM clients to interact with macOS applications through AppleScript. Built using the @beyondbetter/bb-mcp-server library, this server provides safe, controlled execution of predefined scripts with optional support for arbitrary script execution.

An MCP server for WordPress plugin audits

Turn your AI assistant into a digital marketing hub that creates, organizes, and analyzes links and QR Codes on demand.

Connect AI clients to Cal.com scheduling through the Model Context Protocol using the hosted server at mcp.cal.com or a local instance.

Sync Calendars, Scheduling Links, AI Executive Scheduling Assistant, Unified Calendar

No reviews yet — be the first

Sign in to leave a review

Use Google, GitHub, or an email account so ratings stay tied to real people.

Email sign in

No reviews posted yet.