原型 · 预览版:收录官方注册中心里的全部服务器,每 30 分钟同步一次。评价和账户功能将在后续阶段推出。
PopNx MCP为使用 AI 的人准备的 MCP 服务器 · 用大白话讲清楚

contextweaver

作者:dgenio版本 0.18.2i★ –i在你的电脑上运行
注册名称io.github.dgenio/contextweaver

安装

概览

作者提供的说明(英文原文)

MCP gateway: bounded tool shortlists + artifact-backed result firewall. Deterministic, no model.

PopNx MCP 的三大支柱

这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。

它能帮你做什么

我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。

  • 连接方式: 在你的电脑上运行
  • 传输方式: stdio
  • 分类: 其他

安装

选择你使用的 AI 应用,然后复制设置。

安装之前

  • 基础检查:1 项中通过 1 项
  • 在你的电脑上运行,拥有你的用户账户的权限(文件、网络、应用)。
  • 注册中心没有列出需要填写的密钥。

你需要

  • PyPI已安装 Python 的 uv(用于 uvx 命令)

你用的是哪个应用?

在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。

打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json

{
  "mcpServers": {
    "contextweaver": {
      "command": "uvx",
      "args": [
        "contextweaver",
        "mcp",
        "serve",
        "--config",
        "your-value"
      ]
    }
  }
}

在终端中运行这条命令

claude mcp add contextweaver -- uvx contextweaver mcp serve --config your-value

这个服务器需要在启动命令中填入值,请复制设置后自行填写。

或者自己复制设置

粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json

{
  "mcpServers": {
    "contextweaver": {
      "command": "uvx",
      "args": [
        "contextweaver",
        "mcp",
        "serve",
        "--config",
        "your-value"
      ]
    }
  }
}

浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。

这个服务器需要在启动命令中填入值,请复制设置后自行填写。

或者自己复制设置

粘贴到项目中的 .vscode/mcp.json

{
  "servers": {
    "contextweaver": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "contextweaver",
        "mcp",
        "serve",
        "--config",
        "your-value"
      ]
    }
  }
}

浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。

这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。

你的选择通过 Cookie 保存在这台设备上,无需账户。

这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。

它能做什么

它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。

基础检查i

我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月6日

  • ✓ 通过

    作者与仓库一致

    注册名称已通过 GitHub 账户 dgenio 验证,该账户拥有此仓库

  • … 尚未检查

    仍在维护

    我们还没有从 GitHub 读取这个仓库

  • … 尚未检查

    有许可证

    我们还没有从 GitHub 读取这个仓库

  • – 不适用

    端点有响应

    它在你的电脑上运行,没有互联网端点

  • – 不适用

    使用 OAuth 登录

    在你的电脑上运行,改用本地设置

  • … 尚未检查

    工具描述中没有隐藏指令

    它在你的电脑上运行;我们只能读取互联网端点的工具列表

与“其他”中的其他服务器比较i

  • 星标数多于此分类中其他 32451 个服务器的 0%
  • 发布到注册中心的时间比此分类中其他 32451 个服务器的 31% 更新
  • 基础检查结果等于或优于此分类中其他 32451 个服务器的 100%

与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。

常见问题

contextweaver 安全吗?

它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。

它需要哪些密钥或代码?

注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。

它在我的电脑上运行还是在云端?

它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。

它还在维护吗?

GitHub 仓库最后更新于–,最新版本(0.18.2)于2个月前进入注册中心。

哪些应用可以使用它?

支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Python (uv)。

有什么可以替代它?

同一分类中有:Spec Driven Development, Remote Desktop Commander, Recta

替代选择

同一分类中其他作者的服务器,按星标数排序。

如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i

Spec Driven Development

作者:formulahendry

MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.

在你的电脑上运行★ 440MIT14个月前更新
安装

Remote Desktop Commander

作者:desktop-commander

Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.

在云端运行★ 211昨天更新
安装

Recta

作者:RectaBuild

Cheaper cross-chain stablecoin routes for AI agents; 5 % of the verified saving, nothing if none.

在云端运行今天更新
安装

作者的 README

打开 README

按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。

contextweaver

Capture an agent's effective capability surface, commit it, and see semantically meaningful changes before deployment.

