PaperDebugger: an Overleaf plugin that reads your LaTeX and never writes to it
A Plugin-Based Multi-Agent System for In-Editor Academic Writing, Review, and Editing
At a glance
- What is it?
- PaperDebugger is a Chrome extension plus a self-hostable Go backend that runs a Research, Critique, Revision loop over an Overleaf project. The core judgement: the read-only design is the strongest part of the pitch, and the AGPL-3.0 licence plus a backend you have to run yourself is the part to think about before adopting it.
- Who is it for?
- Adopt PaperDebugger if you already write in Overleaf and want reviewer-style critique passes that leave your .tex files untouched until you accept a suggestion. Do not adopt it if you need a tool that edits files directly, or if you cannot run or trust a backend, since the hosted path and the self-hosted path behave differently for login.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 75 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap PaperDebugger targets: chat assistants that cannot see your bibliography
A general chat model can rewrite a paragraph, but it cannot see the rest of your paper, your citation keys, or the section you wrote two days ago. PaperDebugger's stated aim is to close that gap inside the editor. The README describes it as an AI academic writing assistant that works with Overleaf and does not require leaving the editor, and the paper citation gives the fuller framing: a plugin-based multi-agent system for in-editor academic writing, review and editing.
The intended user is narrow and identifiable. Someone writing LaTeX in Overleaf who wants critique and revision suggestions in place, rather than exporting a draft into a separate chat window and pasting results back. The README lists a prompt library for custom templates, a comment system that inserts generated comments into the project, and one-click insertion of AI responses. Those features only make sense if the document is the working surface, which is why the Overleaf integration carries the product rather than sitting beside it.
The design constraint the README states most clearly is the read-only rule: PaperDebugger never modifies your project, it only reads and provides suggestions. Everything downstream follows from that. Insertion is user-triggered, comments are inserted deliberately, and nothing happens to your .tex files without an action.
Research, Critique, Revision: what the multi-agent layer actually changes
The mechanism the README puts forward is a custom MCP-based orchestration engine, documented separately under demo/xtramcp/readme.md, which the project says simulates the academic workflow Research, Critique, Revision. The claim is that this enables multi-step reasoning, reviewer-style critique and structured revision passes beyond standard chat assistance.
The distinction matters in practice. A single-prompt assistant produces one response per request. A staged pipeline can produce a critique pass that is separate from a revision pass, so the criticism is visible before any rewrite is proposed. The README also names specific capabilities attached to XtraMCP: literature-grounded research, AI-conference review, citation verification and domain-specific revision. Citation verification in particular is a task a chat assistant handles badly, because it has no view of your .bib entries unless something feeds them in.
The repository topics list both mcp-client and mcp-server, which suggests the project sits on both sides of the protocol rather than only consuming external servers. The README does not spell out the internal message flow between agents, so the exact division of labour between the orchestrator and any external MCP server is not something I can confirm from the supplied material. Treat the XtraMCP readme as the place to look before assuming a particular topology.
Backend architecture: Go, Gin, gRPC, MongoDB and an OpenAI dependency
The README's architecture section is short but concrete. The backend is written in Go 1.24 or later, with Gin for HTTP and gRPC for API traffic, MongoDB as the database, the OpenAI API for model access, Protocol Buffers across a microservices layout, and JWT authentication with OAuth support.
That stack tells you what self-hosting costs. You need a Go toolchain recent enough for 1.24, a MongoDB instance, and an OpenAI API key, because the README names OpenAI as the AI integration rather than describing a provider-agnostic layer. There is no mention of a local model path. If your institution forbids sending manuscript text to a third-party inference API, the architecture as documented does not offer an obvious way around that, and the privacy claim in the feature list should be read as covering modification of your project, not as a statement about where inference happens.
The split between Gin and gRPC also hints at two client surfaces: browser-facing HTTP from the extension and service-to-service calls internally. The README does not enumerate the protobuf services, so anyone planning to build against the API should read the .proto definitions in the repository rather than working from the README alone.
The frontend half is TypeScript, which matches the repository's primary language. The extension ships through the Chrome Web Store, and the README links a store listing for installation.
Installing it, and pointing the extension at your own backend
The user path is deliberately short. Install the extension from the Chrome Web Store, open any Overleaf project, click the PaperDebugger icon at the top left, and start chatting with the LaTeX document. No configuration is described for that path.
The self-hosted path is where configuration appears, and it is not standard. The README instructs you to open the extension, go to Settings, and click the version number five times to enable Developer Tools. Only then does a Backend Endpoint field appear, where you enter your backend URL. After that you refresh the page.
Two consequences follow. First, the endpoint field is hidden behind a gesture that resembles a debug unlock, so it is not a supported-looking setting in the ordinary sense. Second, the README states plainly that login by Overleaf is only available if you are self-hosting the backend. A user on the hosted service and a user on their own backend therefore do not have the same authentication options, and that asymmetry is worth understanding before you commit to either.
The README also notes that if endpoint errors appear after refresh, you should use the Advanced Options at the bottom of the login page to reconfigure. That is a recovery instruction, which implies endpoint misconfiguration is a known state rather than an edge case. For the backend itself, the README defers to docs/DEVELOPMENT.md rather than reproducing setup steps, so the build and run commands live there and not in the README.
Where PaperDebugger is the wrong tool
The read-only guarantee is also the main functional limit. If your workflow is scripted editing, bulk find-and-replace across a large project, or automated reformatting of a bibliography, PaperDebugger is not that. It reads and suggests, and the README is explicit that it does not modify your project. Anything requiring programmatic writes has to come from somewhere else.
The second limitation is environmental. The extension is distributed through the Chrome Web Store, so the hosted path assumes a Chromium browser and an Overleaf session. The README does not describe a Firefox build, a desktop client, or an offline mode.
The third is the backend dependency. Even with the extension installed, the system needs a reachable backend and, per the architecture section, an OpenAI API key behind it. A self-hosted deployment therefore carries an ongoing external dependency on a paid inference API, and the README does not document a fallback. The community section is candid about maturity in its own way: it says the team is working to improve long-term reliability and hopes to iron out issues this month. That is a project describing itself as still settling, and the release history is consistent with rapid iteration, with v2.12.28 in January 2026 following the open source release v2.9.8 in August 2025.
Finally, the README gives no benchmark, no accuracy figure, and no evaluation of suggestion quality. There is an arXiv paper cited, which is where any such evidence would live, but nothing in the repository material quantifies how good the critique passes are. Anyone evaluating this on output quality has to run it on their own manuscript.
How it differs from a generic chat assistant bolted onto the browser
The obvious alternative is a general chat assistant used alongside Overleaf: copy a section out, paste it in, ask for a review, paste the result back. The difference is not model quality, since PaperDebugger itself calls the OpenAI API. The difference is what surrounds the model.
A chat assistant has no persistent view of the project. PaperDebugger, by sitting inside Overleaf through the extension, can read the document as it stands and insert results back into it, including generated comments. The README's comment system and one-click insertion are the concrete expressions of that. In a copy-paste workflow, the insertion step is manual and lossy; here it is a button, and the insertion target is the project you are already editing.
The second difference is orchestration. The README frames the MCP engine as staging the work into research, critique and revision rather than answering a single prompt. Whether that produces better output than a well-written prompt in a chat window is not something the supplied material answers. But the structural difference is real: separate passes mean you can see the critique before accepting a revision, which a single-response chat turn does not naturally give you.
A third alternative worth naming is doing nothing automated at all and relying on a human co-author or reviewer. That remains the highest-quality option for a submission deadline, and PaperDebugger's reviewer-style critique is best treated as a first pass that reduces what a human reader has to catch.
Licence, maintenance and what to check before you depend on it
The project is licensed AGPL-3.0. That is a copyleft licence with a network clause, which matters here because PaperDebugger is explicitly designed to be self-hosted as a backend service. If you modify the backend and let other people use it over a network, the AGPL's source-disclosure obligations are the thing to read carefully. I am not in a position to give legal advice, and the specifics depend on how you deploy it, so treat this as a pointer to the licence text rather than a conclusion.
Maintenance cost is dominated by the pieces you would run yourself. Go 1.24 or later, MongoDB, and the OpenAI API are all moving targets, and the README gives no compatibility matrix or pinned versions beyond the language requirement. The release cadence suggests the project moves quickly, which cuts both ways: fixes arrive, and so do changes you have to track. The README's own note that reliability work is ongoing is the most honest signal available about where the project is.
The version number in the README's badge and the release list are two different things to watch. If you self-host, keep the extension and the backend on versions you have actually paired, because the README's endpoint troubleshooting section exists precisely because the connection between the two can break. Start by reading docs/DEVELOPMENT.md for the backend and demo/xtramcp/readme.md for the orchestration layer, since the README itself defers to both.
Editorial conclusion
Adopt PaperDebugger if you already write in Overleaf and want reviewer-style critique passes that leave your .tex files untouched until you accept a suggestion. Do not adopt it if you need a tool that edits files directly, or if you cannot run or trust a backend, since the hosted path and the self-hosted path behave differently for login. Before installing, verify two things on your own copy: that the extension version matches the backend version you point it at, and that the Developer Tools toggle and Backend Endpoint field in Settings behave as documented on your build.
Community notes