Support for external text-based files for context & World Info management

[denchik-stodevynostopyaty]

It would be great to have support in the internal Lite web UI for associating individual text fields (main story context, specific World Info entries, System Prompt, Author's Note, etc.) with external text-based (.md/.txt/.py/etc.) files. This would enable bidirectional (or one-way) synchronization.

This approach could help prevent internal rigid feature bloat by integrating better with external tools, similar to the recent MCP tool calling integration I really like, it also allows to reach easier where It could only barely do before.

Key benefits:

• Easier automation: Scripts/agents with filesystem access could modify prompts or World Info without needing full API integration. This can drastically reduce reprocessing in some cases (due to replacing expensive tool calls where a simple file watcher script with regex would go), plus compared to the tool call that is only done in the beginning of an AI response, they would enable a cheap post-response automation.
• Better token economy and context management (restructuring entries, removing old tool calls, etc., beyond current in-turn regex limits).
• Native version control via Git — track changes to World Info or story, roll back prompts, or share world-building files via repositories instead of bulky JSON exports.

Proposed UX:

• Drag-and-drop for example a .txt file onto a field → optional association.
• Manual "Link to file" button with path input (relative or absolute, with safeguards).
• Toggle for auto-sync (on blur/save, or periodic).
• Visual indicator (e.g. "Synced to file.md") + manual sync buttons.
• Fallback to internal storage if the file is unavailable.

Implementation notes: Keep it fully optional and disabled by default for security/portability. Could start with read-only or one-way import if bidirectional is too complex.

This would greatly enhance extensibility for advanced users while keeping the default experience unchanged. I'm happy to help test or discuss implementation details.

From what I understand, it would be a huge pain to make in frontend-only, but the backend implementation looks much more feasible.

My personal use cases would be:

• Partial synchronization between two instances: while one (big and slow) does the code planning and task formulation, other (small and fast) will make expensive tool calls (file read/edit, web search, etc.) without making the big model reprocess the whole context (since it only receives tool calls as a text result, they will be treated just like a simple new appends).
• World Info automation/RPG stat system: Similar to SillyTavern extensions and RisuAI characters but much less hardcoded and more customizable while being simple, it could carry the updatable inventory/event/location/skill/status system (probably using regex or tool calls updating a specific world info entries).
• Notes automation: Having my Obsidian Kanban .md file in memory, it could read/modify the cards, organizing and summarizing without manual intervention

[jabberjabberjabber]

If the backend can modify the file system by taking requests from the UI, isn't that a huge security issue?

[denchik-stodevynostopyaty]

Agree with security concerns, though if being disabled by default in backend, this looks like a fair trade-off even in the raw implementation, but only if warned

UPD: added possible solution in newer comment

[denchik-stodevynostopyaty]

Correct me if I'm wrong, I might be too excited with the idea to see the obvious problems

[denchik-stodevynostopyaty]

One potential solution to the security concern would be restricting access to a dedicated workspace directory, similar to how the filesystem MCP currently handles file access

[denchik-stodevynostopyaty]

If a user wants to sync a file from elsewhere, they can use a simple local script to copy that file into the workspace. In this way, any potential security breach is contained within the sandbox, and the responsibility for accessing sensitive directories stays with the user’s own controlled environment

[jabberjabberjabber]

Yes, all security concerns can be mitigated. I guess the question is what the qualifications are for opening them up. One could argue that MCP is not only a standard, but that it could achieve your goals on its own without exposing to extra risk beyond what it already poses.

[denchik-stodevynostopyaty]

Yes, all security concerns can be mitigated. I guess the question is what the qualifications are for opening them up. One could argue that MCP is not only a standard, but that it could achieve your goals on its own without exposing to extra risk beyond what it already poses.

I see your point, but I think there is a fundamental architectural distinction here: MCP is for agentic actions, while my proposal is for context management.

The issue with relying solely on MCP is that every tool call appends new turns to the conversation history. This leads to massive context bloat and for some reason also requires full context reprocessing despite the current optimizations. MCP operates within the chat stream; it cannot reach back and modify the conversation history to "clean up" after itself or modify specific structural slots like the System Prompt, Author's Note, or World Info entries, which sit at different positions in the prompt hierarchy.

My goal isn't to replace MCP, but to complement it. By allowing external file synchronization for those specific internal slots, we can achieve pre-inference context manipulation. This allows us to update the underlying state of the prompt without for example adding old messy tool call logs to the turn history, providing a level of context optimization and structural control that tool calling is architecturally incapable of providing by itself.

[LostRuins]

MCP operates within the chat stream; it cannot reach back and modify the conversation history to "clean up" after itself or modify specific structural slots like the System Prompt, Author's Note, or World Info entries, which sit at different positions in the prompt hierarchy.

Well, yes, past turn information is available in context, which does include tool calls. I suppose the idea is that your "session" contains less information, and the "database" contains far more information, and the "agent" retrieves whatever it needs for that session (which become context), after which said agent is discarded/cleared.

[denchik-stodevynostopyaty]

MCP operates within the chat stream; it cannot reach back and modify the conversation history to "clean up" after itself or modify specific structural slots like the System Prompt, Author's Note, or World Info entries, which sit at different positions in the prompt hierarchy.

Well, yes, past turn information is available in context, which does include tool calls. I suppose the idea is that your "session" contains less information, and the "database" contains far more information, and the "agent" retrieves whatever it needs for that session (which become context), after which said agent is discarded/cleared.

I think there’s a misunderstanding of my goal. What you're describing sounds like a RAG-style architecture where an agent always retrieves info, but that introduces significant overhead. The proposed approach is to allow the context sanitization and more effective organization by optional selective externalization of the context elements such as chat history, World Info, Memory, System Prompt, Author's Note, etc.

So they are still present in the context, but instead of only manually editing them, we could let the custom scripts or MCP tools to do this job. For example, this could allow the user to write a script that deletes the tool call turns past last 3 from the conversation, heavily freeing the context without manually removing the lines.

From the MCP side, there is more potential in dynamic memory editing (character/world entry, system prompt or author's note after user have explicitly asked them to behave or narrate differently), so instead of blunt auto generating memory, it optionally could let the user have their existing info modified in a more targeted discreet manner.

[LostRuins]

Why not write a simple world info / memory database MCP plugin? It should be very easy to integrate, and would work plug and play for saving/reading large data structures.

[denchik-stodevynostopyaty]

Why not write a simple world info / memory database MCP plugin? It should be very easy to integrate, and would work plug and play for saving/reading large data structures.

Could this plugin seamlessly retrieve the save file, edit and load it back in active session? I was trying to make something like this before, but couldn't find a proper API endpoint to do so

[LostRuins]

Hmm, unfortunately not in that way, because the MCP server runs on the server, and KoboldAI lite is entirely browser based (runs purely in the client browser) so your MCP would not be able to directly "modify" player sessions easily.

I can see the benefit though. Right now, there is a some limited "networkable save capabilities" through the --savedatafile system. I might expand that to include a shared "scratch pad memory" that allows persistent saving and loading text from. That could then be read and inserted into memory by MCP tools or similar. Would that be useful? Seems a little convoluted tho