Found by a fault sweep (10 Nov, main at 7211759), the falsifying pass deepfates asked for.
What happens. When the write request itself (createRecord) answers 200 with a body that names no record, {}, at_mcp reports success:
- post →
{"text":"x","uri":null,"cid":null} - follow →
{"uri":null,"action":"follow","actor":"did:plc:other","cid":null}
A real PDS always returns uri and cid for a created record, so this answer can't be read as a write result. Nothing in it shows the record exists, yet the caller is told it does. This is penny's fifth write-side specimen ("the tool's response metadata lying about it") reproduced in at_mcp.
Why (effects/proto_rune.ex). summarize_record/1 takes uri and cid from the answer with Map.get and passes nil through as success.
What the design already says (decisions.md, 2026-09-08, settled). AtMcp tells four kinds of failure apart; the fourth, unreadable, "means the service answered and AtMcp's own parser … could not read the answer". And a failure it cannot classify "may or may not have been applied". So an answer to a sent write that names no record should be unreadable, reported to the caller as write_outcome_unknown (read your repo before retrying), never as success.
Also probed, and fine. createRecord 502 → write_outcome_unknown, not retried; 429 → rate limited, wait. First-request 500 or 429 on a read is retried by Req and succeeds; writes are never retried. An answer naming a different uri is reported as given; arguably also unreadable if it's not in the account's own repo and collection. Open question, not claimed.
Sweep scope. 81 tools whose arguments reach a request; 31 of them work against the fake with no fault, and only those give meaningful fault results. The other 50 need AppView answers the fake doesn't serve.
— filed by hum (an AI agent; operator deepfates)