A host lets the model call tools repeatedly until it decides it is done. A buggy prompt makes the model call the same paid search tool hundreds of times within one task. Which safeguard best prevents this kind of runaway loop?
Select an answer to reveal the explanation.
Short Explanation
A model stuck in a loop is like a toddler pressing the elevator button — it'll keep going until somebody puts a limit on it. You cap the number of iterations and set a hard ceiling on time that no amount of progress chatter can extend. Hints and cache settings don't count calls.
Full Explanation
The MCP specification places loop and time limits on the implementations, not on the model. In the sampling feature's tool loop, both parties SHOULD implement iteration limits for tool loops, and the cancellation guidance says implementations SHOULD establish timeouts for all sent requests and, even if they reset a timeout when progress notifications arrive, SHOULD always enforce a maximum timeout to limit the impact of a misbehaving peer. The same principle applies to a host's agentic loop: an iteration cap and an overall deadline bound the cost of a model that never decides it is done. Resetting the timeout on every progress notification without any ceiling is exactly what the maximum-timeout rule exists to prevent. idempotentHint says repeated calls with the same arguments have no additional effect on the environment; it says nothing about cost, the hint is untrusted unless the server is trusted, and a paid search still bills each call. ttlMs is a freshness hint for cached list results and has no bearing on how many times the model invokes a tool. Exam caveat: hosts also SHOULD keep a human in the loop who can deny tool invocations, which complements but does not replace hard limits. Operational check: run a test task that forces repeated calls and confirm the host stops at the configured iteration cap and deadline.