The hard case is not the failed call — it is the call that succeeded but whose response was lost. Build idempotency into a tool with real side effects and prove a retry does not double-charge.
What to build
- Build a tool that performs a write with an observable side effect.
- Add an idempotency key derived from the request, supplied by the caller.
- Store processed keys and return the original result on a repeat.
- Simulate the dangerous failure: complete the write, then drop the response.
- Retry and confirm the side effect happened exactly once.
- Handle partial success in a multi-item operation by reporting per-item status.
Done when
- A retry after a lost response produces no duplicate side effect.
- Multi-item operations report per-item outcomes rather than one overall boolean.
- The key is deterministic for the same logical request.
- You can identify which of your tools are safe to retry blindly and which are not.
The trap this exercise teaches
Assuming a timeout means the operation did not happen. A timeout says you did not get the answer, nothing more.
Before you start
The theory behind this build is covered in Idempotency, partial success and safe retries. If any step below is unfamiliar, read that first — the exercise assumes it. Primary source: MCP — Architecture.
Check yourself against the exam
This exercise sits in Domain 4, which is 18% of the CCAR‑F exam. Once you have built it, run a domain drill in the study app and see whether the questions read differently.