Guide · 13 August 2026

Give Claude memory of your novel

Claude does not know your book. It knows what is in the conversation in front of it, and when that conversation ends, most of it goes. Open a new chat tomorrow and you are introducing your protagonist again, pasting the magic system again, explaining again why the innkeeper is dead.

Two things stop it, and they are not equally good. One is a Project with your bible attached. The other is a connector, which lets the model query a record instead of reading a copy. This page covers both, and what Claude carries between conversations on its own. Most of it applies whatever you keep your bible in.

Claude has three memories, and none of them is a record

The conversation itself. Everything in the current thread is available to the model, in full, exactly as written. It is the most reliable memory you have and the one you cannot keep. When the thread ends it takes the lot with it.

Project knowledge. A Project holds reference documents that persist across every conversation inside it. Attach your bible as Markdown or Word and every new chat in that Project starts with it. The context window is now large enough that a substantial series bible simply fits.

Memory across chats. Claude also carries things forward between conversations on its own. This is summarised rather than stored whole, and it is not authoritative. It is good at remembering that you write close third person and hate the word "smirked". It is not where you keep a number.

Why the summary drifts

A summary keeps what looked important when it was written. Your world's important facts are not the memorable ones. Nobody summarises "Fitz has eleven copper and a stolen ledger", because on the day it happened it was a throwaway line. Sixty chapters later it is the reason a scene works.

The expensive part is what happens at the gap. A model reading prose does not experience an absent fact as absent. It reaches for the most plausible completion and hands it to you in the same confident voice it uses for everything it actually knows. You get an answer. You do not get a flag. In progression fiction, where readers check the maths, that is not a typo you catch in copy edits.

Set the Project up properly before you add anything else

Before any of the connector work below, a well-built Project gets you further than most writers expect. What matters:

• One Project per series, not per book. Book seven contradicts book two, not chapter four.
• One bible file, not fifteen. Retrieval across many small documents is fuzzier than retrieval within one well-organised document, and you only have to keep one thing current.
• Headings the model can quote back. Kaelen — status as of chapter 61 is findable. Notes 3 is not.
• One fact per line for anything numeric. Levels, coin, distances, dates, ages. Prose hides numbers; lists do not.
• Write down what is undecided, in the file, marked as undecided. A model told "the Sunder's origin is not yet fixed" will ask you. A model told nothing will invent one.
• Replace the file when you update it rather than adding a second copy. Two versions of the same bible is worse than one stale one, because now the contradiction is inside the source.

Then start each drafting conversation by asking Claude to read the bible back to you for the character in the scene. Ten seconds, and it surfaces a stale line before it reaches the page.

Project knowledge is a photograph

Here is where it stops. Attached files are a snapshot of the moment you uploaded them. The model reads what you gave it, and it cannot write anything back. When Fitz spends the last of her coin in chapter 63, you edit the bible, export it, and re-upload it. Claude cannot record the change itself, and until you do, its answer to "how much does Fitz have" is confidently wrong.

A Markdown bible also cannot be queried. "What level was she in chapter 40" is not a question a document answers; it is a question you answer by reading, and the model approximates. There is no timeline object, no stat block, no ledger, nothing to validate against and nothing to diff. At a hundred chapters the contradictions accumulate quietly, and the place you eventually find them is a review.

The break-even is the week re-exporting the bible becomes a chore you start skipping.

What a custom connector changes

Claude supports custom connectors over remote MCP. Instead of reading a file you uploaded, the model calls a server you have authorised, live, at the moment it needs the answer. Nothing to re-upload. If the server allows it, the model can also write state back, so the thing you established in chapter 63 is recorded as you draft rather than a fortnight later when you remember.

Connectors are available on every Claude plan: one on Free, uncapped on Pro, Max, Team and Enterprise. Check the current position on claude.com/pricing before you plan around it, because this is exactly the kind of limit that moves.

Connecting a remote MCP server

What you need is a URL. Remote MCP servers publish an endpoint, often ending in /mcp, and that string is the whole of the configuration on your side.

1. Open Claude's settings and find connectors. The exact wording of this menu moves between releases, so look for the word "connectors" rather than for a particular button you saw in a screenshot.
2. Add a custom connector and paste the server's URL.
3. Approve the connection. A server that keeps accounts will send you to its own sign-in page, so access is granted there rather than by handing Claude a password.
4. Turn it on only where you draft. A connector every chat can reach is a connector every unrelated chat can read your manuscript through.
5. Test it before you trust it. Ask a question you know the answer to and one you know is not recorded. The second is the useful one.

The connector runs from Anthropic's cloud, which means the server has to be publicly reachable.

That constraint decides which tools can play. A hosted server works from claude.ai in a browser, from the phone app, from anywhere you are signed in. A local MCP server does not: the Obsidian MCP plugins and the community bridge for Scrivener projects both run on your own machine, so they need a local client such as Claude Desktop, Claude Code or Cursor sitting on that machine with them. That is a genuine trade rather than a flaw. Local means your manuscript never leaves your disk. It also means the memory is only there when that disk is.

What to ask once it is connected

The instinct is to ask it to write. Ask it to check instead, at least for the first week. Questions worth asking, using the cast from the front page:

• What is in Fitz's inventory as of chapter 61?
• What did Dottie know in chapter 4, and who told her?
• List every skill Kaelen has unlocked, with the chapter each one happened in.
• I am about to write Kaelen and Fitz in the Ashfall tap room. What does each of them already know about the other, and what does neither of them know yet?
• Which named characters have appeared in more than one chapter and never been described?
• What has the text promised the reader that it has not yet paid?
• Here is chapter 62. What changed: experience, wounds, coin, who now knows what?

That last one is the habit worth building. Draft the scene however you like, then hand it back and have the state recorded while the scene is still in your head. The alternative is reconstructing chapter 62 in January.

One thing to watch for, because it tells you whether the setup is working: a good answer sometimes says "not recorded". A model reading prose will nearly always produce something. A structured record can come back empty, and empty is the answer you need before you write a number into a published chapter.

When a file is enough

For a standalone novel, or the first two books of a series, a Claude Project with a well-maintained Markdown bible genuinely works. It costs the twenty dollars a month you are probably already spending, there is no second tool to learn, and if your world fits in a document you can re-read in ten minutes, a connector is overhead you do not need yet.

Be honest with yourself about scale rather than ambition. Ninety thousand words and a cast of twelve is a file. A hundred chapters, four point-of-view characters, a magic system with numbers in it and a timeline that has to survive being reordered is not a file, and pretending otherwise is how the bible quietly stops being updated.

If you want the server rather than the file

New Quest is a story bible that is also a remote MCP server. Characters, stat blocks, locations, scenes, timeline and world state as structured, queryable data, at a URL you paste into the connector dialogue above. It writes none of your prose and never trains on it. The free tier covers one book, which is enough to find out whether any of this changes how you draft.

Join the Guild · $29/mo →Or the app alone · $39/mo

Set the Project up properly either way. Most of the improvement comes from the file being tidy, not from what reads it.