Can MCP Clients Decide What to Do After Failure? A Result-Only Actionability Audit

Can MCP Clients Decide What to Do After Failure? A Result-Only Actionability Audit Rishabh Mehan

arXiv:2609.00072v1 [cs.SE] 31 Aug 2026

Independent rishabhmehan@gmail.com

Abstract—A client that receives isError:true knows that something went wrong. It may still have no machinereadable basis for deciding whether to fix an argument, authenticate, wait, choose another tool, or stop. This paper studies what deterministic software can learn from a completed MCP failure result alone; request arguments, schemas, discovery history, authentication state, transport metadata, host policy, and application state are outside that boundary. We introduce a sixpart actionability profile and apply it with record-level evidence. In a small illustrative study of 21 safely induced failures from ten reachable sampled servers, typed fields expose failure in 18 cases and a broad policy in 8, yet expose no specific cause, target, executable repair, or replay constraint. Prose often carries more cause and target information, at the price of making semantic interpretation part of the recovery path. A lexical source audit finds the same text-centered pattern. Finally, a fail-closed prototype demonstrates how a separate experimental control plane could support deterministic branching. The result is deliberately narrower than an ecosystem survey or an agent benchmark: completed MCP results often make failure observable, sometimes make a broad response possible, and rarely make concrete recovery or safe replay self-contained in this sample.

I. Introduction A retry is not a neutral response to failure. Repeating a malformed request wastes a call; repeating an unauthenticated request does not restore a credential; repeating a partially committed operation may do real damage. Other failures call for a corrected argument, a delay, a different tool, or human intervention. A Boolean failure marker cannot distinguish among those choices. MCP gives hosts, clients, and tool servers a common language for discovery and invocation [1]. For an ordinary tool-execution failure, the JSON-RPC exchange can still succeed while the result says resultType: complete, sets isError: true, and supplies explanatory content. Protocol failures take a different route through typed JSONRPC errors [2], [3]. The protocol also has a specialized InputRequiredResult and a multi-round-trip workflow for asking for missing input [4]. Those mechanisms matter, but general completed failures still lack standard fields for cause, repair target, policy, timing, or replay safety [5]. In other words, MCP specifies how to observe many failures more fully than it specifies how to recover from them.

Our question is therefore deliberately bounded: given only a completed MCP failure result, how far can deterministic software get toward a safe next action before it has to interpret server-specific prose or look elsewhere? A production client can also consult the original request, the tool schema, discovery history, authentication state, transport metadata, host policy, and application state. We set those sources aside so that the result itself can be measured. The paper contributes: 1) a separately coded, non-cumulative error-actionability profile and componentwise partial order; 2) an auditable, record-level method applied to a versionscoped specification, high-precision lexical corpus audit, and illustrative live case study; and 3) an executable fail-closed conformance refinement that separates machine controls from explanations. We also retain a small, exploratory policy-selection test with two local models. It is a supporting check rather than a central result. The 21 failures are enough to exercise the construct and demonstrate the boundary, but not to estimate registry-wide prevalence, raw-wire behavior, deployed-agent performance, or end-to-end recovery. II. Failure Contracts and Related Work A. MCP failure surfaces MCP failures reach clients through several routes. A protocol error is a JSON-RPC error with an integer code, message, and optional data. A tool-execution error arrives inside an otherwise successful JSON-RPC response and marks its result with isError: true. HTTP and transport failures sit below both. We also observed a fourth, awkward case: a success-shaped error, where the text says the operation failed but the typed result does not. The SDK can alter which of these surfaces an application sees. Official TypeScript SDK guidance describes tool errors as isError:true results read by the model, tells server authors to put a recovery hint in text, and skips outputschema validation for those results [6]. The Python SDK separates ordinary tool failures from protocol and lowlevel failures [7], [8]. Accordingly, our dataset records the Python client’s normalized view; we do not pretend that it preserves the wire representation. An open MCP issue now proposes a schema-governed structured error object for this path [9]. We treat that issue as evidence that the design question is active, not as part of the standard.

B. Machine-facing precedents

moves recovery policy outside the model altogether [37], [38]. Our unit of analysis sits upstream of those agent evaluations. Before asking whether an agent recovers, we ask what the completed MCP result gives a deterministic client to work with. The same profile can later be applied to benchmark failures as well as live observations.

