This walkthrough gives your team a deterministic recovery loop: write a known change, inspect history, diff versions, and restore the previous good state.
Why start here
- It validates your auth and workspace setup.
- It proves that recovery works before high-volume automation.
- It creates a shared operational runbook your team can repeat.
Suggested flow
- Create a sandbox workspace dedicated to onboarding.
- Run
write_file on a single test path.
- Capture IDs from
list_versions.
- Compare output with
get_diff.
- Restore a known-good version with
restore_version.
- Confirm final file state with
read_file.
Minimal end-to-end example
API_KEY="sk_live_xxx"
ENDPOINT="https://mcp.undisk.app/v1/mcp"
# 1) write_file
curl -s "$ENDPOINT" \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"write_file","arguments":{"path":"onboarding/demo.txt","content":"hello v1\n"}}}'
# 2) list_versions
curl -s "$ENDPOINT" \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"list_versions","arguments":{"path":"onboarding/demo.txt"}}}'
# 3) get_diff (replace IDs from previous response)
curl -s "$ENDPOINT" \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"get_diff","arguments":{"path":"onboarding/demo.txt","from_version":"ver_old","to_version":"ver_new"}}}'
# 4) restore_version
curl -s "$ENDPOINT" \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"restore_version","arguments":{"path":"onboarding/demo.txt","version_id":"ver_old"}}}'
Verification checklist
- Version history increments after each write.
- Diff output identifies expected line-level changes.
- Restore reverts only the target file path.
- Unrelated files remain unchanged.
Operational guardrails
- Keep this flow in CI smoke tests for integration changes.
- Use dedicated onboarding paths (for example
/onboarding/*) to avoid noisy history.
- Document known-good version IDs when rehearsing incident response.
Coming soon: turnkey workflow templates for this sequence in dashboard onboarding and starter scripts.