ContextWeaver is currently testing a deliberately narrow product hypothesis: capability snapshot + semantic drift.

Given an OpenAPI document, a captured MCP tools/list response, or a native ContextWeaver catalog, the D1 experiment produces a deterministic normalized snapshot that you can inspect, verify, and compare with a later candidate. It does not require a model account, a gateway, a tool executor, or the Weaver Stack.

Status: alpha, and specifically a product experiment. The implementation works and is tested; the user-value hypothesis is not yet proven. The project is actively measuring whether independent users keep this workflow after trying it on real projects.

Try the capability-drift experiment

Clone the repository and install that checkout so the maintained example fixtures and the code under evaluation are guaranteed to match:

Commands below use python3, matching the repository's documented default (docs/agent-context/workflows.md). On Windows installations that expose Python through the launcher, replace python3 with py -3; if your environment already exposes the intended interpreter as python, use that consistently.

git clone --depth 1 https://github.com/dgenio/contextweaver.git

cd contextweaver python3 -m pip install .

Run the maintained OpenAPI example:

python3 -m contextweaver.d1 snapshot examples/d1/openapi_before.json --source-type openapi --output ./cw-before.json

python3 -m contextweaver.d1 snapshot examples/d1/openapi_after.json --source-type openapi --output ./cw-after.json python3 -m contextweaver.d1 inspect ./cw-after.json python3 -m contextweaver.d1 verify ./cw-after.json python3 -m contextweaver.d1 diff ./cw-before.json ./cw-after.json

The candidate fixture intentionally:

  • makes customer_id required on the existing listInvoices capability;
  • changes its description;
  • adds a new getInvoice capability.

The diff separates capability additions/removals from changes to an existing logical capability and reports the structured paths that changed. Contract changes are separated from documentation-only changes. Changes involving fields such as required, type, or enum are flagged as potentially breaking for review.

That flag is intentionally conservative: ContextWeaver does not claim to be a complete JSON-Schema compatibility checker.

Full walkthrough: Capability drift experiment.

Use it on your own source

OpenAPI
python3 -m contextweaver.d1 snapshot ./openapi.yaml --source-type openapi --output ./capabilities.json

python3 -m contextweaver.d1 verify ./capabilities.json

After the API changes:

python3 -m contextweaver.d1 snapshot ./openapi.yaml --source-type openapi --output ./capabilities-candidate.json

python3 -m contextweaver.d1 diff ./capabilities.json ./capabilities-candidate.json

Captured MCP tools

If you already have an MCP tools/list response saved as JSON:

python3 -m contextweaver.d1 snapshot ./tools-list.json \

--source-type mcp \ --output ./capabilities.json

For MCP, D1 compares tools by their upstream logical name so an input-schema edit appears as a change to the same capability rather than an unexplained remove/add pair. The historical schema-sensitive routing ID is retained separately as normalized_id for inspection.

Capturing a live MCP server is a separate operation. snapshot, inspect, diff, and verify do not execute discovered capabilities.

Native ContextWeaver catalog
python3 -m contextweaver.d1 snapshot ./catalog.json \

--source-type native \ --output ./capabilities.json

What verify means

verify checks the D1 snapshot contract: structure, deterministic ordering, logical-ID uniqueness, and the canonical capability digest.

It is not:

  • deployment approval;
  • security certification;
  • authentication or authorization;
  • a guarantee that a tool implementation is correct;
  • routing-quality evaluation;
  • production runtime attestation.

When not to use ContextWeaver D1

A negative answer is useful evidence for this project. Do not add ContextWeaver just because capability snapshots sound tidy.

Use something simpler when:

  • ordinary Git diff, config review, and tests already make your capability changes obvious;
  • your tool/API surface is tiny and rarely changes;
  • provider-native tool search is the only problem you are trying to solve;
  • you need an agent loop, tool executor, IAM layer, or production orchestrator;
  • maintaining another committed artifact costs more than the review/debugging problem it removes.

If you try D1 and conclude that Git/tests are cheaper, that is a valid product result — please say so.

What is being tested

The current survival experiment asks a stronger question than whether the code works:

Do capability snapshots and semantic drift reports improve a real

review/manual/risk process enough that independent users keep them?

The project distinguishes:

qualified exposure

