Puter MCP
Puter MCP enables AI tools to interact with Puter: manage files, websites, workers, and more
Multi-agent coordination MCP: claim work, survey peers, resolve conflicts via a git branch as CAS.
使っているAIアプリを選んで、設定をコピーしてください。
チェック 2/3 合格 · あなたのパソコンで動きます
まず:どの AI を使っていますか?
使っているアプリを選ぶと、下に手順が表示されます。
Claude につなげますが、先に準備が必要です
agentsync のキーが必要です(提供元のサイトで作成) · 先にパソコンへ Python (uv) を入れてください(1 回だけ) · パソコン版 Claude アプリ(Windows または Mac)のみ。Web やスマホでは使えません
提供元のサイトで登録し、次の手順で使う API キーを作ります。料金や無料プランは提供元のサイトで確認してください。
キーの取り方は下の提供元 README にあります
SettingsDeveloperEdit Config
{
"mcpServers": {
"agentsync": {
"command": "uvx",
"args": [
"agentsync-mcp"
],
"env": {
"AGENTSYNC_REPO": "your-value",
"AGENTSYNC_AGENT_ID": "your-value",
"AGENTSYNC_BRANCH": "your-value"
}
}
}
}キーはアプリの入力欄にだけ貼り付け、チャットに貼ったり人に送ったりしないでください
agentsync を使って、私に何ができるか教えて、1 つやってみせて✓ Claude が agentsync を使っていると言うか、回答に agentsync のツール名が出れば接続成功です
メニュー名は 2026年11月11日 に Anthropic のヘルプページで確認 · アプリのバージョンにより画面が少し違うことがあります
ChatGPT はまだ agentsync につなげません
agentsync はパソコンに入れて使うものですが、ChatGPT は Web 上で動くサーバーにしかつなげません
A · agentsync につなげるアプリを使う
Claude Code につなげますが、先に準備が必要です
agentsync のキーが必要です(提供元のサイトで作成) · 先にパソコンへ Python (uv) を入れてください(1 回だけ)
提供元のサイトで登録し、次の手順で使う API キーを作ります。料金や無料プランは提供元のサイトで確認してください。
キーの取り方は下の提供元 README にあります
Mac:Command+スペースで Terminal と入力 · Windows:PowerShell を開く
claude mcp add --scope user agentsync --env AGENTSYNC_REPO=your-value --env AGENTSYNC_AGENT_ID=your-value --env AGENTSYNC_BRANCH=your-value -- uvx agentsync-mcpEnter の前に「your-value」を自分のキーに書き換えてください
キーはアプリの入力欄にだけ貼り付け、チャットに貼ったり人に送ったりしないでください
agentsync が一覧にあり、接続済みと表示されれば OK です
agentsync を使って、私に何ができるか教えて、1 つやってみせて✓ Claude Code が agentsync を使っていると言うか、回答に agentsync のツール名が出れば接続成功です
メニュー名は 2026年11月11日 に Anthropic のヘルプページで確認 · アプリのバージョンにより画面が少し違うことがあります
Cursor につなげますが、先に準備が必要です
agentsync のキーが必要です(提供元のサイトで作成) · 先にパソコンへ Python (uv) を入れてください(1 回だけ)
提供元のサイトで登録し、次の手順で使う API キーを作ります。料金や無料プランは提供元のサイトで確認してください。
キーの取り方は下の提供元 README にあります
agentsync の設定で AGENTSYNC_REPO, AGENTSYNC_AGENT_ID, AGENTSYNC_BRANCH が空です。自分のキーを入れて保存します
キーはアプリの入力欄にだけ貼り付け、チャットに貼ったり人に送ったりしないでください
agentsync を使って、私に何ができるか教えて、1 つやってみせて✓ Cursor が agentsync を使っていると言うか、回答に agentsync のツール名が出れば接続成功です
メニュー名は 2026年11月11日 に Cursor のヘルプページで確認 · アプリのバージョンにより画面が少し違うことがあります
VS Code につなげますが、先に準備が必要です
agentsync のキーが必要です(提供元のサイトで作成) · 先にパソコンへ Python (uv) を入れてください(1 回だけ)
提供元のサイトで登録し、次の手順で使う API キーを作ります。料金や無料プランは提供元のサイトで確認してください。
キーの取り方は下の提供元 README にあります
agentsync の設定で AGENTSYNC_REPO, AGENTSYNC_AGENT_ID, AGENTSYNC_BRANCH が空です。自分のキーを入れて保存します
キーはアプリの入力欄にだけ貼り付け、チャットに貼ったり人に送ったりしないでください
agentsync を使って、私に何ができるか教えて、1 つやってみせて✓ VS Code が agentsync を使っていると言うか、回答に agentsync のツール名が出れば接続成功です
メニュー名は 2026年11月11日 に VS Code のヘルプページで確認 · アプリのバージョンにより画面が少し違うことがあります
Windsurf、Zed、Gemini CLI など MCP を使える他のアプリは追加方法がそれぞれ違います。アプリ一覧で確認してください
JSON 設定は下の「開発者向け」にあります
Claude Code
claude mcp add --scope user agentsync --env AGENTSYNC_REPO=your-value --env AGENTSYNC_AGENT_ID=your-value --env AGENTSYNC_BRANCH=your-value -- uvx agentsync-mcpClaude Desktop (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"
}
}
}
}Cursor (~/.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 (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"
}
}
}
}AGENTSYNC_REPO envAGENTSYNC_AGENT_ID envAGENTSYNC_BRANCH envこの設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。
このサーバーのつなぎ方と、各アプリの公式ドキュメントに基づきます。2026年11月10日に確認。
パソコン上で動かせるアプリ
ClaudeGooseLM StudioMsty StudioCherry StudioCursorVS Code + GitHub CopilotVisual StudioWindsurf (Devin Desktop)ZedKiroClineContinueJetBrains AI AssistantClaude CodeCodex CLIGemini CLIOpenCodenodecodeWarpLibreChatRaycast
パソコンで動くサーバーです。インストールすると、ツール一覧がAIアプリに表示されます。
誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月13日にチェック
レジストリ名は、リポジトリを所有するGitHubアカウント jarmstrong158 で確認済みです
コードの最終更新:3 か月前
GitHubがライセンスの種類を判別できませんでした。ファイルを開いて確認してください
これはパソコンで動くため、インターネット上のエンドポイントはありません
パソコンで動き、代わりにローカルの設定を使います
パソコンで動くサーバーです。ツール一覧を読み取れるのは、インターネット上のエンドポイントがある場合だけです
質問、コツの共有、使えないことの報告ができます。「役に立った」の多い順です。
まだレビューはありません
レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。
当てはまる基本チェック3項目のうち2項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。
レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。
あなたのパソコンで動きます。必要なときにAIアプリが起動し、データは作者のサーバーを通りません(サーバー自体がオンラインサービスを呼び出す場合を除きます)。
GitHubリポジトリの最終更新は3 か月前、最新バージョン(0.2.0)がレジストリに届いたのは3 か月前です。
Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。パソコンにPython (uv)も必要です。
同じカテゴリには:Puter MCP, XcodeBuildMCP, XcodeBuildMCP
同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。
カードの見方:↓ 週あたりのダウンロードi★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i
Puter MCP enables AI tools to interact with Puter: manage files, websites, workers, and more
XcodeBuildMCP provides tools for Xcode project management, simulator management, and app utilities.
XcodeBuildMCP provides tools for Xcode project management, simulator management, and app utilities.
作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。
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.
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.
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`
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 var | required | default | meaning |
|---|---|---|---|
AGENTSYNC_BOARD_REPO | yes\* | — | path to the clone that holds the board |
AGENTSYNC_REPO | no | — | legacy alias for AGENTSYNC_BOARD_REPO |
AGENTSYNC_AGENT_ID | yes | — | your unique agent id |
AGENTSYNC_REMOTE | no | origin | git remote name |
AGENTSYNC_BRANCH | no | agentsync | coordination branch name |
AGENTSYNC_PARTNER_GITHUB | no | — | partner GitHub user(s) to invite (comma/space-separated) |
AGENTSYNC_STALE_HOURS | no | 24 | age after which an in-progress claim is flagged stale |
AGENTSYNC_GIT_TIMEOUT | no | 25 | seconds 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.
\* 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:
~/.xylem/active_project.json).ls-remote), so this fallback can only ever select a repo that genuinely is a board.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.
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.
`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.
provision(...) — once, only if the repo doesn't exist yet (then both clone)survey() — what's my partner working on, if anything?claim(...) — if blocked, narrow the slice or waitsurvey() again — where are they now?check_conflicts() — does their landed work collide with mine?update_status("done", ...) or finish(...) to also open a PRThe full prompt your agent should run is in AGENTS.md.
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:
add_collaborator("alice, bob, carol") (or list them in provision(partner_github=...)).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.