Other protocols make this separation explicit. HTTP Problem Details provides a machine discriminator alongside human-facing detail and warns clients not to automate by parsing that detail [10]; HTTP also defines Retry-After where delay matters [11]. gRPC pairs a constrained status vocabulary with optional prose, then places retryable codes, attempt limits, backoff, and jitter in a separate retry III. A Non-Cumulative Actionability Profile configuration [12], [13]. None of these mechanisms solves For an observation o, define application-specific recovery. They do show that controls a(o) = (D, P, C, T, E, R) ∈ {0, 1}6 , and explanations can be designed for different consumers. That distinction is familiar in operations. Backoff, jitter, where each coordinate is coded separately and no positive retry limits, and circuit breakers exist because an automatic assignment is inherited: retry can deepen an outage [14], [15], [16]. Retry decisions D — Failure detection. are themselves a recurring source of software defects Software distinguishes failure from success. [17]. This literature motivates host-enforced policy, while also setting a clear boundary around our own replay P — Coarse policy. loop: returning the same stored error is not an outage It can select among request repair, authentication, delayed retry, alternate selection, or stop/escalation. experiment. Structured recovery for MCP is not a blank slate. C — Cause/subtype. SERF proposes an isError envelope with categories, It distinguishes causes such as unknown tool, invalid retryability, timing, ordered actions, and a deterministic type/value, authentication, rate limit, or upstream failure. recovery procedure; its recovery-rate claims remain hy- T — Repair target. potheses for a proposed synthetic evaluation [18]. AdCP It identifies an offending tool, parameter, credential, or 3.1.2 carries a namespaced adcp_error through MCP dependency. structuredContent, JSON-RPC error.data, or guarded E — Executable repair. text fallback, and supplies recovery classes, retry bounds, It can construct or execute the recovery without guessing extraction order, validation, and test vectors [19]. We a missing value or performing another discovery step. therefore do not claim to have discovered the gap or R — Replay constraints. invented the control/content split. Our contribution is Timing, unchanged-request safety, and relevant side-effect the narrower one: an auditable way to measure what a state are explicit. completed result makes actionable, together with a failThe six coordinates should not be read as rungs on closed conformance refinement exercised against recorda ladder. A rate-limit response can provide timing (R) level evidence. without a corrected request (E), and a target pointer (T ) need not identify a precise cause (C). We compare C. Agent failure benchmarks and policy systems observations by componentwise dominance: o1 ⪰ o2 iff Recent empirical work maps runtime and software faults every capability evidenced by o2 is also evidenced by o1 . in MCP repositories and practitioner reports [20], [21]; This permits incomparable profiles, although none occur in Winston and Just provide a broader taxonomy for tool- the present sample. We also set a deliberately high bar for augmented LLM systems [22]. Those studies ask what fails E: knowing a repair procedure, possessing the replacement and where. We ask a different question about the failure value, and having authority to act are collapsed into one record: what can ordinary software safely infer from it? end-to-end threshold. Because no record reaches E, the Tool-use benchmarks usually begin later in the loop, present data cannot tease those sub-capabilities apart. with tool choice, arguments, or full trajectories [23], [24], We read each record twice. In the control view, every [25], [26]. Tools Fail examines silent faulty outputs, and string—even a JSON object serialized as text—is opaque. FAIL-TaLMs studies underspecified queries and unavailable In the content-assisted view, model-visible text may be tools [27], [28]. ToolFailBench focuses on behaviors such interpreted. Thus isError earns D in the control view as skipping tools, ignoring results, and fabrication [29]. but not P . JSON-RPC -32602 earns only broad request AgentCheck is especially close: it injects 12 MCP fault repair: in this sample it covers both unknown tools and types and evaluates five agents in a replay/intervention bad arguments, so it cannot identify the cause. Text that workbench with deterministic and human-validated scoring names a field may earn T without earning E if it supplies [30]. Several newer benchmarks study dynamic recovery no valid replacement. The release gives an evidence pointer under injected failures, sometimes across multiple model and rationale for every bit. The distance between the two families [31], [32], [33], [34], [35], [36]. Other work protects views is practical: whenever prose supplies the missing non-atomic calls with postconditions and idempotency, or information, recovery inherits the cost and fallibility of

a semantic interpreter. That problem is separate from information the result omits but a client might obtain elsewhere. More than one response can be safe. For each controlled scenario, we publish a set containing the cause-specific repair and stop/escalate. Since stopping is safe in all 21 cases, membership in that set says little about useful progress. The model stress test therefore reports preferredpolicy matches alongside valid non-stop coverage; selective accuracy is left to the artifact as a sensitivity calculation. IV. Illustrative Case Study A. Specification, sample, and static candidates We froze the specification and schema available on August 19, 2026, using protocol revision 2026-07-28 as the reference point. The accompanying registry snapshot held 23,569 latest records, from which we derived 16,699 unique GitHub repositories [39], [40]. Seed 20260819 drew 54 repositories: 12 each from npm, PyPI, and remote-only listings, and six each from MCPB, OCI, and other listings. When five initial draws were inaccessible, the next seeded repository in the same stratum replaced each one. The public release preserves the derived frame, draw order, exclusions, replacements, final sample, and hashes. It can replay the sampling step from that frame, though it cannot reconstruct the omitted raw registry response. We then used a deliberately narrow lexical scanner to find likely error construction. It excludes dependencies and builds, while retaining and labeling generated, test, and fixture paths for audit. All 16 isError matches in production-classified files were adjudicated by hand. Two were embedded test strings; the remaining 14 matches collapsed to 12 semantic construction paths in ten repositories. To make that filtering inspectable, the release includes the scanner, a privacy-safe 22-row frozen candidate projection, and an 11-row adjudication ledger with repository-relative files, line numbers, decisions, and pinned commits. We do not redistribute the clones, so the filtering decision is auditable even though acquisition is not fully reproducible.

