Feature
Add a small, deterministic MCP reliability fixture for the ambiguous-success boundary: a mutating tool commits its external write, but the caller loses the result. A blind retry can duplicate the mutation even when neither MCP transport nor server automatically retries it.
This would let MCP client and agent authors test a safety property that protocol conformance alone cannot prove: whether their workflow reconciles destination state before replaying a side effect.
Solution
I propose an isolated example under examples/reliability/ambiguous-success/ with:
- a local stateful MCP server exposing a duplicate-sensitive create tool, a read-back/status tool, and fixture reset
- deterministic fault injection that commits the first mutation and then makes its result uncertain
- an unguarded Vitest case showing the duplicate caused by a blind retry
- a guarded case that records
external_result_uncertain, performs read-after-write reconciliation through a stable opaque operation marker, and does not call create again
- assertions and a compact report for mutation count, tool-call count, recovered outcome, and residual guarantee
The example would stay vendor-neutral: no hosted service, API key, model call, or Agent Enhancer dependency. I can contribute the implementation and tests if this location and shape fit the SDK examples.
Alternatives
A built-in protocol conformance check would overstate what MCP can guarantee because retry safety depends on tool semantics and destination capabilities. A standalone SDK fixture keeps this explicitly at the workflow/reliability layer.
Additional Context
We reproduced the boundary in a real gated-write MCP: erpipe-org/mcp-odoo#61. The state names and reporting boundary are documented in the vendor-neutral Reliability Sidecar Contract v1.
@matteo8p, if this direction is useful, I will keep the PR limited to the local fixture, tests, and README.
Feature
Add a small, deterministic MCP reliability fixture for the ambiguous-success boundary: a mutating tool commits its external write, but the caller loses the result. A blind retry can duplicate the mutation even when neither MCP transport nor server automatically retries it.
This would let MCP client and agent authors test a safety property that protocol conformance alone cannot prove: whether their workflow reconciles destination state before replaying a side effect.
Solution
I propose an isolated example under
examples/reliability/ambiguous-success/with:external_result_uncertain, performs read-after-write reconciliation through a stable opaque operation marker, and does not call create againThe example would stay vendor-neutral: no hosted service, API key, model call, or Agent Enhancer dependency. I can contribute the implementation and tests if this location and shape fit the SDK examples.
Alternatives
A built-in protocol conformance check would overstate what MCP can guarantee because retry safety depends on tool semantics and destination capabilities. A standalone SDK fixture keeps this explicitly at the workflow/reliability layer.
Additional Context
We reproduced the boundary in a real gated-write MCP: erpipe-org/mcp-odoo#61. The state names and reporting boundary are documented in the vendor-neutral Reliability Sidecar Contract v1.
@matteo8p, if this direction is useful, I will keep the PR limited to the local fixture, tests, and README.