Agent-Native Calendar
Agent-Native Google Calendar - manage events, sync, and public booking
Runs in the cloud
Agent Coherence — Stale Write Guard (FS)
Overview
Description from the maker (original English)
Coherence guard for shared files: denies stale writes so agents don't silently overwrite each other.
PopNx MCP’s three pillars
These three are never merged into one score: opinions, measurements and popularity are different things.
- User voiceiNo reviews yetReviews open together with accounts in a later step
- Our basic checksi1 of 1 passedChecked from public information; code not scanned yet
- UsageiVery new↓ 171/wk · ★ –
What you can do with it
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
- Connection: Runs on your computer
- Transport: stdio
- Category: Docs, sheets & office work
Install
Pick the AI app you use, then copy the settings.
Before you install
- Basic checks: 1 of 1 passed
- Runs on your computer with your user’s permissions (files, network, apps).
- The registry lists no key to fill in.
You need
- PyPIPython’s uv installed (for the uvx command)
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"stale-write-guard-fs": {
"command": "uvx",
"args": [
"agent-coherence"
]
}
}
}Run this in your terminal
claude mcp add stale-write-guard-fs -- uvx agent-coherenceOr copy the settings yourself
Paste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"stale-write-guard-fs": {
"command": "uvx",
"args": [
"agent-coherence"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Or copy the settings yourself
Paste into .vscode/mcp.json in your project
{
"servers": {
"stale-write-guard-fs": {
"type": "stdio",
"command": "uvx",
"args": [
"agent-coherence"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
What it can do
Runs on your computer; the tool list appears in your AI app after you install it.
Basic checksi
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 9, 2026
- ✓ Pass
Maker matches the repo
The registry name was verified with the GitHub account Cohexa-ai, which owns the repo
- … Not checked yet
Still maintained
We have not read this repo from GitHub yet
- … Not checked yet
Has a licence
We have not read this repo from GitHub yet
- – Not applicable
Endpoint responds
This one runs on your computer; there is no internet endpoint
- – Not applicable
Sign-in with OAuth
Runs on your computer and uses local settings instead
- … Not checked yet
No hidden instructions in tool descriptions
Runs on your computer; we can only read tool lists from internet endpoints
Compared with others in Docs, sheets & office worki
- More stars than 0% of the other 3606 servers in this category
- Published to the registry more recently than 32% of the other 3606 servers in this category
- Basic checks equal to or better than 100% of the other 3606 servers in this category
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
Common questions
Is Agent Coherence — Stale Write Guard (FS) safe?
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
What keys or codes does it need?
The registry does not list a required key, though some servers ask you to sign in on first use.
Does it run on my computer or in the cloud?
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
Is it still maintained?
The GitHub repo last changed –, and the latest version (0.14.1) reached the registry 2 months ago.
Which apps can use it?
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Python (uv) on your computer.
What can I use instead?
In the same category: Agent-Native Calendar, Excel MCP Server, MCP Server for Excel
Alternatives
Servers in the same category from other makers, sorted by stars.
Reading a card:↓ Downloads per weeki★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
Excel MCP Server
Lets AI create and edit Excel files itself, including formulas, charts and PivotTables, without Excel installed.
Runs on your computer
MCP Server for Excel
Excel automation for AI - Sheets, Power Query, DAX, VBA, Tables, Ranges and more. Windows only.
Runs on your computer
README from the maker
Open the README
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
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
# Beforefrom 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 requiredfrom 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 failure | What happens instead | Mechanism | Invariant |
|---|---|---|---|
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 version | MESI single-writer ownership + invalidation | SingleWriter, 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 drop | optimistic 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 passes | the 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 conflict | on 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-commit | NoStaleApply |
| 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 nothing | the invalidation is dropped as obsolete — the target is not behind what it announces, so the grant survives | a 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 passes | the effect is held (StaleView) at the effect boundary — versions equal, ownership generations apart | gate() re-validates a pair-atomic (version, ownership generation) snapshot before firing | NoStaleAdmit |
| 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 coexisted | session 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 state | multi-artifact snapshot sessions | NoReadSkewWithinCut, PinAlwaysRetained |
| Dead owner blocks the fleet — a crashed agent holds EXCLUSIVE forever | the 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:
| Workload | Agents | Reads:Writes | Hit rate | Savings |
|---|---|---|---|---|
| Planning (read-heavy) | 4 | 12:1 | 75% | 69% |
| Code review (moderate) | 3 | 8:3 | 60% | 47% |
| High-churn (write-heavy) | 4 | 8:4 | 50% | 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
Only the beginning is shown; read the rest in the repo