matter most. Our E/R result should be read within that boundary. Python MCP SDK 1.26.0 serializes successful results through model dumping and records exceptions as normalized dictionaries. What we analyze is therefore the client’s normalized view, not an untouched HTTP body or JSONRPC frame. Server and tool identifiers are pseudonymous; endpoint URLs, headers, discovery schemas, timestamps, excluded success/search payloads, and unrestricted observations remain private. We minimized before release rather than attempting to sanitize everything after the fact. Three service-specific observations were replaced by canonical minimal failures because the originals could retain irrelevant third-party fields. The builder, source hashes, redaction counts, and fail-closed privacy scanner are public; the restricted source records are not. C. Coding procedure The frozen codebook was applied independently to each of the six capabilities in both views. I performed this coding as the sole author. A previous AI-assisted pass remains in the artifact as a sensitivity record, but it is not a second human judgment and is not reported as inter-rater agreement. An archival reliability claim would require two trained independent coders and adjudication. The borderline cases show why separate coding matters. S11 and S18 only say that lookup failed for the supplied test value, which establishes D but no unique policy, cause, or target. S21 calls an identifier invalid, enough for P and C, but never names the parameter and therefore misses T . These decisions can be checked directly in the row-level ledger. V. Exploratory Policy-Selection Stress Test A. Conditions and evidence limits

Each failure is replayed under four paired conditions: Normalized. The client-normalized observation alone. B. Low-load probes and released observations Code-only. Fifteen sampled repositories advertised a remote endThe observation plus a namespaced cause code, with no point. Our probes initialized the server, listed tools, called a action field or recommended-action wording. guaranteed nonexistent name, supplied one wrong requiredfield type to a lexically read-only tool, and, for a con- Structured action. servative subset, sent a type-correct but out-of-domain The same code plus the preferred policy in JSON. sentinel. We neither exhausted quotas nor attempted to Prose action. create state or trigger an outage. Ten endpoints initialized The same cause and preferred policy in a sentence. and yielded 21 verified failures. Their negotiated versions Only the code-only/normalized pair tests recovery inference were 2025-03-26 (3), 2025-06-18 (3), and 2025-11-25 (4), as without revealing the preferred answer. The other two recorded in a released pseudonymous table. Five connection conditions ask a different question. Structured action places or initialization failures remain restricted and are not part the exact output label in JSON; prose action gives an of the tool-failure analysis. This low-risk design necessarily imperative and a cause explanation. They expose different favors deterministic failures. It omits rate limits, genuine words as well as different formats, so their contrast is upstream faults, timeouts, partial commits, and uncertain descriptive rather than a controlled format effect. High idempotency—the very cases in which replay constraints performance in either cell is evidence of compliance with

an answer-bearing message, not independent recovery reasoning. The test uses local Llama 3.2 3.2B (Q4_K_M) and Qwen 3.5 0.8B (Q8_0) through Ollama 0.24.0. The runner checks the full immutable model digests recorded in the manifest before inference. Five stochastic replicates for every model, condition, and scenario produce 2 × 4 × 21 × 5 = 840 decisions; the extra replicates are repeated judgments, not new failures. Temperature is 0.7, with seeds paired across conditions. The model returns an operation_status and a recovery_policy; calling a verified failure succeeded counts as false success. No argument is actually repaired, credential acquired, alternative discovered, side effect checked, or task completed. The experiment is therefore about policy labels, not agent recovery. When a model requests immediate replay, the simulator returns the same stored failure, for at most three attempts. The main descriptive outcome is exact agreement with the preferred policy. Coverage requires a valid policy other than stop_or_escalate; invalid responses count as neither coverage nor abstention. Because always stopping belongs to every non-harm set, that measure is only a safety check. We also record false success, invalid output, and needless replay. Results from two small models under one prompt should not be generalized to frontier or deployed agents. B. Descriptive analysis and deterministic baseline The paper reports exact counts for each model and condition, along with predeclared paired differences. Since the failures are not a probability sample and only ten servers contribute observations, an interval would not justify a population claim. Wilson and ten-server cluster-bootstrap calculations remain available as sensitivity analyses in the artifact. We avoid pooling across models and conditions because such a total would mix different systems and different amounts of disclosed information. For comparison, we built a deterministic client. It first checks the ordinary completed-result shape— resultType, content, and the content blocks—then requires isError:true and validates the experimental schema, code, code–target pairing, policy, timing, replay rule, and side effects. A local registry maps the four controlled causes to host policy and adds a transient class for safe immediate or delayed replay. Anything malformed or unsupported stops safely. The prototype is an executable design baseline, not a production extension or a model leaderboard. VI. Results A. Specification and static code The specification check confirms the basic asymmetry. In the pinned 2026-07-28 schema, an ordinary completed CallToolResult has resultType, isError, content, and optional structured content, but no standard tool-failure code, repair target, policy, retry delay, or replay-safety field [5]. Specialized InputRequiredResult/MRTR and typed

