Skip to main content
Glama

Rewrite one LaTeX section

edit_section
Destructive

Replace an entire section of a .tex file by title, rewriting from its heading to the next same-or-higher-level heading without removing trailing content.

Instructions

Replace one whole section of a .tex file, located by its title. Use replace_text for a smaller change and this to rewrite a section wholesale. The section runs from its heading to the next heading of the same or a shallower level, never swallowing trailing matter such as \end{document} or the bibliography. newContent replaces that range line for line, so it must start with the \section{...} command itself or the heading is lost, and should end with a newline to keep the blank line before the next heading. sectionTitle is compared case-insensitively with the title in braces: an exact match wins, otherwise the first heading in document order that contains it. Pulls from Overleaf first, then edits only the local clone; push_changes publishes it. Returns the heading replaced and its former line range; if no title matches, nothing changes and the reply lists the titles.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath to the .tex file relative to the project root.
projectNoWhich project to use: its Overleaf address, its 24-character id, or a registered project name. Omit to use the default project.
newContentYesThe section's full replacement text, starting with its own sectioning command, e.g. \section{Introduction} followed by the new body.
sectionTitleYesTitle of the section to replace, as it appears in the sectioning command. Matched case-insensitively, with a substring fallback. Call list_sections if unsure.
expectedRevisionNoOptional guard: the 64-character revision hash returned by read_file with mode=full or mode=smart for this same file. When given, the edit is refused if the file changed since that read — for example because pulling from Overleaf brought in a collaborator's version. Pass it whenever the edit depends on content you read earlier.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.8

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only flag it as destructive/non-idempotent/open-world; the description adds substantial behavior beyond that: exact section-boundary semantics (heading to next same-or-shallower heading, never swallowing \end{document} or the bibliography), the requirement that newContent start with the sectioning command, Overleaf-pull-then-local-edit ordering, and the no-match fallback of listing titles. This is exactly the behavioral context annotations cannot convey.

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 dense with no filler, but the single paragraph is long and packs boundary rules, parameter contracts, and return behavior into one run-on block. Slightly more structure would improve scanability.

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?

With no output schema, the description correctly explains the return (heading replaced and former line range) and the no-match behavior, and it discloses the Overleaf-pull/local-edit/push workflow. Nothing needed to invoke this destructive edit safely is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine semantics beyond the schema: exact-match-wins-then-first-containing-heading-in-document-order for sectionTitle, and the line-for-line replacement contract plus newline requirement for newContent. Only slight repetition of what the schema already states keeps it from a 5.

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 (replace/rewrite) and resource (one whole section of a .tex file, located by title), and explicitly distinguishes itself from the sibling replace_text for smaller changes. An agent can tell exactly what this does versus the other edit tools without opening a schema.

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?

Explicitly names the alternative ('Use replace_text for a smaller change and this to rewrite a section wholesale') and the condition that selects each. It also routes the follow-up publishing step to push_changes, so the whole workflow is covered.

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