プロトタイプ · プレビュー版:公式レジストリのすべてのサーバーを掲載し、30分ごとに同期しています。レビューとアカウント機能は今後のステップで始まります。
PopNx MCPAIを使う人のためのMCPサーバー · やさしい言葉で解説

Agent Coherence — Stale Write Guard (FS)

作者:Cohexa-aiバージョン 0.14.1i★ –iパソコンで動く
レジストリ名io.github.Cohexa-ai/stale-write-guard-fs

インストール

概要

作者による説明(英語の原文)

Coherence guard for shared files: denies stale writes so agents don't silently overwrite each other.

PopNx MCPの3つの柱

この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。

できること

このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。

  • 接続方法: パソコンで動く
  • トランスポート: stdio
  • カテゴリ: 文書・表計算・事務作業

インストール

使っているAIアプリを選んで、設定をコピーしてください。

インストールの前に

  • 基本チェック:1項目中1項目に合格
  • あなたのパソコンで、あなたのユーザーと同じ権限(ファイル、ネットワーク、アプリ)で動きます。
  • レジストリには、入力が必要なキーは載っていません。

必要なもの

  • PyPIPythonのuvのインストール(uvxコマンドに必要)

どのアプリを使っていますか?

上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。

Claude Desktop → Settings → Developer → Edit Config を開き、claude_desktop_config.json にこれを貼り付けます

{
  "mcpServers": {
    "stale-write-guard-fs": {
      "command": "uvx",
      "args": [
        "agent-coherence"
      ]
    }
  }
}

ターミナルでこれを実行します

claude mcp add stale-write-guard-fs -- uvx agent-coherence

Cursorで開く

または、設定を自分でコピーする

プロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます

{
  "mcpServers": {
    "stale-write-guard-fs": {
      "command": "uvx",
      "args": [
        "agent-coherence"
      ]
    }
  }
}

ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。

VS Codeで開く

または、設定を自分でコピーする

プロジェクトの .vscode/mcp.json に貼り付けます

{
  "servers": {
    "stale-write-guard-fs": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "agent-coherence"
      ]
    }
  }
}

ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。

これはパソコンで動くサーバーですが、ChatGPTがつなげるのはインターネット上のサーバーだけです。ほかのアプリを選んでください。

選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。

この設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。

できること

パソコンで動くサーバーです。インストールすると、ツール一覧がAIアプリに表示されます。

基本チェックi

誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月8日にチェック

  • ✓ 合格

    作者とリポジトリが一致

    レジストリ名は、リポジトリを所有するGitHubアカウント Cohexa-ai で確認済みです

  • … 未チェック

    今もメンテナンスされている

    このリポジトリはまだGitHubから読み取っていません

  • … 未チェック

    ライセンスがある

    このリポジトリはまだGitHubから読み取っていません

  • – 対象外

    エンドポイントが応答する

    これはパソコンで動くため、インターネット上のエンドポイントはありません

  • – 対象外

    OAuthでサインイン

    パソコンで動き、代わりにローカルの設定を使います

  • … 未チェック

    ツールの説明に隠れた指示がない

    パソコンで動くサーバーです。ツール一覧を読み取れるのは、インターネット上のエンドポイントがある場合だけです

文書・表計算・事務作業のほかのサーバーとの比較i

  • このカテゴリのほかの3577件のうち0%よりスターが多い
  • このカテゴリのほかの3577件のうち33%より最近レジストリに公開
  • 基本チェックの結果が、このカテゴリのほかの3577件のうち100%と同じかそれ以上

レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。

よくある質問

Agent Coherence — Stale Write Guard (FS)は安全ですか?

当てはまる基本チェック1項目のうち1項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。

どんなキーやコードが必要ですか?

レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。

パソコンで動きますか、それともクラウドですか?

あなたのパソコンで動きます。必要なときにAIアプリが起動し、データは作者のサーバーを通りません(サーバー自体がオンラインサービスを呼び出す場合を除きます)。

今もメンテナンスされていますか?

GitHubリポジトリの最終更新は–、最新バージョン(0.14.1)がレジストリに届いたのは2 か月前です。

どのアプリで使えますか?

Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。パソコンにPython (uv)も必要です。

代わりに使えるものは?

同じカテゴリには:Agent-Native Calendar, Excel MCP Server, MCP Server for Excel

代わりの候補

同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。

カードの見方:↓ 週あたりのダウンロードi★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i

Excel MCP Server

Create and edit Excel files with AI: charts, PivotTables, formulas. No Excel needed.

作者:haris-musa広く使われている↓ 5万/週★ 42768 日前更新

パソコンで動く

MCP Server for Excel

Excel automation for AI - Sheets, Power Query, DAX, VBA, Tables, Ranges and more. Windows only.

