Using MCP to Connect AI Assistants to Your Manuscript Safely

A long project outgrows your memory. By book three of a series you cannot hold every character's eye color, every promise a side character made, and every date on the calendar in your head. Search helps, but search only finds exact words. It cannot tell you that a character is in two cities on the same night.

This is where connecting an assistant to your project can earn its place. This post explains what the Model Context Protocol is, what connecting an assistant like Claude or Cursor to a writing project actually means, which jobs it is good at, which ones to approach carefully, and the safety habits that keep you in control. The short version: give the smallest access that does the job, review every change, keep backups, and remember that you are the author.

What MCP is, in plain terms

The Model Context Protocol (MCP) is an open protocol for connecting assistants to outside systems. A program called an MCP server exposes two kinds of things:

Resources: content the assistant can read, such as chapters, character profiles or notes.
Tools: actions the assistant can ask to perform, such as searching the project or updating a field.

An assistant app that supports MCP (the client) connects to that server. When you ask a question, the assistant can read the resources it needs and call tools to get answers, instead of relying only on what you paste into the chat.

Think of it as a controlled door. Without MCP, the assistant only knows what you copy into the conversation. With MCP, it can look things up in your project, but only through the door the server provides, and only with the permissions that door allows.

What connecting means for a writing project

When you connect an assistant to a manuscript project, a few things become true:

The assistant can read more than you paste: whole chapters, character files, timelines, notes.
Depending on the server and your permissions, it may be able to add to the project or make edits.
The content it reads is sent to the assistant's provider for processing, under that provider's terms.

That last point is the one people forget. Connecting a project is closer to sharing a folder with a collaborator than to running a spell checker. Treat it with the same care.

Good uses

The jobs where an assistant helps most are the ones that need reading across a lot of text and checking it against itself. These are tedious for people and error-prone when you are tired.

Continuity checks

Ask it to compare scenes for contradictions: a wound on the left arm in chapter four and the right arm in chapter nine, a door locked from inside that someone walks through. Ask for page or chapter references so you can verify each finding yourself.

Where was this character last seen?

"Where is Tobin at the end of chapter 22, and who was with him?" is a quick question with a connected assistant and a slow one by hand. It is especially useful when you return to a subplot after a long gap.

Chapter summaries for an outline

Summaries of existing chapters make it much easier to restructure a draft or plan an adaptation. If you are moving a novel into another medium, a chapter-by-chapter summary is the first step (see adapting a novel into a comic, screenplay or game). The same summaries are useful raw material for a story diagram of your structure.

Consistency of names, dates and terms

Spellings drift. A city spelled two ways, a title that changes, a calendar date that falls on a different weekday than you claimed. Ask the assistant to list every variant of a name and where it appears.

Building a series bible from existing notes

Many writers have years of notes scattered across documents. An assistant can draft a structured bible from them: characters, places, factions, key dates, open threads. Expect to correct it. A draft bible you fix is still faster than one you type from nothing. If your visual references are already named and tagged consistently (see organizing concept art and references for a story world), the bible can point to them too.

A sample read-only session

Here is what a continuity pass might look like with an invented series. Notice that every request asks for locations in the text, so you can check the answers.

You: List every scene where Tobin Ash appears in chapters 18 to 24.
     For each, give the chapter, the location, and who else is present.

You: In chapter 21 Tobin is in Port Ilse at dusk. Is there any scene
     in chapters 20 to 22 that places him somewhere else that same day?
     Quote the lines that establish time and place.

You: Make a list of every spelling of "Ilse" and "Ilsa" in the manuscript,
     with chapter numbers. Do not change anything.

The last line matters. Saying "do not change anything" costs nothing, even on a read-only connection.

Uses to avoid or approach carefully

Wholesale rewriting. Asking an assistant to rewrite chapters in bulk tends to flatten voice, and you lose track of what changed. If you want suggestions, ask for them on a passage you choose and edit them yourself.
Letting it decide canon. If the assistant finds a contradiction, you decide which version is true. It does not know which detail you planted on purpose.
Unreviewed bulk edits. Renaming a character across 40 chapters sounds convenient. It also catches the wrong word in places you did not expect. Review every change.
Sensitive material. Unpublished work under embargo, real people's private details, or material you have agreed to keep confidential should not go to any service until you have checked whether that is allowed.
Treating answers as facts. Assistants can be wrong with confidence, including about what your own manuscript says. Check the passage it cites.

Safety practices

Least privilege

Give the smallest access that does the job. Most of the good uses above only need to read. Prefer a read-only connection, and only grant edit access when you have a specific editing task and a way to review the result. When the task is done, step back down.

Review changes before accepting

If an assistant can edit, treat its edits like edits from a new collaborator: look at each one before it becomes part of the draft. A system that holds edits for approval is much safer than one where changes land immediately.

Keep backups and exports

Before any session where an assistant may make changes, export or back up the project. If something goes wrong, you want a clean copy from before, not a reconstruction.

Revoke access you no longer use

Connections tend to linger after the task that needed them. Remove access for assistants or devices you have stopped using. Review your connections every so often the way you would review who has a shared folder.

Do not paste secrets

Do not put passwords, access tokens or account details into a chat with any assistant, and do not store them inside your manuscript or notes where a connected assistant might read them.

Know the provider's data policies

Read how your assistant's provider handles the content you send: whether it is retained, for how long, and whether it may be used to train models. Policies differ between providers and between plans, and they change. Choose settings that match what you are comfortable with.

Check your contracts

If you have a publisher, agent, studio or client, check your contract for terms about confidentiality or the use of automated tools on the work. Some contracts address this; when in doubt, ask before connecting.

You stay the author

An assistant connected to your project can find things, check things and draft summaries. It does not know what the book is for. It does not know which contradiction is a clue and which is a mistake, which character is supposed to be unlikable, or why a scene ends one line early. Those decisions are the work of writing, and they stay with you. Use the assistant like a careful research helper whose notes you always verify, not as a co-author.

Connecting an assistant to an Aevon project

Aevon runs an MCP server so you can connect assistants such as Claude, Cursor or VS Code to your Aevon projects through the Model Context Protocol. The connection uses a personal access token that you create in Aevon's settings, under Connections, one token per app.

Each token is either read only or read and write. A read only token lets the assistant read chapters, notes, world entries and ideas. A read and write token also lets it add new ideas, world entries and notes. Neither kind can edit or delete the writing you already have, which keeps the draft itself in your hands by design.

Tokens follow your own project role, too. Aevon projects have owner, editor and viewer roles, and viewers are read-only, so in a project where you are a viewer the assistant can read but not add anything. When you create a token you can let it open all your projects or only the ones you pick, and you can give it an expiry date. That fits the least-privilege habit above: start with a read only token for one project.

If a token leaks or you stop using an app, revoke the token and every app using it loses access right away. Pair that with exports: Aevon exports to PDF, Word (DOCX), ePub and Markdown, which gives you a dated copy of the project at any point.

The exact setup steps for each app can change, so follow the current instructions in Aevon's settings, on the MCP page and in the docs rather than a screenshot from a blog post.