Skip to main content
Glama

Surgical find-and-replace in an Overleaf doc

find_and_replace

Replace a substring with new text in an Overleaf document, optionally replacing all occurrences and tracking changes. Ideal for single targeted edits without re-emitting the whole file.

Instructions

Replace one occurrence — or all, with replace_all: true — of old_string with new_string in a doc, without re-emitting the rest of the file. By default old_string must be unique; ambiguous matches are returned with line:column locations so you can extend the match. Submits the minimal OT operation through the same pathway as edit_file, so by default it lands as a pending suggestion in Overleaf's Review panel (track:'on'). If path is omitted, defaults to the project's root doc. USE WHEN: a SINGLE targeted edit (one typo, one label rename, one heading change) in a large doc — saves tokens vs. re-emitting the body and avoids accidental whitespace drift. AVOID FOR BATCH WORK: for multiple substitutions (e.g. converting many words, applying a style guide across a chapter) prefer ONE edit_file call with all changes computed client-side. Each find_and_replace is its own round-trip with its own race window, its own tracked-change entry, and its own cache-sync cycle — calling it N times for N small changes amplifies the failure modes that one batched edit_file would avoid.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoProject-relative path of the doc to edit, e.g. 'main.tex'. If omitted, defaults to the project's root doc.
trackNoTracked-changes mode. This is a client *request*, not a guarantee — when the project has `track_changes_on_for_me: true` (visible in `open_project`'s response), the server forces tracking regardless of what you pass, and the tool response will report `tracked: true, track_overridden: true`. Don't tell the user 'this will be untracked' without first checking that flag from `open_project`. Modes: 'on' (default) — explicitly request tracking; edit lands as a pending suggestion in Overleaf's Review panel. 'off' — request a direct untracked write (may be overridden as above). 'auto' — track iff the project's tc setting says so.on
new_stringYesReplacement text. May be empty (effectively a delete).
old_stringYesExact substring to find — must match byte-for-byte including whitespace. Must be unique in the doc unless `replace_all` is true.
replace_allNoIf true, replace every occurrence of `old_string`. If false (default), `old_string` must match exactly once — multi-match returns a list of locations so you can disambiguate with a longer `old_string`.
strict_versionNoIf true, re-fetch the doc version before sending the edit and refuse if the cached baseline is stale. Catches races from parallel agents (each MCP process has its own cache) or a concurrently open Overleaf web editor at the cost of one extra round-trip. Without this, the server's OT transform handles stale-version edits silently, which can land the op in an unexpected location or collapse it to a no-op. Recommended when several agents may be editing the same project.
expected_versionNoOptional safety check. If the doc's current version differs, the edit is rejected.
Behavior5/5

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

With no annotations, the description discloses key behaviors: track:'on' default lands as pending suggestion, uniqueness requirement, ambiguity handling, OT operation minimalism, path default, race windows, cache-sync, and version checking. It also notes that track is a request not a guarantee (via schema, but description references).

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

Conciseness5/5

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

The description is front-loaded with a clear summary, then structured into 'USE WHEN' and 'AVOID FOR BATCH WORK' sections. Every sentence adds value—no fluff. Length is justified by the tool's complexity.

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

Completeness4/5

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

For a tool with no output schema and no annotations, the description covers purpose, usage, edge cases, and trade-offs thoroughly. It does not enumerate response fields, but it provides sufficient context for an agent to decide when and how to invoke it. Minor gap: no explicit mention of success response structure, but the provided detail is strong overall.

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 covers all 7 parameters with detailed descriptions (100% coverage). The description adds some behavioral nuance (e.g., ambiguity resolution) but largely restates schema semantics. 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?

The description opens with a precise definition: 'Replace one occurrence — or all, with replace_all: true — of old_string with new_string in a doc, without re-emitting the rest of the file.' It clearly differentiates from edit_file by positioning itself as the surgical single-edit tool, and explicitly contrasts with edit_file in the usage guidance.

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

Usage Guidelines5/5

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

Provides explicit 'USE WHEN' and 'AVOID FOR BATCH WORK' sections. It names edit_file as the alternative for batch work and explains trade-offs (round-trips, race windows, tracked-change entries).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/netique/overleaf-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server