TABLE I Separately coded capabilities for 21 observations. Coordinates are not cumulative.

Capability D failure detection P coarse policy C cause/subtype T repair target E executable repair R replay constraints

Control

Content-assisted

18 8 0 0 0 0

21 19 19 18 0 0

protocol errors prevent any blanket claim that MCP has no structured recovery; they simply do not form a general taxonomy for completed failures. The SDK guidance places recovery hints in model-readable text, while issue 3003 treats schema governance on the error path as unresolved [6], [9]. The repository audit tells a similar, though deliberately narrow, story. Each of the 12 adjudicated production errorconstruction paths combines isError with text. Seven produce prose alone; five serialize JSON or mixed JSON inside a text block. None provides a standard code or action. A separately audited repository does define a private structured recovery contract. That example demonstrates feasibility, but also fragmentation: a client cannot assume the contract elsewhere. The released ledger pins the repository and commit and records the safe relative files, line ranges, and fields. B. Joint capability profiles The 21 failures comprise ten nonexistent tools, seven invalid argument types, three invalid values, and one authentication failure. Eight normalize as protocol errors, ten as isError results, and three as success-shaped errors. Table I makes the information boundary visible. Typed fields identify 18 of the 21 records as failures. Eight -32602 observations support a broad “repair the request” policy, but they cover five unknown tools and three invalid arguments; the code alone therefore identifies no specific cause. Once content is interpreted, all 21 failures are visible, 19 support a coarse policy, 19 identify a cause, and 18 name a target. Still, not one observation provides a complete replacement request, explicit retry timing, unchangedrequest safety, or side-effect state. With bits ordered D/P/C/T /E/R, the control profiles are 110000 (8), 100000 (10), and 000000 (3). The contentassisted profiles are 111100 (18), 111000 (1), and 100000 (2). Both sets happen to form chains, with 0 and 0 incomparable pairs, so this sample does not exercise the partial order’s main advantage. Nor should E = R = 0 be overread. In the control view it follows from the missing standard fields; in the content view it describes only this safely inducible failure mix, not transient, rate-limit, upstream, timeout, partial-effect, or idempotency cases.

TABLE II Exploratory policy-label selection; exact counts per 105 decisions. Strict is preferred-policy match; Cover is valid non-stop policy; Retry is wrong identical replay; Any FS is any-step false success; Extra is additional identical calls in the local simulator. Model

Condition

Strict

Cover

Retry

Invalid

Any FS

Extra

Llama 3.2 Llama 3.2 Llama 3.2 Llama 3.2 Qwen 0.8B Qwen 0.8B Qwen 0.8B Qwen 0.8B

Normalized Code-only Structured Prose Normalized Code-only Structured Prose

42 39 95 105 6 5 39 30

105 105 105 105 73 76 84 77

1 1 0 0 24 24 26 23

0 0 0 0 5 6 8 11

0 0 0 0 5 2 2 2

1 1 0 0 48 48 55 42

