Agent safety and infrastructure
MCP Tool Annotations Remain Too Limited to Support Transaction Safety, Study Catalogs Eight Types of Agentic External-Side-Effect Anomalies
A new study categorizes eight types of external-state anomalies caused by agent retries, parallel execution, and compensation, showing that a successful response from an individual tool does not guarantee consistency across the overall workflow. A survey of 98,291 MCP tools found that annotation fields are common but cannot express outcome confirmation, staged commits, compensation, or cross-call dependencies.

A study published on September 14 reframes agent-tool reliability as a problem of consistency in external side effects: an individual API call may succeed locally, while retries, speculative execution, parallel branches, or partial failures can still leave the overall workflow in an incorrect state. For example, retrying after a payment response is lost can result in a duplicate charge; a canceled branch may leave behind a nonrefundable order; and two independently valid parallel bookings may together exceed the total budget.
The authors propose an effect-history model that deliberately distinguishes effects that have occurred in the real world, the executor’s observations of their outcomes, and the workflow’s eventual commit or abort. From this model, they identify eight classes of anomalies: duplicate effects, committed workflows missing required effects, orphaned compensation, residual effects after cancellation, premature externalization, contaminated speculative results, conflicting externalization, and phantom compensation. Preventing these anomalies in general requires tool boundaries to support capabilities such as logical operation IDs, authoritative status queries, idempotent retries, declarative compensation, dry-run or staging, stable resource identities, dependency tracking, and coordination over shared resources. Merely wrapping black-box tools in a smarter agent layer is insufficient.
For the accompanying survey, the researchers selected the latest version of each server from 59,625 version records in the MCP Registry and anonymously probed 9,234 remote endpoints. A total of 4,838 reachable servers returned 98,291 tools. Of those tools, 74.0% provided at least one standard hint field, and 61.7% provided all four, but only 12.9% included an applicable destructive-operation classification. A single combination—`readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true`—accounted for 39.9%, suggesting that field completeness may simply reflect framework defaults and should not be equated with complete transactional semantics.
The study does not demonstrate that the scanned tools actually produce these anomalies: 4,318 remote targets were unreachable, stdio-based servers were excluded, and the subset of tools assumed to have side effects was inferred solely from tool names. A key question for future work is whether MCP or higher-level contracts can standardize outcome queries, compensation, staging, and resource scopes—and enable executors to verify state before retrying—instead of treating four boolean hints as a safety guarantee.