MCP ETag on tool results: Sume idempotency_key and job reads

ETag-versioned MCP tool results are a roadmap idea. In Sume, idempotency_key is write dedup, not a cache validator; job reads are separate read tools.

4 min readSume
All posts

Sume's idempotency_key is not an ETag. It deduplicates write and paid calls and says nothing about whether a result changed. To re-check a result, call a read tool such as jobs_status or jobs_result; to retry a write, reuse the same key for the same payload.

The roadmap idea is from the MCP roadmap (last updated 2026-08-22), read 2026-10-01. Sume details are from MCP tools and gates and Jobs and results.

What does the roadmap propose?

It says the team wants to extend MCP's caching approach to support ETags, which should allow versioning the results of primitives, in particular tool calls. It is a goal, and I did not find an ETag field on Sume tool results.

What is idempotency_key for?

The docs describe it as a stable key for transport and dedup, not human approval, required on write and paid tools. Reuse the same key only for the same operation and payload. It protects you from a duplicate paid create when a connection drops; it does not tell you a result is fresh.

Which calls are safe to repeat?

hosted MCP tool behavior, from docs and code read 2026-10-01.
CallKindRepeat how
jobs_list, jobs_get, jobs_status, jobs_result, jobs_events, jobs_waitReadAny time; read tools carry idempotentHint: true
jobs_cancelWriteWith an idempotency_key
Paid createWriteSame key, same payload

How should an agent poll a job?

Poll with the read tools and keep the job id from the create. For long renders, repeat jobs_wait on the same ids rather than resubmitting; the slice is capped at 55 seconds. See MCP jobs_wait for long video jobs. If you need to know whether the tool list itself changed, that is a separate topic covered in the tools/list caching post.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume