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

agentsync

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

安装

概览

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

Multi-agent coordination MCP: claim work, survey peers, resolve conflicts via a git branch as CAS.

PopNx MCP 的三大支柱

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

它能帮你做什么

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

  • 连接方式: 在你的电脑上运行
  • 传输方式: stdio
  • 分类: 开发者工具

安装

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

安装之前

  • 基础检查:1 项中通过 1 项
  • 在你的电脑上运行,拥有你的用户账户的权限(文件、网络、应用)。
  • 需要你自己填写: AGENTSYNC_REPO, AGENTSYNC_AGENT_ID, AGENTSYNC_BRANCH

你需要

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

你用的是哪个应用?

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

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

{
  "mcpServers": {
    "agentsync": {
      "command": "uvx",
      "args": [
        "agentsync-mcp"
      ],
      "env": {
        "AGENTSYNC_REPO": "your-value",
        "AGENTSYNC_AGENT_ID": "your-value",
        "AGENTSYNC_BRANCH": "your-value"
      }
    }
  }
}

在终端中运行这条命令

claude mcp add agentsync --env AGENTSYNC_REPO=your-value --env AGENTSYNC_AGENT_ID=your-value --env AGENTSYNC_BRANCH=your-value -- uvx agentsync-mcp

运行前请先填写空着的值。

在 Cursor 中打开

或者自己复制设置

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

{
  "mcpServers": {
    "agentsync": {
      "command": "uvx",
      "args": [
        "agentsync-mcp"
      ],
      "env": {
        "AGENTSYNC_REPO": "your-value",
        "AGENTSYNC_AGENT_ID": "your-value",
        "AGENTSYNC_BRANCH": "your-value"
      }
    }
  }
}

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

在 VS Code 中打开

或者自己复制设置

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

{
  "servers": {
    "agentsync": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "agentsync-mcp"
      ],
      "env": {
        "AGENTSYNC_REPO": "your-value",
        "AGENTSYNC_AGENT_ID": "your-value",
        "AGENTSYNC_BRANCH": "your-value"
      }
    }
  }
}

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

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

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

需要你填写的值

  • AGENTSYNC_REPO env
    Absolute path to the shared project git clone used for coordination.
  • AGENTSYNC_AGENT_ID env
    Your unique agent id, used to key your claims.
  • AGENTSYNC_BRANCH env
    The dedicated coordination branch (default: agentsync).

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

它能做什么

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

基础检查i

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

  • ✓ 通过

    作者与仓库一致

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

  • … 尚未检查

    仍在维护

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

  • … 尚未检查

    有许可证

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

  • – 不适用

    端点有响应

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

  • – 不适用

    使用 OAuth 登录

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

  • … 尚未检查

    工具描述中没有隐藏指令

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

与“开发者工具”中的其他服务器比较i

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

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

常见问题

agentsync 安全吗?

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

它需要哪些密钥或代码?

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

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

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

它还在维护吗?

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

哪些应用可以使用它?

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

有什么可以替代它?

同一分类中有:GitHub, Desktop Commander, Cloudflare MCP

替代选择

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

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

GitHub

作者:github

Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.

电脑或云端★ 34,245MIT3天前更新
安装

Desktop Commander

作者:wonderwhy-er

MCP server for terminal commands, file operations, and process management

在你的电脑上运行★ 10,225MIT15天前更新
安装

Cloudflare MCP

作者:cloudflare

Cloudflare MCP servers

在云端运行★ 4,446Apache-2.014个月前更新
安装

作者的 README

打开 README

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

agentsync

An MCP server that lets two (or more) AI agents collaborate on the same git repository without stepping on each other. Each agent declares what it's building before it builds, sees what its partner has claimed, and detects conflicts when work lands — all coordinated through the repo itself, with no lock server and no requirement that both agents be online at once.

How it works (one paragraph)

Coordination state is a single claims.json living on a dedicated agentsync branch (kept out of main, so it never pollutes your code history and isn't blocked by main's branch protection). Each agent's claim declares the work, the files it will touch, what it requires, its branch, and a status. Overlap is plain set intersection. Writes use a read-modify-write loop with git push as a compare-and-swap: if the push is rejected, the server re-fetches the latest claims and re-evaluates, so a colliding peer claim is *observed before* this agent's claim is committed. All git work happens in a private worktree under .git/, so your agent's actual code branch is never disturbed.