作者:sbroenne成長中↓ 4321/週★ 8475 日前更新

パソコンで動く

作者のREADME

READMEを開く

作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。

agent-coherence

`agent-coherence` stops one agent from silently clobbering another's work on a shared `plan.md`, store key, or `memory.json` — a vendor-neutral MESI + optimistic-concurrency coordinator for agent state on a single host, with the safety invariants machine-checked in TLA+.

Two agents share an artifact — a plan.md, a store key, a memory.json. One reads it and works; meanwhile a peer commits a newer version; the first writes back anyway. Last write wins, the peer's work is silently gone, nothing errors, and every downstream decision builds on the wrong version.

Why it goes unnoticed. An agent system keeps two records of what happened: the one your infrastructure can verify — which version each agent held, what actually committed, what was refused — and the one the model narrates, *"task complete", "the plan is updated"*. They agree until an agent acts on a version that moved underneath it, and the narrated record is the one you read. That is why a lost update looks like a clean run and gets debugged as a model problem. agent-coherence is the verified record for the state your agents share. (It does not verify what an agent did in the outside world — a sent email, a fired webhook — that stays your outbox and idempotency layer's job.) agent-coherence turns that silent clobber into a loud, typed refusal: MESI-style ownership and invalidation over shared artifacts, optimistic commit-CAS for concurrent writers, and a read-generation fence for crash-reclaimed ones — a stale write is denied or returned as a retryable conflict, never silently applied. Same library, same protocol, across LangGraph, CrewAI, AutoGen, the OpenAI Agents SDK, plain files shared across processes (CoherentVolume), any MCP client (the stale-write-guard-fs server, via the mcp extra), and any custom orchestrator. Same behavior regardless of which model provider (Anthropic, OpenAI, Google, Mistral, open-source) the agents talk to.

mcp-name: io.github.cohexa-ai/stale-write-guard-fs

# Requires Python 3.11+

pip install "agent-coherence[langgraph]" # LangGraph drop-in pip install "agent-coherence[crewai]" # CrewAI adapter pip install "agent-coherence[openai-agents]" # OpenAI Agents SDK adapter (experimental) pip install "agent-coherence[diagnose]" # ccs-diagnose CLI pip install "agent-coherence[mcp]" # stale-write-guard-fs MCP server pip install "agent-coherence[conformance]" # substrate conformance corpus (for foreign implementations) pip install "agent-coherence[all]" # everything

# Before

from langgraph.store.memory import InMemoryStore store = InMemoryStore()

After — one import change, no node code changes

from ccs.adapters import CCSStore store = CCSStore(strategy="lazy")

store.get(), store.put(), store.search() keep working unchanged. CCSStore adds read-side coherence: a peer's commit invalidates your cached view, so your next read is a fresh miss. It does not deny a stale write-back — put is not version-CAS; for write-side lost-update prevention, route writes through CoherentVolume or write_cas (below).

The one-import swap assumes your store namespaces carry the agent identity in namespace[0] — a (user_id, "memories") shape would merge users onto one shared artifact. See the namespace convention.

# Plain files shared across processes / sessions — no framework required

from ccs.adapters.coherent_volume import CoherentVolume

vol = CoherentVolume(workspace_root, managed=("plans/**",)) plan = vol.read("plans/plan.md") # tracked read — your view is registered vol.write("plans/plan.md", revised_plan) # stale view? denied fail-closed → vol.reacquire() and re-derive

agent-coherence-replay — invariant-replay for any CoherenceAdapterCore-mediated agent system. LangGraph capture verified in v1 via CCSStore.record_to(path); CrewAI / AutoGen wired through the same seam but unverified — file an issue if it breaks.

What it guarantees

Each row is a safety invariant model-checked with TLA+/TLC. make tla-check runs all nine specs. CI runs them as three parallel jobs on every pull request that changes a TLA+ input (the specs and their configs, the Makefile, the workflows, and the scripts that decide and judge the run), and on every run outside a pull request. Every spec carries a documented mutant that must fail — the invariants are load-bearing, not decorative.

The silent failureWhat happens insteadMechanismInvariant
Stale-read overwrite — an agent acts on an old snapshot and writes over a newer version (two sessions, one plan.md)the write is denied fail-closed; the writer must reacquire() and read the current versionMESI single-writer ownership + invalidationSingleWriter, MonotonicVersion
Concurrent lost update — two writers hit the same key and both "succeed"exactly one wins; the loser gets a typed conflict + bounded retry, never a silent dropoptimistic commit-CAS (write_cas)NoLostUpdate
Reclaim-zombie write — a stalled writer is reclaimed by crash recovery, wakes later, and lands its stale commit; the version never moved, so a version check passesthe commit is rejected: on the pessimistic route (CoherentVolume.write() and the Claude Code hooks, /hooks/post-edit) with commit_not_allowed, naming the reclaim (reclaimed_by=reclaim_heartbeat); on the commit-CAS route (write_cas, write_cas_at, /hooks/post-edit-cas) with a typed stale_read_generation conflicton the pessimistic route, the grant check refuses a holder whose grant was reclaimed; the read-generation fence — reclamation bumps the artifact's ownership epoch, checked atomically at commit — rejects it on the commit-CAS route, and on the pessimistic route when the reclaim lands mid-commitNoStaleApply
Zombie revoke — an invalidation is minted, and by the time it is applied the agent it names has been reclaimed, re-acquired and re-read; applying it now revokes a grant issued *after* the signal, and the target's version never moved, so a version check sees nothingthe invalidation is dropped as obsolete — the target is not behind what it announces, so the grant survivesa peer-issued revoke is pinned to the target's last observed version, and every revoke-class ending of a write claim — a sweep reclaim or a release — moves the ownership epoch (a peer's write-*acquire* moves neither comparand; the effect gate fences that by grant state instead)NoZombieRevoke, NoSilentRevoke
Reclaim-zombie effect — the same reclaimed writer's *escaping* effect (a webhook, a deploy, an opened PR) fires on a decision made under the revoked grant; the version never moved, so a version-only re-check passesthe effect is held (StaleView) at the effect boundary — versions equal, ownership generations apartgate() re-validates a pair-atomic (version, ownership generation) snapshot before firingNoStaleAdmit
Torn multi-artifact read (read-skew) — an agent reads several artifacts one by one while a peer commits in between; each read was individually current, but the *combination* never coexistedsession reads serve from a pinned consistent cut; commits validate against the pinned base; a lapsed session fails closed with a typed rejection, never a silent fall-through to live statemulti-artifact snapshot sessionsNoReadSkewWithinCut, PinAlwaysRetained
Dead owner blocks the fleet — a crashed agent holds EXCLUSIVE foreverthe heartbeat/TTL sweep reclaims the grant (on by default; best-effort, rate-limited)crash-recovery sweep; an operator can read from /status?detail=full when the sweep will reclaim each write grant (how) and which grants it reclaimed (how)sweep invariants I3–I6

The table is also machine-checked against the test suite: the packaged claim ladder (ccs.testing.claim_ladder) pins every claim-phrase above to the tests that would fail without it — resolved at collection time and two-way drift-guarded by tests/conformance/test_claim_ladder.py, so a claim cannot outlive its proof (and a cross-host rung cannot appear without one).

Scope, honestly: the guarantees hold for writers that go through the coordinator, under a single coordinator (one host). Both registries hold one lock across every check-and-act sequence — the durable SQLite registry and the in-memory one carry the same concurrency contract, so an embedder may drive either from several threads. Concurrent same-key writers on one host are covered, with one open gap (#248): a plain write() made after a peer's write_cas_at has committed but before the peer's bytes reach disk is lost when the writing volume holds no live view of the file — it never read it, it read it only inside that window (the coordinator refuses such a read, even where read() hands back the old bytes under the default on_stale_read="allow"), or a write_cas / write_cas_at it ran ended in ViewWedged. Both calls report success, disk keeps the peer's bytes while the coordinator records the lost write as the newest version, and every write_cas / write_cas_at on the file raises ViewWedged until a plain write() replaces it. A volume that read the file before the peer committed is refused instead. Cross-host fencing is on the roadmap, demand-gated — if you need it, open an issue. Edits that *bypass* the coordinator entirely (a human in an editor, a formatter, a regenerating script) are caught at the read()/write() boundary by content-hash checks — the foreign-edit guards below, enforced by tests rather than TLA+; the batch CAS path has a narrower boundary, spelled out in Atomic multi-file publish. Specs, the invariant ↔ implementation map, and the mutant recipes live in formal/tla/.

Correctness is the wedge; the token savings come with it. Writes publish ~12-token invalidation signals instead of rebroadcasting full artifacts, so read-heavy fleets stop re-paying for state they already hold:

WorkloadAgentsReads:WritesHit rateSavings
Planning (read-heavy)412:175%69%
Code review (moderate)38:360%47%
High-churn (write-heavy)48:450%29%

*Measured on real LangGraph graphs; see docs/reproduce.md and the user guide.*

Those are the spatial savings (more agents sharing one artifact). The temporal dimension — a single agent whose source drifts between its turns — has its own pre-registered benchmark, TC-1 (#116): a reproducible savings-regime map of how many re-fetches coherence-gating avoids as the change-rate rises. The metric is *re-fetches-avoided* — a proxy, a regime map, not a token/dollar i

冒頭だけを表示しています。続きはリポジトリで読めます

PopNxに聞く