Novel Translation MCP Server
A local MCP server that lets Claude answer narrow questions about a novel manuscript — one chapter, one search hit, one glossary term — instead of ever re-reading the whole document.
A story of translation
My dream to be a writer started way back when I was a kid, when I read R. L. Stine's Goosebumps series and Katherine Applegate's Animorphs series. But as I became a teenager, I ended up getting into manga and anime, and over 20 years ago, there was literally a Manga genre in Fictionpress, the website I started writing stories on. You can guess what kind of stories I ended up writing the most.
As I entered university (National University of Singapore) and majored in Japanese Studies, while learning the language, I delved into Japanese light novels. My dream of being a writer also shifted, and I wanted to produce my own light novel... written in Japanese, if possible. I had a good friend from my exchange semester in Keio University — Watanabe Kazunari — and he helped me translate one of my (sadly, very badly written) light novels into Japanese. Great fun, I'm super grateful to him even though the project wasn't a success, and I hope to work with him again in the future.
Fast forward over a decade, and I'm back at it again. With the advent of AI, translation is easier, and I would like to think that I have gotten better at writing Japanese too (nah, not really... better at reading Japanese, more like). With AI models such as Claude's Opus 4.8 and ChatGPT being able to pick up cultural contexts and nuances that Google Translate couldn't, translation has become a more manageable process.
So I thought, why not write a story in English, then use Claude to translate it into Japanese?
However, here's the kicker. I believe in creative collaboration. That is to say, I'm not the lazy kind who will just hand my story over to Claude, ask him to translate it for me completely, then post it online. No. AI is an amazing assistant, but AI is not a replacement for humans. Just because AI can translate for you doesn't mean you don't need translators and interpreters. There have been breathtaking developments and progress in AI translations, but... they're still not human. They'll still miss the creative decisions, deliberate choice of words/phrases, and contextual intention that a human writer brings.
Furthermore, I can read and write Japanese. So why not take advantage of that? Human-AI collaboration. That's what we should strive for. AI and I are partners. He assists me in what I do, not replace me. He advises me if he spots a mistake. I make the judgement calls, especially when it comes to creative context and judgement, such as play on words, puns, deliberate foreshadowing, references and easter eggs that the AI has no context of.
Translation workflow
So instead of a 100% handover to Claude — what they call "fire and forget" if I'm not mistaken — I asked him to translate chapter by chapter. After he translates one chapter, I read and review it, make my changes. This can be: "No, I was making a reference here, the choice of Japanese words are deliberate." "My character meant to say this, it was on purpose." Or "this character speaks in 丁寧語, that character speaks in 普通語."
An interesting note: one of my observations is that Claude tends to translate according to what he deems "realistic." As in, "oh, this character will speak 丁寧語 to this party, but switch to 普通語 for another." But that doesn't really work in light novels and manga because character consistency. Certainly, there will be cases where the character chooses to be deferential and polite, but realism and switching between speech modes aren't really the point.
Also, he tends to miss the references and easter eggs, especially the Japanese light novel titles, or whatever meta-joke my protagonist made, and I had to correct those too.
There was also the matter of pronouns. Now this is less of an AI's weakness because I'm sure 3rd language translators like me tend to make similar mistakes too, but I notice a ton of pronouns being used. In English, lots of pronouns being used is the norm. In Japanese, it looks odd.
So that's where a human comes in, to check the naturalness of the translation, to make precise, surgical edits, after my AI assistant has done the heavy lifting and translated a whole chapter. As I said, one doesn't replace the other. It's a creative collaboration. A partnership.
That's the other aspect I enjoyed in the workflow. When I make a mistake, Claude would raise it and advise me on how best to proceed. "No, that sounds weird." Or "your changes are ungrammatical. Here's an alternative." Or "You've overtrimmed the pronouns and this sentence now lacks a subject. I suggest you add it back."
There are times when Claude acknowledges my changes are better (not sure if he's flattering me), but there are often times he helps correct my mistakes. I would like to believe this collaboration helps both of us produce a better work than either of us can do solo.
The problem
However, one thing I noticed while translating was that every time I resume my translation workflow, after booting up my computer or waking him up from sleep, is that... the first resumption prompt would immediately consume 20-30% of my 5-hour usage.
That is a lot.
Apparently, he kept rereading the full English master document every time we resume the chat, which bloated the context.
At that time, I was also working on building MCP servers for my company, and one of the things we had to address was that the AI harness of my colleagues burned a lot of tokens reading a Google Drive spreadsheet. I thought I had an MCP server or app that solved that — instead of the AI harness reading the spreadsheet directly (lots of tabs, which caused the token burn), he uses tools to fetch the relevant data from the spreadsheet instead. The app rendered the data on screen via TypeScript, while the MCP server hosted tools with similar functions for the AI client to fetch that exact same data to answer queries.
So I thought, why not apply that same principle here? Instead of the AI harness reading my 52,000+ word master document over and over again, just use tools hosted by an MCP server to read them. With that, I went about building that MCP server, again with Claude as my assistant.
It didn't work out the first time
An MCP server that returns small, targeted excerpts — one chapter, one search hit — instead of ever touching the full document is the obvious answer, and it should have cut the resume cost by roughly 10x. Instead, throughput measurably got worse — from 2-3 chapters a session down to less than one.
The server was being used inside the wrong pattern: one long-running chat, where every tool call re-sends the entire conversation history, and each context call was returning a full previous chapter (~9k tokens) that then sat in history, being re-processed on every subsequent turn.
Diagnosed by measuring actual tool-schema and payload sizes — not guessing — then fixed three ways: terser tool docstrings cut per-message schema overhead by roughly 45% (schemas ride on every message of every connected chat, so verbosity there is expensive in a way verbosity in a README is not); the context tool was changed to return only the tail of the previous chapter instead of the whole thing; and the workflow itself now explicitly teaches "one fresh chat per chapter, state lives on disk" — because a fresh chat with this server costs about 7k tokens to fully re-establish context, versus roughly 70k to re-read the manuscript by hand.
(down from ~2,500)
list_projects |
Every registered novel and its chapter counts |
register_project |
Register a new novel's Volume 1 |
add_manuscript_volume |
Register Volume 2+ without risk of dropping an earlier volume |
list_chapters |
Titles + translation status for one volume — no text |
get_chapter |
One chapter's text, optionally a paragraph slice |
get_context |
One-call bundle: source text + previous chapter's tail + glossary + session notes |
search_manuscript |
Grep across one or every volume without loading the document |
get_glossary |
Approved terms + staged terms pending human review |
propose_glossary_term |
Stage a term — never auto-commits |
record_note |
Persist a mid-session agreement so the next fresh chat inherits it |
save_translation |
Write a translation (only for a language with no master docx) |
lint_chapter |
Deterministic mechanical checks — orthography, brackets, non-words, pronoun density |
Reads the author's actual document, never a stale copy
Early design tracked one manuscript per project and treated every other language as export files the tool itself wrote. For a project where the author maintains a real Japanese master document — not throwaway exports — that meant the tool could silently drift out of sync with what the author actually wrote, auditing yesterday's copy instead of today's edit. Fixed by making any language with a registered master docx get read from that docx directly, always, and making the write tool refuse — raise an error, not a silent no-op — for a language that has one. The author's document is the only writable artifact for it; the tool never owns a second copy of the truth.
Volumes restart chapter numbering, because that's how real books work
First design assumed a Volume 2 would continue counting from Volume 1's last chapter. Correction from the author: real published volumes restart at chapter 1 — so chapter identity throughout the server is (volume, chapter number) together, reworked so chapter 1 of two different volumes resolves to two different, correct texts, including at the volume boundary (asking for context on Volume 2's first chapter correctly pulls continuity from the end of Volume 1, not "no previous chapter"). Verified with a synthetic two-volume test manuscript where both volumes genuinely have their own chapter 1.
Human-in-the-loop is enforced in code, not just prompted
propose_glossary_term has no code path that writes to the approved glossary — a
proposed term sits staged until a human explicitly promotes it. Same principle in the workflow
itself: the model checks the human's own edits with the same scrutiny as its own draft (the
translator is fluent but not a native speaker, so his prose isn't automatically correct just
because he wrote it) — approval requires two gates in order: the model's review converges with
nothing left to flag, then the human signs off. Skipping straight to human approval is exactly
how an error slips through unflagged.
The workflow ships inside the MCP protocol itself, not chat memory
The collaborative review loop — draft, judgment-call notes, human edit, re-check, approve — is
written once in a WORKFLOW.md and passed as the server's instructions field, part
of the MCP handshake every connecting client receives automatically. The workflow travels with
the tool, independent of which model or session is on the other end. A gitignored local override
lets an individual translator layer their own house rules — locked orthography, pronoun
conventions, a specific voice bible — on top of the shipped default without forking the repo.
Diagnosed a live bug across two running chat sessions
Mid-project, a second chat session — also connected to the same server — hit a bare
KeyError. Traced it to stale server processes: a dozen Python subprocesses still
running from earlier that day, several holding code from before a schema change, still
answering tool calls against a registry file the current code had already migrated. Fixed by
killing the stale processes and, separately, turning that class of failure into a clear error
message instead of a bare traceback for next time.
The efficiency of an AI Assistant
When I was an undergraduate, it took me several months to translate a story that's about 80,000 words long (or less), which equated to about roughly 236,000 characters in Japanese. And my friend, Kazu, helped me edit it, which took another few months. Of course, this was done whenever we had free time, so it probably seems slow.
However, for Reincarnator X Regressor, I was able to completely translate my 53,000 word story into about 140,000 characters in Japanese in about a week. That is the power of AI.
Now, if I had simply fired and forgot, thrown the whole master document to my good friend, Claude, and translated it in one shot, it'll probably take me even shorter. Maybe 1 to 2 days, depending on how many times I hit my 5-hour usage limit? But I didn't want to leave everything to Claude and assume his translations are completely spot on. Never mind my vision of creative collaboration — AI as an assistant, not replacement — quite frankly, even human translators make errors or misunderstand the original authors' intentions, and I'm certain they work together as Kazu and I did, checking, double-checking and confirming if I meant this with that sentence.
Now, instead of Kazu (with whom I have sadly lost contact with — if you're out there somewhere, please reach out to me!), I have Claude to help me. And Claude doesn't have to worry about his free time being used up. The workflow that took me several months now takes a week.
Keep in mind, though, that this is only possible because I can read and write Japanese. I'm not telling authors, "Hey, here's a convenient MCP server that automatically translates your light novel for you! You just need to do a back-and-forth with your AI to ensure consistency." That consistency is maintained because I understand Japanese. Because I'm a translator myself. The takeaway here, again, is that AI does not replace translators or interpreters. It simply makes our work that much faster and more efficient. I can tell you from actual experience that even Claude's translations (this is using Opus 4.8, by the way) are not perfect. Japanese is my third language, I am not a native speaker, I am a mere JLPT N2 user, and someone as incompetent as me could still spot unnatural expressions, excessive use of pronouns, and slips in the translation. That's where the human comes in. We're still needed, especially for creative collaboration. It's a completely different ballgame from translating technical documents (and even then, I would argue you had best get an actual human translator to eyeball the technical document to ensure clarity and that the explanations make sense to a human reader).
Previously, I would have taken a few months to translate everything from scratch. Now, I leave the heavy lifting to AI, review the translation myself, make surgical and precise edits (don't underestimate these surgical edits though, they will be many), get Claude to double-check my work to ensure I didn't screw up on my grammar or vocabulary, argue with him because I'm pretty sure I read this line in a light novel or heard this piece of dialogue in an anime, explain to him that this is character contextual rather than realism, and complete everything in far less time than I need before. Now I can move on to other projects... and hopefully a sequel (volume 2).
So don't dismiss the power of AI, but don't just completely rely on AI either. It's only through collaboration that we're able to craft a better product than either of us could do alone.
Get the code
Second personal MCP server, same origin pattern as the first (Webcomic Background Generator): built to fix a real, dated problem I actually hit doing my own work, not a speculative feature. Same design stance across both — AI as a collaborative partner, with the human keeping final authority.
Public from day one, and genericized before publishing: personal paths and my novel's specific title moved to a gitignored local config, so anyone can clone it and register their own book. It lives in webcomic-toolkit — a monorepo, not a single-purpose repo, alongside the Webcomic Background Generator and the Anime Production Skill (both consolidated in from their original standalone repos, full history intact). Built to keep holding the next ones — a comic speech-bubble + translation server, a publication/EPUB-assembly server, an orchestration skill — without needing a new repo each time.
View the code on GitHub →