C. Exploratory model-by-condition results In the only answer-free comparison, adding a symbolic cause code changes strict matches from 42 to 39 for Llama and from 6 to 5 for Qwen. The taxonomy label does not help either model in this setup. When the message discloses the action, structured JSON yields 95 and 39 strict matches, while prose yields 105 and 30. Those cells mainly measure whether the model follows an answer-bearing instruction; their lexical differences rule out a clean format comparison. An always-stop baseline is non-harmful in all 21 scenarios but achieves no strict match or coverage. The code-registry and explicit-policy baselines reach 21/21 by construction. Needless replay is concentrated in the smaller model. Llama repeats the failed request once in each answer-free condition and never does so when the action is supplied. Qwen repeats it 24, 24, 26, and 23 times across normalized, code-only, structured, and prose conditions; because the loop permits further attempts, those choices create 48, 48, 55, and 42 additional calls. Llama adds one, one, zero, and zero. Qwen also accounts for every terminal false-success judgment: 4, 1, 1, and 0 by condition. These figures diagnose this controller and these models. They do not measure load amplification on a degraded service. D. Executable conformance result The deterministic prototype handles all 21 counterfactual controls as designed. Registry and explicit-action modes select both the preferred and a non-harmful policy in every case. Two synthetic transient cases cover safe immediate replay and delayed retry. Seventeen malformed or unsafe inputs must fail closed with an exact reason and stop/escalate; these include missing base content, invalid content shape, three code–target mismatches, and unsafe reachable replay. The suite establishes that the design is executable inside one implementation. It does not establish interoperability or protocol security. VII. An Evidence-Motivated Two-Plane Candidate The evidence points to a modest design rule: do not ask one error string to serve both software and people. Building on earlier structured-recovery proposals, we place

validated controls in a control plane for the host and leave the explanation in content for models and people: Listing 1. Illustrative experimental control envelope. { "resultType": "complete", "isError": true, "error": { "schema": "urn:example:mcp-error:1", "code": "example.mcp.arguments.invalid_type", "target": {"kind": "parameter", "pointer": "/walletAddress"}, "policy": "revise_arguments", "retry": {"sameRequest": "unsafe"}, "sideEffects": "none_committed" }, "content": [{"type": "text", "text": "walletAddress must be a string."}] }

The host first validates the ordinary result, then checks the experimental schema, code–target pairing, policy, replay constraints, and side effects. Only after those checks does it apply local authorization, confirmations, retry budgets, backoff, or circuit breakers. The server is still making assertions: its code, policy, replay claim, and sideeffect claim are not automatically trustworthy. A host must compare them with request identity, local state, and authority. Unknown codes and unavailable capabilities stop safely, while the explanation remains available. The example namespace is intentionally non-official. Where such a control belongs in MCP is still an open design question. A reserved member would need capability negotiation and independent versioning so that a successful tool’s outputSchema cannot quietly redefine failure semantics. Older clients could continue reading isError and content; aware hosts could inspect validated controls before involving a model. Our 21-case implementation goes no further than internal executability. Independent implementations, downgrade behavior, namespace collision, malicious assertions, extension negotiation, SDK validation, and standardization remain untested. VIII. Threats, Ethics, and Reproducibility a) Sampling and representation.: The registry is still a preview, and our sample is not a census. Reachability and low-risk inducibility both select which failures enter the study. Transient, rate-limit, upstream, timeout, partialcommit, and idempotency cases are absent, so the E/R