See DESIGN.md for the architecture rationale and AGENTS.md for the playbook your agent follows to drive the tools.

Install

pip install -r requirements.txt      # just `mcp`

For anything that talks to GitHub — provisioning a repo (provision), inviting a collaborator (add_collaborator), or opening a PR (finish) — you also need the GitHub CLI, authenticated with repo scope:

gh auth login        # one-time; check with `gh auth status`

Configure

Both collaborators add the server to their MCP client, each with their own agent id and their own local clone. See mcp.config.example.json:

{

"mcpServers": { "agentsync": { "command": "python3", "args": ["/abs/path/to/agentsync_server.py"], "env": { "AGENTSYNC_BOARD_REPO": "/abs/path/to/the/clone/holding/the/board", "AGENTSYNC_AGENT_ID": "jonny" } } } }

env varrequireddefaultmeaning
AGENTSYNC_BOARD_REPOyes\*—path to the clone that holds the board
AGENTSYNC_REPOno—legacy alias for AGENTSYNC_BOARD_REPO
AGENTSYNC_AGENT_IDyes—your unique agent id
AGENTSYNC_REMOTEnoorigingit remote name
AGENTSYNC_BRANCHnoagentsynccoordination branch name
AGENTSYNC_PARTNER_GITHUBno—partner GitHub user(s) to invite (comma/space-separated)
AGENTSYNC_STALE_HOURSno24age after which an in-progress claim is flagged stale
AGENTSYNC_GIT_TIMEOUTno25seconds any single git/gh call may run before it fails fast

The agentsync branch is created automatically on the first survey() or claim() call against an explicitly addressed board — no manual setup.

Where the board lives (board addressing)