-> understood the problem -> chose to evaluate -> attempted setup -> reached first useful output -> used on a real project -> retained independently / removed

Stars, forks, downloads, a successful demo, and maintainer-created integrations are not treated as retained adoption.

The controlling product decision is tracked in #758, and the distribution quality gate is #855. Unassisted first success and retention are tracked in #658 and genuine adoption in #551.

What about routing, context compilation, and the MCP gateway?

ContextWeaver already contains substantial historical runtime functionality. That code still exists and currently shipped behavior should remain truthful and safe, but existing implementation is not evidence that the project should keep expanding it.

Two broader hypotheses are explicitly evidence-first:

  • D2 — bounded / phase-aware context compilation: conditional. It must show consequential value beyond contemporary provider/runtime-native mechanisms.
  • D3 — custom deterministic tool selection: a falsification track. It must beat modern provider-native tool search/deferred loading or a simple retrieval baseline on something target users actually care about.

During the D1 experiment, the project is not expanding routing sophistication, runtime bundle machinery, memory/session surfaces, framework breadth, gateway scope, vector stores, or model-assisted enrichment without a concrete external blocker or approved falsification experiment.

If you are maintaining an existing integration that uses those historical surfaces, the relevant documentation remains available:

  • Which historical pattern fits?
  • Context firewall
  • MCP Context Gateway architecture
  • MCP gateway security model
  • Comparison / alternatives
  • Ecosystem map

Evidence and claims

The D1 implementation supports scoped engineering claims such as deterministic snapshot construction under the documented source/adapter contract and structured semantic-diff output. It does not yet support the stronger claim that users need or retain the product.

The historical token-reduction headline is intentionally not used to sell D1. The current evidence-integrity work for those older benchmark claims is tracked in #841.

See Claims & evidence for the claim registry and Capability drift experiment for the exact D1 contract and limitations.

Python API stability

D1 is intentionally exposed through:

python3 -m contextweaver.d1 ...

rather than being promoted immediately into the historical top-level CLI or a large new public Python API. That is deliberate. The experiment should earn a permanent surface through real retained use before the project takes on another compatibility obligation.

Part of the Weaver Stack — optionally

ContextWeaver can be used standalone. It has no hard dependency on the sibling Weaver projects.

The wider Weaver Stack contains adjacent experiments/components for planning, execution boundaries, guardrails, lessons, and evaluation. That ecosystem is not required to evaluate D1, and Stack coherence is not a reason to preserve a ContextWeaver feature that does not justify itself independently.

See the Ecosystem map only if you actually need those adjacent responsibilities.

Install and compatibility

pip install contextweaver

Python 3.10–3.14 are covered by the repository CI matrix.

Current package version: 0.18.2

ProjectRelease
ContextWeaver (this repo, v0.18.2)current package release

The repository is pre-1.0. Prefer the latest supported patch release for bug and security fixes, and check the changelog before relying on historical runtime APIs.

Current roadmap

The roadmap is intentionally a product-decision sequence, not a feature queue.

MilestoneStatusMeaning
v0.18.1 — D1 survival experiment baseline✅ completeOffline snapshot/inspect/diff/verify exists; user value remains unverified.
v0.18.2✅ current (v0.18.2)D1 survival experiment and release-path recovery
D1 distribution gate🔬 evidence firstMake the front door understandable, recruit qualified evaluators, measure first success and retention.
D1 decision⏸ next decisionContinue, shrink further, or kill based on retained value after competent distribution.
D2 / D3🧪 conditionalRun only if D1 evidence or independent problem discovery justifies bounded falsification experiments.

A green CI run does not advance this roadmap by itself.

Contributing

The most valuable contributions during the survival experiment are narrow and evidence-linked:

  • a real D1 evaluator blocker;
  • a semantic-diff case that is currently misleading or silently lost;
  • deterministic normalization correctness;
  • security/release maintenance for behavior the package still ships;
  • negative evidence showing a simpler alternative wins.

Please do not add a framework adapter, routing policy, storage backend, runtime phase, or ecosystem integration solely for completeness.

See CONTRIBUTING.md and AGENTS.md for repository engineering conventions.

Security

See SECURITY.md for supported-ve

只显示了开头部分;其余内容请在仓库中阅读

问 PopNx