result cannot speak for them. The lexical audit exhausts The documented commands use only the Python standard one high-precision candidate class rather than every pos- library and run relative to the extracted package. Raw sible error path, and SDK normalization changes fields model responses were not retained, so a third party cannot and exception shapes. These data illustrate a protocol re-audit parser and invalid-output decisions; a future run boundary; they do not estimate prevalence or preserve should preserve those responses and full row-level digests. raw-wire behavior. Clones, the raw registry payload, acquisition traffic, and b) Coding and oracle.: The profile is rule-based and unrestricted endpoint data remain outside the package. coded by one author. Public rationales make each decision IX. Discussion and Conclusion inspectable, but they are no substitute for independent huCalling an error “machine-actionable” hides several man coding. Because every non-harm set permits stopping, the 100% always-stop baseline cannot be interpreted as different questions. Can software see the failure? Can it progress. Preferred policies also remain judgments: a real choose a kind of response? Does it know what broke, what task may allow clarification, discovery, or user-controlled to change, and whether replay is safe? The six-part profile keeps those questions separate. Within our completedauthorization outside our vocabulary. c) Models and inference.: Two small local models, one result-only boundary, deterministic software often sees prompt, and 21 scenarios cannot characterize deployed the failure and sometimes identifies a broad response. It agents, especially when two treatments reveal the answer. usually lacks the cause, target, executable repair, or replay Qwen accounts for nearly all wrong retries and invalid conditions unless it reads server-specific prose or consults responses, which may simply reflect model scale. Prose and other state. Prose is useful evidence, but relying on it puts structure also differ in wording and explanation, not only a semantic interpreter—and its failure modes—inside the serialization. We had neither frontier-model credentials nor recovery path. The model test supports only a modest warning. Showbudget and did not invent a proxy for them. Exact cells lead the analysis; sensitivity intervals remain in the artifact ing these two small models a taxonomy name did not because a non-probability corpus and ten server clusters improve policy selection; showing them the answer mostly tested whether they would follow it. Their needless retries offer little inferential reach. d) Behavioral scope.: The simulator records policy and false-success judgments are reasons to keep failure labels, not repaired requests, downstream completion, or belief separate from recovery policy, not estimates of how side effects. Replaying produces the same stored response. deployed agents behave or how much load retries create There is no backoff, shared load, service recovery, or real during an outage. transient outage, so the additional calls are properties of The two-plane example is best understood as a conthis local controller rather than a degradation result. formance target grounded in the audit, not as the first e) Ethics and privacy.: Probes were low volume and proposal for structured MCP recovery. At minimum, such limited to initialization, nonexistent names, malformed a control plane needs a stable cause code, policy compatarguments on conservatively selected read-only tools, and ibility, an optional target, and explicit assertions about sentinel values. We did not obtain maintainer consent, replay and side effects. Explanations can remain readable conduct a jurisdiction-specific terms review, seek an IRB by people and models. Our client branches deterministically determination, or coordinate disclosure. No production and fails closed on controlled cases. Whether independent calls were made during the later revisions. Endpoint implementations interoperate—and whether the assertions and discovery payloads are absent from the release, and survive adversarial conditions—is still unknown. unrestricted originals stay in private work storage. An The paper’s answer is not simply yes or no. For ordinary earlier unsafe draft bundle was quarantined and is not completed tool errors, MCP standardizes observability distributed. more strongly than recovery semantics, with important A larger IMC/PAM-style collection should begin with exceptions in typed specialized workflows. Software can an identifying User-Agent linked to a study page, an often branch on failure and sometimes on a broad policy opt-out route, community notice, an IRB determination class. In this sample, however, concrete autonomous recovor documented exemption, and coordinated disclosure of ery remains dependent on prose or information outside the success-shaped correctness bugs. None of those safeguards result. Testing how far that conclusion travels will require should be inferred from this pilot; they are requirements independent human coding, raw-wire captures across SDKs, for follow-on work. the missing failure classes, end-to-end recovery experiments, f) Artifact.: The privacy-safe package reproduces the and independent interoperability and adversarial trials. derived analysis. It contains frozen sampling metadata, Acknowledgment exact draw and replacement reconstruction, pseudonymous protocol versions, minimized observations, record-level Generative AI tools (OpenAI Codex and Anthropic rationales, non-harm sets, the lexical scanner and frozen Claude) assisted with literature discovery, code review, candidates, static provenance, 840 parsed decisions, analy- adversarial manuscript review, drafting, and prose editing. sis and conformance code, a runtime manifest, and hashes. The author selected the research question and methods,

