Skip to main content
Glama
yangzichao

mcp-server-overleaf

by yangzichao
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Delete a project file

delete_file
Destructive

Delete a file from an Overleaf project's local clone, staging the removal for the next push so co-authors keep the file until it is published.

Instructions

Delete a file from the project. The file is removed from the local clone only: it stays in Overleaf, and co-authors keep seeing it, until push_changes publishes the removal. Until then discard_local_changes brings it back, and show_diff shows the pending deletion. Deleting a file a co-author still cites or includes will break their compile, so confirm it is unused first with search_project on its path or label. To replace a file's contents instead, use write_file. path is relative to the project root, as list_files prints it; a directory is refused, and a file sparse checkout keeps off disk is still deleted from the project. Pulls from Overleaf first. Returns a confirmation, or says the path is not in the project and deletes nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath of the file to delete, relative to the project root, e.g. sections/old-draft.tex. Directories cannot be deleted, only files.
projectNoWhich project to use: its Overleaf address, its 24-character id, or a registered project name. Omit to use the default project.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.8

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds rich context beyond the annotations: removal is local-only until push_changes, is reversible via discard_local_changes, runs a pull first, refuses directories, still deletes sparse-checkout files, and returns a not-in-project message deleting nothing. Annotations cover destructive/openWorld; the description carries the real behavioral burden and does it well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and its local-only scope, then layered with undo, sibling routing, safety warning, and return behavior. Slightly dense and long, but each sentence carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation with no output schema, it covers scope of effect, reversibility, publishing dependency, preconditions, edge cases (directories, sparse checkout, missing path), and return behavior. Nothing an agent needs to call safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and already documents path (relative to project root, directories refused) and the project selector. The description reinforces 'relative to the project root, as list_files prints it' but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (delete a file from the project) and immediately scopes the semantics: local clone only, latent until push_changes. The 'To replace a file's contents instead, use write_file' clause distinguishes it from the nearest sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear precondition (confirm the file is unused via search_project on path or label) and names alternatives (write_file to replace, discard_local_changes to undo, show_diff to inspect). No explicit when-NOT-to-use framing, but the routing to siblings is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools