overleaf-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OVERLEAF_API_PASS | Yes | WEB_API_PASSWORD | |
| OVERLEAF_API_PATH | No | Path prefix for the API proxy | /agent-api |
| OVERLEAF_API_USER | Yes | WEB_API_USER (usually 'overleaf') | |
| OVERLEAF_BASE_URL | Yes | Base URL of the Overleaf instance, e.g. https://overleaf.example.com | |
| OVERLEAF_OWNER_ID | Yes | Overleaf user id owning created projects | |
| OVERLEAF_CLSI_PATH | No | Path prefix for the CLSI proxy. Empty disables diagnostics. | /agent-clsi |
| OVERLEAF_CLSI_TOKEN | No | Must match the nginx config. Optional but required for diagnostics. | |
| OVERLEAF_TIMEOUT_MS | No | Timeout in milliseconds for operations | 120000 |
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 |
|---|---|
| create_projectA | Create a new Overleaf project and return its id. The project is immediately visible and editable in the Overleaf web UI by a human. |
| list_filesA | List every file in the project with its size. Reflects edits made by humans in the web UI, not just files written through this server. |
| read_fileA | Read one file from the project. Call this before rewriting a file a human may have touched, so your edit is based on current content. |
| write_fileA | Create or overwrite a file. Writes are merged into the live document as an operational transform, so a human with the project open sees the change immediately and their cursor is preserved. NOTE: this replaces the whole file — read_file first if the content may have changed. |
| delete_fileB | Delete a file from the project. |
| compileA | Compile the project and return structured diagnostics. Returns a verdict, plus errors with file/line and suggested fixes. Does NOT return the PDF itself (it would flood your context) — use get_pdf if you need the bytes. Check verdict first: if it says BLOCKED, the server environment is at fault and retrying will not help. |
| get_pdfA | Compile and save the PDF to a local file, returning the path. Use when you need the artifact itself; for fixing errors use compile instead. |
| get_logA | Fetch the raw LaTeX log from the last compile. Use only when compile's structured diagnostics are not enough — the raw log is long. |
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 8 tools
Each tool targets a distinct operation: project creation, file listing, reading, writing, deleting, compiling, PDF retrieval, and log access. Even the compile/get_pdf/get_log trio is clearly separated by their descriptions (structured diagnostics vs. artifact bytes vs. raw log). No two tools are likely to be confused.
Most tools follow a clear verb_noun snake_case pattern (create_project, list_files, read_file, write_file, delete_file, get_pdf, get_log). 'compile' is a single verb without an object, which is a slight deviation, but the naming remains consistent and predictable overall.
Eight tools is well-scoped for an Overleaf/LaTeX project server, covering project creation, file management, compilation, and output handling. Each tool serves a clear purpose without unnecessary bloat.
The file-level CRUD (list/read/write/delete) and compile/PDF/log operations are well covered. However, the project lifecycle is incomplete: there is no way to list existing projects, delete a project, or update project metadata, which is a notable gap for a multi-project server.