Skip to content
Conduit

mcp server

story-teller-mcp-wsl

Durable project context for multi-repo agentic development via MCP and AnythingLLM.

tom-kido/story-teller-mcp-wslcommunitylistedunreviewed
Use tool

Set up

Runs on your computer. Pick your agent and operating system.

This project does not publish an install method we can turn into a config. Follow the README instead.

README

synced Oct 29, 2026

story-teller MCP

Durable project context for multi-repo agentic development.

story-teller MCP is an MCP server for preserving and reconstructing project context across many coding sessions. It is designed for workflows where design, coding, infrastructure, and deployment happen in separate conversations or even separate repositories, but still need a shared memory layer.

Today, the backend is AnythingLLM. The long-term goal is backend portability, including Azure Foundry.

What Problem This Solves

When you use AI coding agents across multiple repos, the context gets fragmented quickly.

Typical failure modes:

  • one repo contains the implementation, but the design decisions live in an old chat
  • infrastructure decisions are discussed in another thread
  • deployment notes are stored somewhere else
  • when work resumes, the agent no longer knows which decisions are current

story-teller MCP treats one project as one durable thread:

  • project_id = thread name = thread slug = session identity
  • project context is stored in the backend thread history
  • get_project_context reconstructs resumable context from that history

Core Idea

Instead of storing context in local ad hoc notes, story-teller MCP uses an LLM-backed thread as the canonical memory for a project.

Each project gets:

  • a project thread
  • an initial bootstrap message
  • durable notes
  • saved summaries
  • resumable context reconstruction

This makes it possible to manage:

  • a hub project such as make_env
  • multiple derived repos
  • long-running work that spans many sessions

Current Backend

  • AnythingLLM

Current model:

  • one AnythingLLM workspace for story-teller
  • one thread per project
  • thread history acts as durable context memory

Planned backend:

  • Azure Foundry

Available Tools

  • create_project_context
  • list_project_contexts
  • get_project_context
  • append_project_note
  • update_project_summary
  • continue_project_story
  • summarize_project_context

append_project_note accepts:

  • kind=decision
  • kind=task
  • kind=risk
  • kind=memo

For tasks, status can be set to values like:

  • open
  • done
  • blocked

How It Works

1. Create a Project Context

create_project_context:

  • creates an AnythingLLM thread
  • uses the project folder name as the durable identity
  • sends a bootstrap message containing:
    • title
    • related paths
    • initial summary

2. Add Durable Notes

append_project_note writes structured notes into the project thread.

These notes are intended for things like:

  • decisions
  • open tasks
  • risks
  • handoff memos

3. Resume Work

get_project_context reconstructs project state from thread history and returns a resumable view centered on:

  • currentContext
  • latestDecisions
  • openTasks
  • notes
  • recentConversation

This is the main retrieval path for continuing work later.

4. Save Summaries

summarize_project_context asks the backend LLM to generate a resumable summary and stores that result in the same thread.

Example Use Case

A hub project:

  • make_env

Derived projects:

  • story-teller-mcp-wsl
  • foundry-agentConsole-wsl
  • mcp-resourceFinder-wsl
  • anythingllm-agentConsole-wsl

In this pattern:

  • the hub repo tracks cross-project direction
  • each child repo has its own project context thread
  • the MCP layer provides consistent retrieval and note-taking across all of them

Quick Start

cd /home/t-kido/projects/story-teller-mcp-wsl
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env

Minimal .env:

STORY_TELLER_BACKEND=anythingllm
ANYTHINGLLM_BASE_URL=http://127.0.0.1:3001
ANYTHINGLLM_API_KEY=your-api-key
ANYTHINGLLM_WORKSPACE_SLUG=story-teller-mcp
ANYTHINGLLM_MODE=chat

Run with MCP Inspector:

cd /home/t-kido/projects/story-teller-mcp-wsl
source .venv/bin/activate
mcp dev app.py

Register in an MCP client:

  • command: /home/t-kido/projects/story-teller-mcp-wsl/.venv/bin/python
  • arguments: /home/t-kido/projects/story-teller-mcp-wsl/app.py

Quick Start for AnythingLLM-backed Usage

This is the shortest path to get story-teller MCP working with an existing local AnythingLLM desktop setup.

Prerequisites

  • AnythingLLM desktop app is already installed and running on Windows
  • API key is available from AnythingLLM settings
  • a dedicated workspace exists for story-teller MCP
  • WSL can reach AnythingLLM at http://127.0.0.1:3001

1. Prepare .env

STORY_TELLER_BACKEND=anythingllm
ANYTHINGLLM_BASE_URL=http://127.0.0.1:3001
ANYTHINGLLM_API_KEY=your-api-key
ANYTHINGLLM_WORKSPACE_SLUG=story-teller-mcp
ANYTHINGLLM_MODE=chat

2. Register the MCP server in your client

Use STDIO mode with:

  • command: /home/t-kido/projects/story-teller-mcp-wsl/.venv/bin/python
  • arguments: /home/t-kido/projects/story-teller-mcp-wsl/app.py

3. Create the first project context

Example:

create_project_context(
  project_id="make_env",
  title="AI Agent Lab Hub",
  related_paths="/home/t-kido/projects/make_env,/home/t-kido/projects/story-teller-mcp-wsl,/home/t-kido/projects/foundry-agentConsole-wsl,/home/t-kido/projects/mcp-resourceFinder-wsl",
  initial_summary="Hub project for agent-related experiments and derived projects."
)