verified the cited sources and derived results, made the scientific judgments, and accepts responsibility for the paper. References [1] Model Context Protocol Contributors, “Model context protocol specification,” https://modelcontextprotocol.io/specification/ 2026-07-28, 2026, protocol revision 2026-07-28, accessed 202608-19. [2] ——, “Tools: Error handling,” https://github.com/ modelcontextprotocol/modelcontextprotocol/blob/ 0cb6c6a31768cbb16129b35e6b569a31fecfe1b6/docs/ specification/2026-07-28/server/tools.mdx, 2026, commit 0cb6c6a, accessed 2026-08-26. [3] JSON-RPC Working Group, “Json-rpc 2.0 specification,” https: //www.jsonrpc.org/specification, 2013, accessed 2026-08-19. [4] Model Context Protocol Contributors, “Multi round-trip requests,” https://github.com/ modelcontextprotocol/modelcontextprotocol/blob/ 0cb6c6a31768cbb16129b35e6b569a31fecfe1b6/docs/ specification/2026-07-28/basic/patterns/mrtr.mdx, 2026, protocol revision 2026-07-28, commit 0cb6c6a, accessed 2026-08-26. [5] ——, “Model context protocol schema: 2026-07-28,” https: //github.com/modelcontextprotocol/modelcontextprotocol/ blob/271ecc9accafdd9b83a3c869fa67c22953b2af80/schema/ 2026-07-28/schema.json, 2026, commit 271ecc9, accessed 2026-08-26. [6] ——, “Typescript sdk: Errors,” https://github. com/modelcontextprotocol/typescript-sdk/blob/ ce2f65db0e019506f4d2526466ec8cc7106de98e/docs/servers/ errors.md, 2026, commit ce2f65d, accessed 2026-08-26. [7] ——, “Python sdk: Handling errors,” https:// github.com/modelcontextprotocol/python-sdk/blob/ 56af44727b291c5901d976bff6c6c8eff5649f23/docs/servers/ handling-errors.md, 2026, commit 56af447, accessed 2026-08-26. [8] ——, “Python sdk: Low-level server,” https:// github.com/modelcontextprotocol/python-sdk/blob/ b2025ab815ee4013d12cd3af5e7dba50c2c2868c/docs/advanced/ low-level-server.md, 2026, commit b2025ab, accessed 2026-08-26. [9] antara1414, “[spec gap] tool execution errors lack a schemagoverned signal for LLM forwarding,” Model Context Protocol issue 3003, 2026, opened 2026-07-02; open when accessed 2026-08-26. [Online]. Available: https://github.com/ modelcontextprotocol/modelcontextprotocol/issues/3003 [10] M. Nottingham, E. Wilde, and S. Dalal, “Problem details for http apis,” Internet Engineering Task Force, Tech. Rep. RFC 9457, Jul. 2023. [Online]. Available: https://www.rfc-editor.org/ rfc/rfc9457.html [11] R. T. Fielding, M. Nottingham, and J. Reschke, “Http semantics,” Internet Engineering Task Force, Tech. Rep. RFC 9110, Jun. 2022. [Online]. Available: https://www.rfc-editor.org/rfc/rfc9110.html [12] gRPC Authors, “Status codes,” gRPC Documentation, 2024, accessed 2026-08-20. [Online]. Available: https://grpc.io/docs/ guides/status-codes/ [13] ——, “Retry,” gRPC Documentation, 2025, accessed 2026-08-20. [Online]. Available: https://grpc.io/docs/guides/retry/ [14] M. Brooker, “Timeouts, retries, and backoff with jitter,” Amazon Builders’ Library, 2019, accessed 2026-08-20. [Online]. Available: https://aws.amazon.com/builders-library/ timeouts-retries-and-backoff-with-jitter/ [15] Microsoft, “Circuit breaker pattern,” Azure Architecture Center, 2025, accessed 2026-08-20. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/ patterns/circuit-breaker [16] M. Ulrich, “Addressing cascading failures,” in Site Reliability Engineering. O’Reilly Media, 2016. [Online]. Available: https://sre.google/sre-book/addressing-cascading-failures/ [17] B. A. Stoica, U. Sethi, Y. Su, C. Zhou, S. Lu, J. Mace, M. Musuvathi, and S. Nath, “If at first you don’t succeed, try, try, again...? insights and LLM-informed tooling for detecting retry bugs in software systems,” in Proceedings of the 30th ACM Symposium on Operating Systems Principles, 2024.

