Allows interaction with an Overleaf instance, providing tools for creating projects, managing files, writing LaTeX, compiling documents, and retrieving structured diagnostics.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@overleaf-mcp compile main.tex and report any fixable LaTeX errors"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for self-hosted Overleaf Community Edition. Lets a coding agent create projects, write LaTeX, compile, and read back structured diagnostics — while a human edits the same document in the browser.
compile → {
"verdict": "FAILED with 1 fixable LaTeX error(s)",
"errors": [{
"file": "./main.tex", "line": 4,
"message": "Is \\usepackage{natbib} missing?",
"fixable": true
}]
}The raw log said ! Undefined control sequence.
Existing Overleaf MCP servers target overleaf.com and authenticate one of two ways:
Git bridge — the most popular ones. Unusable on Community Edition: the
git bridge is a Server Pro feature. The CE image neither builds nor starts it
(absent from server-ce/services.js, server-ce/runit/, and the Dockerfile),
and Features.mjs gates it on Settings.enableGitBridge, which CE never sets.
Session cookies / headless browser — works, but sessions expire, CSRF has to be handled, and login-flow changes break it.
Self-hosting opens a third door that overleaf.com users cannot reach, because it
is an internal interface there: Overleaf's own privateApiRouter,
authenticated with plain HTTP Basic. No session, no CSRF, no browser.
Related MCP server: Overleaf MCP
Structured diagnostics, not raw logs. Vendors Overleaf's own log parser and
its 1200-line ruleset — years of accumulated knowledge translating cryptic TeX
messages into actionable ones, including a command→package map (\citep →
natbib, \toprule → booktabs).
Separates "fix your LaTeX" from "fix your server." A missing package is not something an agent can solve by editing source. Conflating the two is what makes agents loop until they run out of context — the failure mode The AI Scientist reports as a central bottleneck. Compare:
verdict: FAILED with 1 fixable LaTeX error(s) — see errors[] for file/line.
verdict: BLOCKED: the server environment cannot build this document —
missing package/class file hyperxmp.sty. Install it on the server
(tlmgr install ...); the agent cannot fix this in source.
Do not retry without changing the server.Both are "compile produced no PDF." Only one is worth another attempt.
Two backends, because neither alone suffices:
Concern | Backend | Why |
Project CRUD |
| Stable HTTP Basic interface — the one Dropbox/GitHub sync uses |
Compilation | CLSI | Returns |
Writes enter through EditorController.upsertDocWithPath — the same entry point
the web UI uses. For an existing document that reaches
DocumentUpdaterHandler.setDocument, which diffs old against new and applies the
result as an operational transform. An agent write is merged into the live
document exactly like a keystroke: a human with the project open sees it
immediately, their cursor survives, and it lands in project history.
Verified against a live instance: with the document loaded in document-updater,
an agent write moved it from version 0 to version 1 — an incremental
operation, not a reload.
Self-hosted Overleaf Community Edition (Server Pro works too)
Shell access to the host running it
Node.js ≥ 20 wherever the MCP server runs
Overleaf reachable over HTTPS
git clone https://github.com/lintheyoung/overleaf-mcp
cd overleaf-mcp
# Kubernetes / k3s (Zeabur, Coolify, ...)
bash deploy/setup.sh --k8s --namespace <ns> --deployment <name>
# docker compose — not yet verified end to end, see Caveats
bash deploy/setup.sh --docker --container sharelatexFind the namespace and deployment with
kubectl get deploy -A | grep -i overleaf; for compose it is the service name
in docker-compose.yml (usually sharelatex).
This generates secrets under /etc/overleaf-agent, injects them so Overleaf
uses them, and installs an nginx reverse proxy exposing two prefixes:
Path | Upstream | Guard |
| Overleaf api | HTTP Basic (app) + path allow-list (nginx) |
| CLSI |
|
It mounts at /etc/nginx/vhost-extras/overleaf/, an include directory the stock
Overleaf vhost already provides — no vendor file is overwritten.
CLSI has no authentication of its own. It runs arbitrary LaTeX, which on
Community Edition means arbitrary code execution inside the container with
filesystem and network access. The token gate is not optional hardening; it is
the only thing standing in front of it. Never expose :3013 directly.
The allow-list matters too: privateApiRouter also carries endpoints for user
expiry and project deactivation. Only what an agent needs is routed; everything
else under /agent-api/ returns 404 even with valid credentials.
Platforms like Zeabur own the Deployment. A restart keeps the configuration above; a redeploy rebuilds from the platform's spec and silently drops it — the API starts answering 401 and the routes 404.
sudo install -m 700 deploy/restore.sh /usr/local/sbin/overleaf-agent-restore.sh
sudo install -m 644 deploy/systemd/* /etc/systemd/system/
sudo systemctl enable --now overleaf-agent-restore.timerRuns 3 minutes after boot, then hourly. It is a no-op when nothing is missing — patching a Deployment triggers a rollout, so an unconditional timer would restart Overleaf every hour.
npm install && npm run buildnpm run vendor (invoked by build) fetches Overleaf's log parser from GitHub.
See Licensing.
Find the Overleaf user id that should own agent-created projects — visible in the URL when viewing that user in the admin panel, or from the database.
{
"mcpServers": {
"overleaf": {
"command": "node",
"args": ["/path/to/overleaf-mcp/dist/index.js"],
"env": {
"OVERLEAF_BASE_URL": "https://overleaf.example.com",
"OVERLEAF_API_USER": "overleaf",
"OVERLEAF_API_PASS": "<from /etc/overleaf-agent/api_pass>",
"OVERLEAF_CLSI_TOKEN": "<from /etc/overleaf-agent/clsi_token>",
"OVERLEAF_OWNER_ID": "<overleaf user id>"
}
}
}
}node dist/dev/selftest.js # offline — diagnostics layer only
node dist/dev/smoke.js # end-to-end against the live instancesmoke creates a project, writes broken LaTeX, checks the diagnostic names
natbib, applies the fix, and confirms a PDF comes out.
Variable | Required | Default | Meaning |
| yes | e.g. | |
| yes |
| |
| yes |
| |
| yes | Overleaf user id owning created projects | |
| for diagnostics | Must match the nginx config | |
| no |
| |
| no |
| Empty disables diagnostics |
| no |
| Raise for long bibliographies |
Without OVERLEAF_CLSI_TOKEN the server still runs, but only get_pdf works —
no diagnostics.
Tool | Notes |
| Returns id + web URL |
| Reads back from Overleaf, so human edits are visible |
| Whole-file replace, merged as an OT |
| |
| Structured diagnostics. Does not return the PDF |
| Writes the PDF to disk, returns the path |
| Raw log, tail-truncated. Last resort |
compile withholds PDF bytes deliberately — base64 of a paper would swamp an
agent's context for no benefit.
OT guarantees no data is lost, not that the result is what you wanted:
The agent reads
intro.texat T0. A human rewrites a paragraph at T1. The agent writes back its T0-derived text at T2. The human's edit is gone from the live document — recoverable from history, but they will not know to look.
Split the paper and give each file an owner:
main.tex skeleton, rarely touched
sections/intro.tex agent
sections/related.tex humanPhysical separation beats relying on merge semantics. See CLAUDE.md for rules to hand your agent.
deploy/tlget.sh installs packages into TEXMFHOME by unpacking tlnet archives
directly, working around two tlmgr behaviours that bite containerised
Overleaf:
"package X is not relocatable, cannot install it in user mode" — tlmgr
refuses to place some packages under TEXMFHOME, the only TeX tree on the
persistent volume. The system tree is inside the image and is wiped on every
restart. hyperxmp, required by acmart, is one of these.
"tlmgr itself needs to be updated" — CTAN's tlnet only carries the current release, so once upstream moves on the tlmgr baked into the image cannot install anything at all.
bash deploy/tlget.sh <namespace> <deployment-substring> hyperxmpA tlnet archive is just a tarball of a texmf-dist tree, so unpacking it into
TEXMFHOME sidesteps both problems and lands the files on the volume.
This project is MIT (see LICENSE).
src/vendor/ is not part of it and is not committed. npm run vendor
fetches five files from overleaf/overleaf
at build time; those remain AGPL-3.0 and belong to Overleaf. Keeping them
out of the repository is what keeps the licences separate — otherwise AGPL's
network-use clause would extend to everyone running this server.
To pin or audit the fetch:
OVERLEAF_REF=v5.5.4 npm run vendor # pin to a tag
npm run vendor -- /path/to/overleaf # use a local checkoutOverleaf is a trademark of Overleaf Inc. This project is not affiliated with or endorsed by them.
Community Edition has no compile sandbox. Any logged-in user can read container environment variables through LaTeX. Upstream says as much. Only give accounts to people you trust, and do not open registration.
write_file replaces whole files. There is no patch/append tool yet.
Compilation is synchronous. A bibliography-heavy document takes 20 s+; CLSI's own ceiling is 600 s.
Verified against Overleaf CE 5.x on k3s. The --docker path in setup.sh is
written but not yet tested end to end — it also cannot inject the
environment variables automatically, so that step is manual. Reports welcome.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| compiler | No | ||
| projectId | Yes | ||
| timeoutSec | No | Default 180, server max 600 | |
| rootResourcePath | No | Defaults to main.tex |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses return shape (verdict, errors with file/line and suggestions), an important limitation (PDF is not returned to avoid context flood), and the BLOCKED verdict's irreversibility. This goes well beyond basic semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose/result, critical exclusion (PDF), and verdict handling. No redundancy, front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations or output schema, the description covers return format, failure modes (BLOCKED), and an alternative tool (get_pdf). This gives the agent sufficient context to use and interpret the tool's response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; timeoutSec and rootResourcePath are already described in the schema. The description adds no parameter-specific meaning, but the remaining parameters (compiler enum, projectId) are self-explanatory in context. It neither clarifies nor harms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compile') and resource ('the project'), and clearly states the return type ('structured diagnostics'). It distinguishes from sibling tools like get_pdf (which returns the PDF bytes) and get_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when not to use: 'Does NOT return the PDF itself — use get_pdf if you need the bytes.' Also instructs to 'Check verdict first: if it says BLOCKED, the server environment is at fault and retrying will not help,' which clarifies a key usage nuance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Overleaf project and return its id. The project is immediately visible and editable in the Overleaf web UI by a human.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Project name as shown in the Overleaf UI |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It usefully notes that the project is immediately visible and editable in the Overleaf web UI by a human, but it omits important details such as permission requirements, name-conflict behavior, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two front-loaded sentences. The first states the core action and return value, and the second adds useful contextual information. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter creation tool, the description adequately covers the action, the immediate side effect (visibility/editable in the web UI), and the return value (id). It does not specify the exact return format or conflict behavior, but given the tool's simplicity and full schema coverage, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single 'name' parameter at 100% with a clear description. The tool description adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') with a clear resource ('a new Overleaf project') and states the return value ('return its id'). This clearly distinguishes it from the sibling file-manipulation and compilation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is inherently distinct from sibling tools, implying this should be used when a new project is needed. However, it does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a file from the project.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action without noting whether deletion is permanent, required permissions, or side effects. This is insufficient for a destructive operation, leaving significant behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise and front-loaded. It contains no unnecessary words or repetition, earning a perfect score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only 2 parameters, but given the absence of annotations, output schema, and parameter explanations, the description provides only the bare minimum. It does not mention return values, error behavior, or how this tool fits with siblings like compile or get_log. It is minimally viable but lacks contextual depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 required parameters (path, projectId) with no descriptions (0% coverage). The tool description does not mention or explain these parameters, providing no additional meaning beyond the parameter names. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a file from the project' uses a specific verb and resource, making the tool's function unambiguous. It clearly distinguishes from sibling tools like read_file, write_file, and list_files by indicating the delete operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or conditions. Usage is implied by the tool name and simple statement, but no exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the raw LaTeX log from the last compile. Use only when compile's structured diagnostics are not enough — the raw log is long.
| Name | Required | Description | Default |
|---|---|---|---|
| maxBytes | No | ||
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It notes the log is raw and long, hinting at potentially large output. However, it omits error conditions, behavior when no compile has run, and what maxBytes controls, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and no filler. 'the raw log is long' efficiently justifies the usage constraint and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 parameters and no output schema, but with 0% schema coverage and no annotations, the description needs to explain parameters and edge-case behavior. It misses what happens before the first compile, maxBytes semantics, and possible error responses, so the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description names no parameters. The optional maxBytes parameter is completely undocumented, and projectId is only implied by context. The description adds zero value beyond the schema, which itself is terse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Fetch the raw LaTeX log from the last compile' with a specific verb and resource. Distinguishes from sibling tools like compile (which provides diagnostics) and read_file (which reads files generally).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use only when compile's structured diagnostics are not enough' explicitly prescribes when to use this tool and points to the alternative (compile). This provides clear decision guidance, similar to the TDQS example that names an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | ||
| outputPath | No | Defaults to a temp directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it compiles, saves to a local file, and returns the path, which are key behaviors. However, it omits potential side effects like overwriting files or permission requirements, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each purposeful: the first states the function, the second gives usage guidance. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description covers the core purpose, usage guidance, and return value. It lacks parameter details (already penalized) and error handling, but provides a sufficient high-level understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only covers outputPath with a default note, leaving projectId undescribed. The description adds no parameter-specific meaning, failing to explain what projectId identifies or how outputPath behaves beyond the schema, despite the low 50% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'compile and save' with a clear resource (PDF) and specifies the outcome (local file path). It also distinguishes from sibling 'compile' by indicating when to use each, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when you need the artifact itself; for fixing errors use compile instead.' This provides clear context and names an alternative tool, fulfilling the when-to-use guidance thoroughly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds a meaningful nuance: the listing reflects edits made by humans in the web UI, not just server-written files. While it doesn't explicitly state read-only behavior, the verb 'List' plus the non-mutating context implies a safe operation. The added context about human edits is valuable beyond what a simple tool description provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no fluff. It front-loads the core purpose in the first sentence and adds a valuable behavioral note in the second. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the essential behavior and even an extra data-source nuance, but with no output schema and no mention of return format (beyond 'size'), error conditions, or whether directories are included, some gaps remain. For a simple one-parameter tool, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention projectId at all. The only clue is the phrase 'in the project', which vaguely implies projectId identifies the project, but no actual guidance is given. This fails to add meaning beyond the bare schema field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists every file in the project with its size, which is a specific verb+resource action. This distinguishes it from sibling tools like read_file or write_file, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a full file listing with sizes, but does not explicitly state when to use this tool versus alternatives like read_file for individual files or delete_file for removal. It gives no explicit exclusions or alternative suggestions, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | e.g. main.tex or sections/intro.tex | |
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It correctly implies a read-only operation but does not describe return format, error behavior (e.g., file not found), or any side effects. The note about human-touched files adds context but not tool mechanics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action. Every word earns its place; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter read tool, the description provides purpose and a clear usage hint. However, without an output schema or mention of return value, the agent may need to infer what the tool returns, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (path has an example, projectId does not). The description does not explain projectId or add meaning beyond the schema's path example. It fails to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and resource ('one file from the project'), clearly distinguishing it from sibling tools like list_files and write_file. Purpose is immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Call this before rewriting a file a human may have touched, so your edit is based on current content.' This tells the agent when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | e.g. main.tex, sections/intro.tex, refs.bib | |
| content | Yes | ||
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits on its own. It reveals operational transform merging, live document updates, cursor preservation, and whole-file replacement—all valuable context beyond mere 'write.' It does not mention permissions or failure modes, but the disclosed details are significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a prominent NOTE, with a clear front-loaded purpose. It wastes no words and structures the key safety warning at the end, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (operational transform, live updates, overwrite risk), the description covers the critical behaviors and safety guidance. It does not describe return values, but no output schema exists, and this is not essential for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'path' has a description). The description adds no explicit meaning for 'content' or 'projectId,' though the note about replacing the whole file implies 'content' is the full file contents. This is insufficient compensation for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Create or overwrite a file,' which clearly states the verb and resource. This distinguishes it from sibling tools like read_file and delete_file by focusing on the write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises to 'read_file first if the content may have changed,' providing a direct alternative and a safety caveat. It implies this is the tool for creating or modifying file contents, but does not fully enumerate when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0compilecreate_projectdelete_fileget_logget_pdflist_filesread_filewrite_fileScored 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.
MCP server for agentverse documentation, generated by doc2mcp.
A MCP server built for developers enabling Git based project management with project and personal…
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