Expected result:

  • a thread named make_env appears in the story-teller-MCP AnythingLLM workspace
  • the thread receives a bootstrap message
  • later calls such as append_project_note and get_project_context use the same thread

4. Save a note and resume later

append_project_note(
  project_id="make_env",
  kind="decision",
  note="Use make_env as the long-term hub project."
)

get_project_context(project_id="make_env")

This is the core loop:

  1. create a project context
  2. save decisions, tasks, and memos into the same thread
  3. reconstruct resumable context when work continues later

Example Workflow

Create a project:

create_project_context(
  project_id="make_env",
  title="AI Agent Lab Hub",
  related_paths="/home/t-kido/projects/make_env,/home/t-kido/projects/story-teller-mcp-wsl",
  initial_summary="Hub project for agent-related experiments and derived projects."
)

Save a decision:

append_project_note(
  project_id="make_env",
  kind="decision",
  note="Use make_env as the long-term hub project."
)

Save an open task:

append_project_note(
  project_id="make_env",
  kind="task",
  status="open",
  note="Reconnect story-teller MCP after changing the implementation."
)

Reconstruct project state:

get_project_context(project_id="make_env")

Multi-repo Sample Structure

One practical pattern is to use one hub repo plus multiple child repos.

Example:

/home/t-kido/projects/
  make_env/
  story-teller-mcp-wsl/
  foundry-agentConsole-wsl/
  mcp-resourceFinder-wsl/
  anythingllm-agentConsole-wsl/

Suggested role split:

  • make_env
    • hub repo
    • cross-project direction
    • architecture notes
    • high-level coordination
  • story-teller-mcp-wsl
    • context layer implementation
  • foundry-agentConsole-wsl
    • local console app for Foundry-style agent experiments
  • mcp-resourceFinder-wsl
    • Azure resource lookup MCP server
  • anythingllm-agentConsole-wsl
    • local console app for AnythingLLM experiments

Recommended thread mapping:

  • make_env -> hub context
  • story-teller-mcp-wsl -> story-teller implementation context
  • foundry-agentConsole-wsl -> Foundry experiment context
  • mcp-resourceFinder-wsl -> MCP resource server context
  • anythingllm-agentConsole-wsl -> AnythingLLM console app context

Multi-repo Example Usage

Pattern

  1. keep high-level direction in the hub project thread
  2. keep implementation details in the child project thread
  3. use get_project_context before resuming work in any repo
  4. record important decisions and open tasks as structured notes

Example

In the hub repo:

append_project_note(
  project_id="make_env",
  kind="decision",
  note="Use story-teller MCP as the shared context layer across child repos."
)

In the story-teller-mcp-wsl repo:

append_project_note(
  project_id="story-teller-mcp-wsl",
  kind="task",
  status="open",
  note="Document the AnythingLLM quick-start path."
)

When resuming work in the child repo:

get_project_context(project_id="story-teller-mcp-wsl")

When checking project-wide direction:

get_project_context(project_id="make_env")

This gives a simple but effective split:

  • hub thread for cross-project memory
  • child thread for repo-specific memory
  • one stable project_id per repo

Output Shape

get_project_context is designed to return a resumable view of the project state, including:

  • title
  • currentContext
  • latestDecisions
  • openTasks
  • notes
  • recentConversation

This is the heart of the system.

Design Principles

  • Use the backend thread as the durable memory, not a local scratch file
  • Keep history, even when decisions change
  • Prefer the latest explicit direction over older conflicting notes
  • Make context resumable, not just searchable
  • Keep the project identity stable through project_id

Current Limitations

  • Backend is currently AnythingLLM-centered
  • Summary quality depends on the connected LLM
  • openTasks extraction is based on structured notes, not full semantic task mining
  • Output schema is still evolving

Project Status

As of April 4, 2026, this project is still at the stage of turning the core idea into a working implementation. It has not yet gone through sustained real-world validation.

That means:

  • practical usefulness is still being evaluated
  • missing features and bugs are possible
  • some ideas may turn out to be less effective than expected in day-to-day use

Please treat the project as experimental for now.

Also, due to limited time, I may not be able to respond quickly, or at all, to bug reports or feature requests. I appreciate your understanding.

These documents were generated with the help of Codex and were published without a detailed line-by-line review. Some wording or nuance may differ from how the author would personally explain the project. Please keep that in mind.

Roadmap

  • Azure Foundry backend
  • stronger structured note schema
  • better summary parsing
  • streamable HTTP support
  • MCP registry packaging
  • public examples and demos

Repository Notes

  • This repository is licensed under Apache-2.0
  • NOTICE requests attribution to the original story-teller MCP project when practical
  • .env is intentionally ignored
  • .venv and caches are ignored
  • prompt_for_LLM.txt contains the current workspace prompt used for the backend LLM behavior

Attribution Request

Modification and extension are welcome.

If you build on this project, please preserve attribution to the original story-teller MCP repository and acknowledge the original idea where practical. The formal license is Apache-2.0, and the repository also includes a NOTICE file to make that request visible.

Why Public?

This project is aimed at people exploring:

  • multi-repo AI-assisted development
  • MCP as a context layer
  • durable agent memory
  • hub-and-spoke repo workflows

If that is also your problem, this repo is intended to be practical, inspectable, and hackable.

↑↓ navigate openesc close