The optimal solution IMO would be that Scrivener supports applescript, and would therefore plug in easily to other tools. Even better for LLMs/agents specifically would be that it added an MCP server — a formal and well understood method for LLMs/agents to plugin in to a data source. For example my preferred reference manager Bookends will add an MCP server soon, and that gives a direct route to plug in reference data, annotations from PDF and automate LLM interactions. This means Scrivener doesn’t need to become an AI focused editor or offer a bunch of user-facing dodads, but allows other tools to work with it in the background.
I use markdown exclusively, and love its flexibility and ubiquity. Scrivener is still the best markdown tool that exists, even though its editor is RTF-only IMO. This sounds crazy at first glance, but styles+compiler gives me more power than any of the zillion markdown writing tools can (and Scrivener’s project management still outclasses anything else). One may argue they are more “streamlined” for markdown, but they are not more “useful”…
We have asked for a scriptable Scrivener for a long time, and I think adding an MCP server fits in a similar problem space so it will depend on @KB — good news for developers these days is that coding agents can work well on a large codebase like Scrivener, they handle Swift and can pump out an MCP probably in a single session.
I had AI create a Scrivener skill that will translate RTF back and forth. It reads the rtf files directly, converts them, to something it works best with, then converts them back. I put limits on what it will do since I want something that’s simple, easy to maintain, and consistent. It’s working very well so far.
The only problem is that Scrivener doesn’t see the changes to the documents unless I exit and then restart Scrivener. If there was a “Refresh” or “Reload” option for a single document (maybe button on the toolbar and right-click menu item), or a file watch feature, or a way to tell scrivener to reload just that document externally, that would be really helpful.
An approach like this would work for both Mac and Windows, while at the same time, staying independent of other software.
Seems you have partly recreated this 3rd-party MCP server:
I haven’t looked in detail about how @writerslogic solution handles Scrivener’s custom RTF syntax for styles etc. (RTF doesn’t support them natively, so general RTF tools don’t work properly when Scrivener uses those features)… Did you address this specifically?
If KB published a clear spec for Scrivener’s RTF variant then we could be sure that these bespoke RTF handlers “should” understand the current Scrivener way of writing RTF.
You’re correct that Scrivener’s styles aren’t native RTF, and that’s exactly where generic RTF tooling falls over. Scrivener leans on named paragraph/character styles (the \stylesheet table plus \sN/\csN references) and its own {\Scrv_…} control groups for annotations, comments, footnotes, and inline metadata. A general RTF reader/writer either ignores those or, worse, silently discards them on write-back — so the moment an AI tool “edits” a document, the styles and Scrivener-specific markup are gone.
This is fundamentally a write-path problem, not a parser-completeness problem. You can build the most complete RTF reader in the world, but if editing means “regenerate the document from a simplified model,” you lose everything the model didn’t capture. So instead of round-tripping through a lossy representation, we treat the original RTF as the source of truth and splice only the spans that actually changed. Everything untouched is preserved byte-for-byte, and an edited paragraph inherits its original style. We verify this with byte-identical round-trip tests against real Scrivener projects, including documents that use custom styles, footnotes, and embedded images.
Without a published spec from L&L, this is reverse-engineered from real .scriv files, so we’re careful to frame it as best-effort tracking of the current Scrivener writer rather than a guarantee. The honest boundary: everything you don’t edit is preserved exactly; a wholesale rewrite of a passage can’t preserve inline styling anchored to text that no longer exists (that’s true of any editor). A clear KB spec would let us harden the edge cases and drop the “reverse-engineered” caveat, and we’d happily align to it if one were ever published.
I think your span-local step-carefully strategy makes sense. However this problem space is quite well understood — abstract syntax tree (AST) can parse an input to an abstract internal representation and as long as they match the features you want to preserve, then an output should be robust. This is how Pandoc and other input-output parsers work. An AST for Scrivener RTF is probably doable… However this still works best when having a stable representation that a spec would provide…
I had the AI first examine the data, and then run validation tests during the skill creation, and from what I can tell, it’s working without issue. Things I had it block are tables, and a few other things. I had the skill bar whatever it wasn’t positive about.
In my own writing I never touch formatting– no italics, no bold, not even font size changes. That being said, the skill appears to be able to preserve those things. I’m not too worried about supporting everything, just what I need for my workflow.
I don’t tell the skill to write to any of the files in the Manuscript folder since that’s the one thing I don’t want to lose by accident. I also don’t want it writing any prose anyway.
As noted in your other thread, editing the contents of a Scrivener project with any tool other than Scrivener itself is unsupported and entirely at your own risk.
The Sync with External Folder function, which is supported, can be instructed to work with plain text if desired.
strategy makes sense. However this problem space is quite well understood — abstract syntax tree (AST) can parse an input to an abstract internal representation and as long as they match the features you want to preserve, then an output should be robust. This is how Pandoc and other input-output parsers work. An AST for Scrivener RTF is probably doable… However this still works best when having a stable representation that a spec would provide…