[18] V. Srinivasan, “Bridging protocol and production: Design patterns for deploying AI agents with model context protocol,” 2026, version 1, accessed 2026-08-26. [Online]. Available: https://arxiv.org/abs/2603.13417v1 [19] Ad Context Protocol, “Transport error mapping,” AdCP 3.1.2 Documentation, 2026, accessed 2026-08-22. [Online]. Available: https://docs.adcontextprotocol.org/dist/docs/3.1.2/ building/operating/transport-errors [20] J. Owotogbe, I. Kumara, W.-J. van den Heuvel, D. A. Tamburri, A. K. Iannillo, and R. Natella, “A taxonomy of runtime faults in model context protocol servers,” 2026. [Online]. Available: https://arxiv.org/abs/2606.05339 [21] M. Taraghi, M. M. Morovati, and F. Khomh, “Real faults in model context protocol (MCP) software: A comprehensive taxonomy,” 2026. [Online]. Available: https://arxiv.org/abs/ 2603.05637 [22] C. Winston and R. Just, “A taxonomy of failures in tool-augmented LLMs,” in Proceedings of the IEEE/ACM International Conference on Automation of Software Test, 2025, pp. 125–135. [Online]. Available: https://homes.cs.washington. edu/~rjust/publ/tallm_testing_ast_2025.pdf [23] M. Li, Y. Zhao, B. Yu, F. Song, H. Li, H. Yu, Z. Li, F. Huang, and Y. Li, “API-Bank: A comprehensive benchmark for tool-augmented LLMs,” in Proceedings of EMNLP, 2023, pp. 3102–3116. [Online]. Available: https://arxiv.org/abs/2304.08244 [24] Y. Qin, S. Liang, Y. Ye, K. Zhu, L. Yan, Y. Lu, Y. Lin, X. Cong, X. Tang, B. Qian, S. Zhao, L. Hong, R. Tian, R. Xie, J. Zhou, M. Gerstein, D. Li, Z. Liu, and M. Sun, “ToolLLM: Facilitating large language models to master 16000+ real-world APIs,” in International Conference on Learning Representations, 2024. [Online]. Available: https://arxiv.org/abs/2307.16789 [25] S. G. Patil, T. Zhang, X. Wang, and J. E. Gonzalez, “Gorilla: Large language model connected with massive APIs,” in Advances in Neural Information Processing Systems, 2024. [Online]. Available: https://arxiv.org/abs/2305.15334 [26] J. Lu, T. Holleis, Y. Zhang, B. Aumayer, F. Nan, F. Bai, S. Ma, S. Ma, M. Li, G. Yin, Z. Wang, and R. Pang, “ToolSandbox: A stateful, conversational, interactive evaluation benchmark for LLM tool use capabilities,” in Findings of NAACL, 2025, pp. 1160–1183. [Online]. Available: https://arxiv.org/abs/2408.04682 [27] J. Sun, S. Y. Min, Y. Chang, and Y. Bisk, “Tools fail: Detecting silent errors in faulty tools,” 2024. [Online]. Available: https://arxiv.org/abs/2406.19228 [28] E. Treviño, H. Contant, J. Ngai, G. Neubig, and Z. Z. Wang, “Benchmarking failures in tool-augmented language models,” in Proceedings of NAACL-HLT, 2025, pp. 2916–2934. [Online]. Available: https://aclanthology.org/2025.naacl-long.149/ [29] H. Soni, “ToolFailBench: Diagnosing tool-use failures in LLM agents,” 2026. [Online]. Available: https://arxiv.org/abs/2607. 04686 [30] A. Mazumder and N. jahan Lia, “AgentCheck: A reproduceintervene-mitigate workbench for LLM agents over MCP,” 2026, version 3, accessed 2026-08-26. [Online]. Available: https://arxiv.org/abs/2607.11098v3 [31] D. Zhu, X. Ma, Y. Shen, X. Li, Y. Zhao, S. Wang, L. Yan, and D. Yin, “When tools fail: Benchmarking dynamic replanning and anomaly recovery in LLM agents,” 2026. [Online]. Available: https://arxiv.org/abs/2606.05806 [32] C. Chen, V. Nguyen, Z. Zhang, A. Gullapalli, Z. Wang, Y. Lu, D. Wang, J. Huang, Z. Yu, and J. Lai, “Retry, switch, or abstain? learning strategy-aware tool-use policies via controlled error injection,” 2026, version 1, accessed 2026-08-26. [Online]. Available: https://arxiv.org/abs/2608.11977v1 [33] Anonymous, “Failing tools: Benchmarking LLM agent recovery under runtime tool failures,” Anonymous ACL submission on OpenReview, 2026, accessed 2026-08-21. [Online]. Available: https://openreview.net/forum?id=j7YsSnA64D [34] A. Sigdel and R. Baral, “ToolMisuseBench: An offline deterministic benchmark for tool misuse and recovery in agentic systems,” 2026. [Online]. Available: https://arxiv.org/abs/2604. 01508 [35] J. Liu, Q. Lin, C. Qian, R. Wang, E. C. Acikgoz, X. Yang, J. Liu, Z. Wang, X. Chen, H. Ji, and D. Hakkani-Tur, “PlanBench-XL: Evaluating long-horizon planning of LLM

tool-use agents in large-scale tool ecosystems,” 2026. [Online]. Available: https://arxiv.org/abs/2606.22388 [36] Y. Tian, Z. Shi, Y. Zhou, and B. Zhao, “Beyond function calling: Benchmarking tool-using agents under tool-environment unreliability,” 2026. [Online]. Available: https://arxiv.org/abs/ 2606.25819 [37] I. K. Mansoor, A. Phadke, and P. Rana, “Verified tool calls improve LLM agent reliability under non-atomic failures,” 2026. [Online]. Available: https://arxiv.org/abs/2608.02645 [38] A. Sigdel and R. Baral, “Guardrails as infrastructure: Policyfirst control for tool-orchestrated workflows,” 2026. [Online]. Available: https://arxiv.org/abs/2603.18059 [39] Model Context Protocol Contributors, “Official mcp registry api,” https://github.com/modelcontextprotocol/registry/blob/ a25f166b4b5bee06eeecb75e4f37b2a44a8aa5be/docs/reference/ api/official-registry-api.md, 2026, commit a25f166, accessed 2026-08-26. [40] ——, “About the mcp registry,” https:// github.com/modelcontextprotocol/registry/blob/ b941ee3674f5e33578dddefdeb2b928753684cf7/docs/ modelcontextprotocol-io/about.mdx, 2026, commit b941ee3, accessed 2026-08-26.

Related documents

• Lost message detection and recovery protocol#220620
• Empirical Analysis of Current Approaches to Incidental Findings#747502
• SOCpilot: Verifying Policy Compliance for LLM-Assisted Incident Response#160751
• General Admissibility Gating Law: Reproducible Analysis Package#456549
• Fraudulent Transport Documents under the UCP: Controversies and Possible Solutions#24272