Self-funded research by IsoKron, conducted and written with AI assistance. Not commissioned or endorsed by GitHub, Grafana Labs or PostHog; IsoKron is not affiliated with any of them. IsoKron sells MCP server audits.
We audited the MCP servers that GitHub, Grafana and PostHog publish for their own products. In all three, two writes sent at the same moment to the same object could lose one of the changes, and both callers were told their write had succeeded. This page puts the three results side by side. Each row links to the full audit.
The reason to look at this class of bug now is that it was rare when one person used one client. It stops being rare when several agents work on the same backlog, dashboard or project at once.
The three results
| Server | What was raced | Lost through the MCP server | Lost through the vendor's own API | Where the defect is |
|---|---|---|---|---|
| GitHub MCP server v2.1.0 | Two updates to different issue fields of one issue | 19 of 30 pairs | 0 of 28 pairs, using GitHub's per-field update | In the MCP tool |
| Grafana MCP server v2.2.0 | Two patches to different panels of one dashboard | 30 of 30 pairs, on Grafana 13 and on Grafana 11 | Legacy save endpoint: 30 of 30 on Grafana 13, 20 of 30 on Grafana 11. Kubernetes-style API on Grafana 13: 0 of 30, one save rejected in every pair | In the MCP tool and in the legacy save endpoint |
| PostHog MCP server | Two updates to different fields of one insight | 7 of 11 pairs, through the hosted server | 6 of 11 pairs | In PostHog's API; the MCP server passes it through |
A pair counts as lost when both calls returned success and one of the two changes was missing afterwards. All pairs were deliberately simultaneous. None of these numbers says how often this happens in normal use.
Three different causes
GitHub: the MCP tool rewrites more than it was asked to change. To set one issue field, the tool reads every field value, merges in the change and writes the whole set back, with no version check. Two agents changing different fields overwrite each other. GitHub's own per-field update does not have the problem, which is why the control lost nothing. The MCP layer introduced the loss.
Grafana: the MCP tool switches off a check, and the endpoint behind it has a gap of its own. Patch mode reads the dashboard, applies the patch and saves the whole dashboard with overwrite forced on, so Grafana's version check never runs. Grafana rejected a stale save in 10 of 10 trials when the check was allowed to run. But two saves that arrive at exactly the same moment through the legacy save endpoint were both accepted even with the check on. Grafana 13's Kubernetes-style API did not have that gap: it rejected one of two simultaneous saves in 30 of 30 pairs.
PostHog: the loss is in the product's API. The same two requests sent straight to PostHog's API lost a write about as often as they did through the MCP server. The MCP server added nothing and removed nothing. An agent hits it more easily than a person does, because agents work in parallel.
The distinction matters when you read an audit of any MCP server. "The MCP server loses writes" can mean the server is wrong, or that it faithfully exposes a backend that is. The control against the vendor's own API is what tells them apart, and it should be in the report.
What happened next
| Server | Reported | Status on 10 November 2026 |
|---|---|---|
| GitHub | Issue 3751 | Our fix is open as pull request 3781. In our test of that approach a patched build lost 0 of 12 pairs |
| Grafana | Pull request 1518 | Open, not yet reviewed. The proposed fix saves through the Kubernetes-style API where it exists and lost 0 of 60 pairs on Grafana 13. Grafana 11 has only the legacy endpoint; there the restored version check reports stale saves but still lost 14 of 30 simultaneous pairs |
| PostHog | Pull request 131519 | Fixed for insights. A maintainer re-created the change as pull request 131620 and merged it about 17 hours after we opened ours. Cohorts and dashboards lost writes in the same tests and are not yet fixed |
PostHog's response is the one to copy: a small fix, reviewed and merged the next morning.
What this does not show
- The pair counts are small: 11 to 30 pairs per cell, on one machine or one test account, with the two calls released together on purpose.
- We did not measure how often real agents collide in real use.
- Three servers is not a survey. We chose them because they are widely used and open source, not at random.
- In every case the lost change can be put back by writing it again, and at Grafana it stays in the dashboard's version history. The harm is that nothing tells the agent or the user that it needs to.
- The findings were found with AI assistance and checked as each audit describes. We sell audits of this kind, so read the method sections with that in mind.
How to check a server you run
- Pick a tool that updates part of an object: one field, one panel, one tag.
- Send two calls that change different parts of the same object at the same moment, from two separate server processes. Repeat at least ten times.
- Read the object back. If both calls said success and one change is missing, you have a lost update.
- Repeat with the same two changes sent straight to the product's API. If the API loses nothing, the MCP tool is the cause. If the API loses them too, the fix belongs in the API, and the tool should at least surface a conflict where the API offers one.
The full method, including the controls and the ways we got it wrong before getting it right, is in How to test an MCP server without fooling yourself.