An unauthenticated demo MCP server issues handles that let the model resume a document-drafting workspace across tool calls. Anyone holding a handle can use that workspace. How should the server design these handles?
Select an answer to reveal the explanation.
Short Explanation
On an unauthenticated server, a handle is a house key — whoever holds it gets in. So you make it impossible to guess and you make it expire. The trap is treating it as a harmless label when nobody is checking identity.
Full Explanation
The stateful-tools guidance distinguishes authenticated from unauthenticated servers. On an authenticated server, a handle is a name, not a capability, and the server validates the caller's authorization against it on every call. On an unauthenticated server the handle is necessarily a bearer token, so it should be generated with sufficient entropy, for example a UUIDv4, and given a bounded lifetime. The guidance also favors opacity, since handles that encode internal structure invite parsing or guessing, and it recommends stating the retention policy in the creation tool's description so the model and user know how long state lasts. Sequential integers are trivially guessable, and the premise fails here because an unauthenticated server has no identity to check per call. Handles derived from an email address and a date leak personal data, encode structure and can be reconstructed by anyone who knows the inputs. Permanent handles maximize the window in which a leaked handle can be abused and leave stored state growing without limit. Exam caveat: when the server later adds authentication, it should bind each handle to its creating principal and check that binding on every call. Operational check: create several handles and confirm they show no visible pattern, expire on schedule, and are rejected with a clear tool execution error afterward.