The report
A November discussion in the Model Context Protocol repository describes a sharp difference between tool metadata and task authorization. With forced tool choice enabled over a set that included mutating operations, the contributor recorded 460 unauthorized simulated writes in 816 trials. Without forcing, the same setup produced five such writes. When the forced-choice set was limited to tools authorized by the task, the reported count fell to zero in the 816 tested trials. These are contributor-run experiments using mock tools and selected hosted models, not observed incidents across live MCP services. Read the issue and methods.
The mechanism is subtle. A tool may advertise readOnlyHint or destructiveHint, but those annotations describe a tool's reported properties; they do not grant permission on behalf of the user. If a client forces the model to call some tool when the requested read operation is unavailable, an otherwise plausible tool-selection policy can turn a read-only request into a write. The canonical Case retains the exact denominator and test setup.
Empty authorized sets are a policy decision
Restricting the candidate set is useful only if the executor handles the empty set safely. A client may need to stop, request a new explicit grant or answer without a tool, but must not silently enlarge authority because the original task could not be completed. The reported 0/816 is evidence for the tested allowlist behavior, not a guarantee that a broader deployment would never misclassify a tool.
This finding supports a general rule: a model's choice is not the source of authority. Authorization belongs to the caller and is enforced again where state-changing effects occur.