\* The board is a shared, long-lived team artifact, not a property of whichever repo you happen to be sitting in. So its address is resolved independently of the session, in this order:

  1. `AGENTSYNC_BOARD_REPO` — the explicit board address. This never follows the Xylem session pointer (~/.xylem/active_project.json).
  2. `AGENTSYNC_REPO` — the legacy explicit pin; identical effect.
  3. The current repo (session pointer, else the cwd's git root) — but *only if that repo actually holds the coordination branch*. The check is a real ref lookup (local head → remote-tracking ref → ls-remote), so this fallback can only ever select a repo that genuinely is a board.
  4. Otherwise a `ConfigError` naming `AGENTSYNC_BOARD_REPO` — never a silent selection of a boardless repo.

survey() reports the board it actually read under board: {repo, source}, so "the team is quiet" and "I am looking at the wrong board" are distinguishable.

Why this order. Previously an unpinned server followed the session pointer blindly. The board therefore changed identity whenever the session changed project, and in any project that had never been provisioned it simply disappeared — reported downstream as "no coordination branch found" and treated as normal. cambium's distill() applies this exact same resolution, so the two halves of the suite can never disagree about where the board is.

Starting from nothing (no repo yet)

If the shared repo doesn't exist on GitHub yet, one person runs provision() once. Point AGENTSYNC_BOARD_REPO at the folder you want the project in (it can be empty or not yet created) and call:

provision(repo="you/our-project", partner_github="their-username")

This creates the GitHub repo (private by default), makes the first commit, seeds the agentsync coordination branch, and invites your partner as a push collaborator. It's idempotent — safe to re-run. Then send your partner the clone_url it returns; once they accept the invite and clone, both of you point the MCP server at your own clones and the normal protocol below takes over.

Tools

`provision(repo="", partner_github="", private=True, description="")` — one-time bootstrap when the shared repo doesn't exist yet. Creates the GitHub repo via gh, makes the first commit, seeds the agentsync branch, and invites the partner as a push collaborator. Idempotent. Returns the clone_url to hand your partner. (Needs the gh CLI authenticated with repo scope.)

`add_collaborator(github_username, permission="push")` — invite one or more people (comma/space-separated) to the existing shared repo so they can push (pull|triage|push|maintain|admin). Use this when the repo already exists and you just want to grant access — this is how you build a team of more than two. They must accept the GitHub invite, then clone. (Needs gh with admin on the repo.)

`survey()` — pull the latest state and report what every *other* agent has claimed: task, files, dependencies, branch, status, timestamp. Works for any number of collaborators. Each partner entry is annotated with age_hours and a stale flag (in-progress and older than AGENTSYNC_STALE_HOURS, default 24h), and a top-level stale_claims list — so you can spot a partner who crashed or walked away still holding files. Run it before planning and after finishing.

`claim(task, touches, requires=None, branch="", force=False)` — stake a unit of work. Refuses with status: "blocked" if your touches hits a partner's active files (you'd get in their way) or your requires hits their in-progress files (you'd build on unstable ground), returning exactly what overlaps and with whom. Overlap is path-aware: exact match, directory containment (src/api vs src/api/routes.py), and globs (src/**, *.py) all collide, and paths are normalized first (./auth.py == auth.py). The overlap is checked against freshly-fetched state immediately before the push. Pass force=True to claim anyway (e.g. same large file, disjoint regions). If your agent id already holds an in-progress claim written by a different server instance — another agent is live under the same id — claim() returns blocked with a shared_agent_id reason naming the task, branch and files that would be erased, because one id holds exactly one claim. Give each agent its own id; force=True overrides it for the legitimate case of a restarted server reclaiming its own slot, and then the result carries a warning listing the files that just lost their protection.

`release(note="")` — abandon your current claim without marking it done, freeing the files for a partner to take over. Use it when you drop a task or step away — otherwise a crashed/abandoned claim blocks those files until someone does manual git surgery. Pushes immediately.

`check_conflicts(against_branch="")` — after building, diff your branch against your partners' branches at two levels:

  • claim_overlap — declared-path intersection (intent, path-aware).
  • merge_conflict — a real git merge-tree dry-run merge (textual). Catches collisions the claims didn't predict.

Defaults to every branch named in an active peer claim; pass against_branch to check one specific branch.

`update_status(status, note="")` — set your own claim's status (planning | in-progress | done) and optionally leave a note for your partner. Pushes immediately. On done, the claim is auto-annotated with changed_files — your branch's diffstat vs the default branch — so your partner reconciles against real data, not just a hand-written summary. It is computed in the board repo, and a claim records a branch *name* with no repo qualifier, so changed_files_repo names the repo the diffstat actually came from: where you coordinate on a dedicated board repo, a same-named branch there will diff cleanly and produce a confidently wrong file list. Check the label before trusting the list. (To drop a claim without finishing it, use release().)

`finish(note="", title="", draft=False)` — close the loop: mark your claim done and open a GitHub pull request from your claimed branch into the default branch. Falls back to your claim's task/note for the PR title/body, and returns the existing PR's URL if one is already open. Your branch must be pushed. (Needs gh.)

`history(limit=20)` — the coordination timeline (who claimed, finished, or released what, and when) read from the git history of claims.json, newest first. Answers "what has my partner been up to?" even when they're offline.

The workflow (what your agent does)

  1. provision(...) — once, only if the repo doesn't exist yet (then both clone)
  2. survey() — what's my partner working on, if anything?
  3. plan a slice that doesn't overlap their active work
  4. claim(...) — if blocked, narrow the slice or wait
  5. build on your branch
  6. survey() again — where are they now?
  7. check_conflicts() — does their landed work collide with mine?
  8. reconcile (rebase/merge or flag) → update_status("done", ...) or finish(...) to also open a PR

The full prompt your agent should run is in AGENTS.md.

More than two agents

Nothing here is limited to two. claims.json is keyed by agent id, claim() checks your plan against *every* peer, and the compare-and-swap only ever edits your own key — so three, four, or more agents coordinate safely. To run a team:

  • Invite everyone: add_collaborator("alice, bob, carol") (or list them in provision(partner_github=...)).
  • Give every agent a unique `AGENTSYNC_AGENT_ID` — every *agent*, not every person. One person running a desktop session, a phone and a remote agent needs three ids, for the same reason three people do: one id holds exactly one claim. claim() blocks rather than overwriting a live claim under your own id, but a unique id per agent avoids the collision entirely.

This guard used to key on a per-process token, which meant it caught a restarted server and waved through a *concurrent session* -- one agentsync process serves every session on a machine, so two sessions shared the token and silently overwrote each other. It now keys on the work: a claim for a different task, while one is in progress under your id, is refused whatever process wrote it. Re-claiming the *same* task stays free, which is how you widen touches mid-unit. release(expect_task=...) covers the other direction, refusing to close a claim that is not the one you think you hold.

  • Contention stays cheap for

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

问 PopNx