mcp-context-window

一个为本地模型提供外部上下文缓冲区的 MCP 服务器：可持久化的会话记忆，模型可以向其中写入笔记；以及大型文档，模型可以分页浏览而无需一次性完整加载。

基于 MCP TypeScript SDK v2 构建，针对 2026-07-28 协议修订版。通过 stdio（LM Studio、Claude Desktop 或任何派生本地进程的宿主）或 Streamable HTTP 运行。

先读这个：MCP 服务器能做什么、不能做什么

没有任何 MCP 服务器能查看或修改你的上下文窗口。 MCP 严格遵循请求/响应模式——宿主调用工具，工具给出回答。服务器永远看不到对话内容，无法在消息到达模型之前拦截它们，也无法裁剪任何内容。LM Studio 在内部自行执行截断，不会就此事咨询任何服务器。

所以这不是自动滑动窗口，任何将其宣传为滑动窗口的产品都在误导你。它实际是：一个模型主动分页访问的存储区，将大部分材料保留在窗口之外，只取回所需的部分。对于 8k token 的本地模型来说，这确实非常强大——但它的生效是因为模型主动调用它，而不是因为它拦截了任何东西。

实际后果是：模型必须配合。 这里的工具描述写得具有指令性，context_guide 会返回预期的工作流程。如果你的模型忽略了这些，请在系统提示中明确说明。

一个相关说明：MCP Sampling——即允许服务器请求客户端 LLM 生成文本的机制——已在 2026-07-28 规范中弃用，官方建议"改为直接与 LLM 提供商 API 集成"。因此，本服务器自行调用 OpenAI 兼容端点。这也使其与宿主无关：同一套代码可适用于 LM Studio、Ollama、llama.cpp 或 vLLM。

Related MCP server: membot

两大部分

会话——长任务中的工作记忆

文档——太大而无法一次性阅读的材料

另有 context_guide，向模型解释工作流程。

快速开始

npm install
npm run build
npm test

node dist/index.js --ingest-root ./sources

或交互式探索：

npx @modelcontextprotocol/inspector node dist/index.js

LM Studio

通过 Program → Install → Edit mcp.json 编辑 ~/.lmstudio/mcp.json（Windows 上为 C:\Users\<you>\.lmstudio\mcp.json），然后重新加载 LM Studio。

{
  "mcpServers": {
    "context": {
      "command": "node",
      "args": [
        "/absolute/path/to/mcp-context-sliding/dist/index.js",
        "--ingest-root", "/absolute/path/to/your/project",
        "--budget", "4000"
      ]
    }
  }
}

这两个路径必须是绝对路径。 宿主以不可预测的工作目录将服务器作为子进程派生，因此相对路径无法解析。在命令行中，由于你控制工作目录，像 --ingest-root ./sources 这样的相对路径没有问题。

在 Windows 上，要么使用正斜杠（C:/Users/you/projects），要么将反斜杠加倍，因为单个 \ 在 JSON 字符串中是转义字符。

将 --budget 设置为模型上下文长度的大约一半。它是本服务器打包召回内容的目标值，不是 LM Studio 强制执行的限制。

--ingest-root 是让 doc_ingest 能够读取文件的配置。不设置它，服务器只接受内联文本——这是安全的默认值，因为一个仅凭模型一句话就打开任意路径的服务器是个隐患。

Docker

docker build -t mcp-context-window:latest .

{
  "mcpServers": {
    "context": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm", "--init",
        "-v", "mcp-context-data:/data",
        "-v", "/absolute/path/to/your/project:/ingest:ro",
        "-e", "CTX_INGEST_ROOTS=/ingest",
        "--add-host", "host.docker.internal:host-gateway",
        "mcp-context-window:latest", "--stdio"
      ]
    }
  }
}

这里有两个容易踩的坑：-i 是必需的，否则 JSON-RPC 握手永远不会发生；命名卷也是必需的，否则每次重启都会静默丢弃所有已存储的会话。从容器内部看，localhost 就是容器本身，因此 LLM 基础 URL 默认为 host.docker.internal。Docker 还要求 -v 绑定挂载的宿主机一侧必须是绝对路径。

会话的实际流程

context_open        session_id "refactor-auth"
context_append      "Goal: replace session cookies with JWT" (pinned)
context_append      "auth/middleware.ts:42 assumes a cookie is present"
context_append      "Decision: keep cookie support behind a flag for one release"
...
context_status      → 3200/4000 tokens — approaching budget
context_compact     → folds 14 old entries into one 380-token summary
context_recall      "cookie flag decision" → returns the pinned goal + the decision

以及一个文档：

doc_ingest      file_path "logs/build-failure.log"  → doc_kx91, 240 chunks
doc_search      "OutOfMemory"                       → 3 chunks, 1400 tokens
doc_window      from 118 to 121                     → the surrounding context

日志从未进入模型的上下文。三次有针对性的读取就完成了。

配置

设计说明

Token 计数针对你的实际模型进行校准。 不存在通用的分词器——Llama、Qwen 和 GPT 的分词方式各不相同——捆绑一个分词器会体积庞大且对你加载的模型不准确。因此服务器先进行低成本估算，再测量真实值：它向你的端点发送两个不同长度的样本，设置 max_tokens: 1，取两者报告的 usage.prompt_tokens 之间的斜率。斜率抵消了聊天模板的固定开销，得出每字符的真实边际成本。结果会被缓存，因此只有第一次运行是未校准的，而且它在后台运行，启动永远不会因模型可能尚未加载而阻塞。

估算值刻意偏高。低估会导致窗口溢出，截断这个服务器存在的意义就是要保护的上下文。

摘要功能降级而非失败。 如果端点不可达或没有加载模型，它会回退到抽取式摘要——TF-ISF 句子评分——这种方式即时、确定性，且在结构上不可能产生幻觉，因为它只能选择真实存在的句子。失去对已存储上下文的访问比得到更粗糙的摘要更糟糕。失败后客户端会短暂退避，因此 200 块的文档不会等待 200 次独立的 TCP 超时。

存储采用追加式 JSONL。 崩溃最多损坏最后一行，加载时会跳过该行而不是导致致命错误。用 tail 查看文件即可观察记忆的累积。压缩将原始条目标记为已取代而不是删除，因此即使压缩丢弃了重要内容，仍可从日志中恢复。

分块遵循文档结构，而非固定偏移——标题、段落和围栏代码块保持完整，每个块携带其所属的标题路径。只有真正大于整个块的块才会被硬切分。

检索采用 BM25 加时效性，不需要嵌入模型。这无需加载任何额外内容，不占用主模型旁边的 VRAM，而且是确定性的——当全部意义在于模型所见内容的可预测性时，这一点至关重要。标识符按整体和拆分两种方式索引，因此 getUserName 可以通过"user name"找到。

限制

• 模型必须实际调用这些工具。没有任何自动机制。

• 关键词搜索会漏掉嵌入模型能捕捉到的同义改写。

• 在首次校准成功之前，token 计数只是估算值。

• 两种传输方式均无认证；HTTP 因此绑定到回环地址。

• doc_ingest 读取 UTF-8 文本。它不是 PDF 或 DOCX 提取器。

许可证

MIT