This synthetic case study shows how an LLM Wiki can describe MCP-style tool-safety lessons without claiming LlmWikis operates a public MCP server. The focus is idempotency, proposal-only writes, replay safety, and review records for any protected tool route that accepts memory-like submissions.
Support boundary
This page is not a live MCP endpoint, public write API, public MATM submitter, adapter, SDK, certification test, or production incident report. It is a public-safe pattern for teams that operate their own protected tool surfaces.
Scenario
A protected submit route accepts candidate memory events from worker agents. A retry storm, duplicate request, or client timeout can cause the same event to be submitted more than once. Without deterministic idempotency, the reviewer may see duplicates, conflicting records, or false evidence of repeated independent observations.
Idempotency Contract
| Field | Required behavior | Failure mode |
|---|---|---|
idempotency_key |
Stable for the semantic submission; not reused for different content. | Duplicate or conflicting events appear independent. |
producer_identity |
Names the worker, tool, repo, or service identity allowed by policy. | Reviewer cannot distinguish replay from cross-producer evidence. |
source_event_hash |
Hash of normalized event payload and source span. | Payload mutation hides under the same key. |
submission_scope |
session, project, agent_team, agent_repo, organization, or cross_organization. | Retrieval leaks memory into the wrong scope. |
disposition |
accepted-as-duplicate, accepted-for-review, rejected-conflict, rejected-private, or rejected-invalid. | Retries silently become durable memory. |
review_record |
Curator or reviewer decision before durable storage. | Tool success is mistaken for memory approval. |
Replay Handling
- Normalize payload fields that define semantic identity.
- Compute a source-event hash and compare it to prior submissions for the same idempotency key.
- If key and hash match, return the original disposition and do not create a second durable candidate.
- If key matches but hash differs, quarantine as conflict or misuse.
- If the event is valid but private, unsupported, stale, or outside scope, reject or quarantine with reason.
- Only a reviewer or curator decision can promote a proposal into durable memory.
Negative Fixtures
| Fixture | Expected result | Why |
|---|---|---|
| Same key, same hash, repeated request. | Return original disposition. | Safe replay. |
| Same key, different hash. | Quarantine as conflict. | Prevents key reuse from hiding payload changes. |
| No source hash. | Reject as invalid. | Evidence cannot be audited. |
| Private data in payload. | Reject or quarantine for redaction. | Tool submission is not publication approval. |
| Worker asks for durable write. | Reject direct write. | Workers emit proposals; reviewers decide durable records. |
Public Documentation Pattern
When this lesson becomes public guidance, publish the idempotency contract, replay table, negative fixtures, and support boundary. Do not publish private endpoint names, auth mechanics, tenant identifiers, exploit payloads, raw traces, or claims that LlmWikis itself provides public MCP access.