Bound tool recovery before choosing fallback

Learning objective

Design tool failure policies with bounded retries, backoff, timeouts, circuit breakers, and safe fallbacks.

Core idea

A failure policy decides whether another attempt can succeed safely within the caller’s remaining budget. It needs error classification, a bounded attempt count, a delay policy, and a deadline. A circuit breaker limits pressure on an unhealthy dependency across calls. Fallback chooses another approved outcome or implementation; it must preserve the request’s authorization, result contract, and side-effect constraints.

A mutation can complete even when its response never reaches the caller. A timeout does not establish safe replay or backend switching. Establish idempotency and reconciliation before recovery; see 2.3.9.

How it works

Classify delivery and execution failures

Separate invalid arguments, denied access, transient dependency failures, and unknown completion. Repeating unchanged invalid input does not repair it. Changing arguments after validation feedback is a corrected request, not a transport retry. A denied call needs an authorization decision, not a fallback that bypasses the denial.

MCP distinguishes JSON-RPC protocol errors from tool execution errors represented by isError: true. A delivered tool error is not the same as a lost response. Classify its business meaning before repeating it: an unavailable dependency might be recoverable, while an invalid account identifier needs correction. Do not use HTTP success alone as the retry classifier.

Azure Logic Apps retry policies apply to supporting triggers and actions when requests time out or return 408, 429, or 5xx. This documented eligibility describes the mechanism; it does not prove that every operation producing those statuses is safe to repeat. Match it to the selected connector operation’s semantics.

Give retries an explicit owner

For supporting Logic Apps operations, configure inputs.retryPolicy with type values default, none, fixed, or exponential. The fixed and exponential forms use count and interval; exponential policies also support minimumInterval and maximumInterval. Use none where another layer owns recovery or repetition is unsafe.

Most supporting connector operations use a default exponential policy with up to four retries, but Microsoft documents exceptions. Inspect the actual action instead of assigning that default to every connector. Also distinguish workflow modes: the documented interval range for Standard stateful workflows is five seconds to one day, while Standard stateless workflows use one second to one minute.

At an API Management-backed HTTP operation, the retry policy executes its children once, then repeats while condition remains true and count has not been exhausted. count is the number of retries, from 1 through 50; the initial execution is additional. A configured count="2" therefore permits three executions, not two.

With only interval, API Management uses fixed delays. Add delta for linear delays; supply interval, delta, and max-interval for its exponential algorithm, which randomizes the delta contribution. first-fast-retry="true" skips the first retry delay. An immediate retry does not protect against synchronized overload.

Do not independently wrap those gateway retries in client retries and connector retries. Three client attempts, each permitting three gateway executions, each permitting five connector attempts, can produce forty-five downstream attempts. Choose one owner for ordinary transient recovery, or explicitly divide a shared budget across layers. Count actual downstream attempts in telemetry, including those hidden from the final caller.

Bound retries in tool code

For a .NET tool implementation making HTTP calls without a gateway, Microsoft.Extensions.Http.Resilience provides AddStandardResilienceHandler() on IHttpClientBuilder. Its documented strategy order is rate limiter, total timeout, retry, circuit breaker, and attempt timeout. Use this pipeline as the HTTP retry owner, rather than adding an independent outer retry loop.

The defaults are a zero-length queue and 1,000 permits; a 30-second total timeout covering retries; three retries with exponential backoff, jitter, and a two-second delay; a circuit breaker with a 10% failure ratio, minimum throughput of 100, 30-second sampling duration, and five-second break; and a 10-second attempt timeout. Tune these to the operation’s budget rather than treating them as service quotas.

By default, the handler retries all HTTP methods. Set options.Retry.DisableForUnsafeHttpMethods() to disable retries for POST, PATCH, PUT, DELETE, and CONNECT. For HTTP-backed mutation tools, an eligible status does not establish business replay safety. This handler governs HTTP requests, not every function execution or an entire agent task; keep result validation and fallback inside the application’s remaining deadline.

Bound elapsed time independently

An attempt cap does not bound wall-clock time. Budget per-attempt duration, backoff, validation, and fallback under one application deadline. Stop scheduling work when the remaining time cannot accommodate it.

API Management forward-request supports timeout in seconds or timeout-ms in milliseconds, but not both. These settings bound the wait for backend response headers, not completion of an entire streamed tool result. Microsoft warns that values above 240 seconds might not be honored because network infrastructure can drop idle connections. A long header timeout is therefore neither a reliable end-to-end deadline nor proof that the backend stopped work.

For repeatable HTTP requests, buffer-request-body="true" lets forward-request reuse the request body on retry. That preserves bytes; it does not make the business operation idempotent. For streaming backends, buffer-response="false" preserves immediate chunk delivery. Apply those settings to the HTTP integration you own rather than treating an entire MCP session as a replayable business operation.

Stop pressure with a circuit breaker

API Management backend resources expose circuitBreaker.rules, including failureCondition, tripDuration, and acceptRetryAfter. A rule can use failure counts or percentages within an interval and status-code ranges. When the circuit trips, the gateway stops sending requests to that backend and returns 503; traffic resumes after the trip duration.

Backend circuit breakers are not supported in the Consumption tier. Microsoft documents one rule per backend and approximate tripping because gateway instances do not synchronize their failure information. Do not describe the breaker as an exact global counter or promise that every instance opens simultaneously.

acceptRetryAfter can use the backend’s indicated wait duration; review whether that duration fits your recovery expectations.

Preserve the contract in fallback

A safe fallback can be a compatible approved backend, a clearly labeled stale read, deferred work, or an explicit unavailable outcome. Choose one that satisfies the operation’s purpose. A cached value is inappropriate when the caller requires a fresh decision; a second mutation backend is inappropriate when the primary outcome is unknown.

For API Management routing, set-backend-service with backend-id selects a configured backend. The retry documentation demonstrates switching backends after 429. Treat that sample as routing mechanics, not a universal license to replay tools. Require compatible arguments, equivalent authorization, acceptable data handling, and a shared remaining budget before switching.

Validate fallback results through the same checks as primary results; see 2.3.10. If output has already reached the user, do not silently append a different backend’s answer as if it were one complete result. Return an explicit incomplete outcome when the application cannot preserve a coherent response.

Key distinctions and trade-offs

Retry versus circuit breaker: Retry recovers an individual call. A breaker suppresses calls to a failing backend over a period. Increasing retries can undermine the breaker’s recovery purpose.

Timeout versus cancellation of effects: A caller stops waiting at its deadline. That observation does not establish whether a downstream write committed.

Fallback versus bypass: An approved alternative preserves the original constraints. Routing around authorization, approval, or result validation is a different and unacceptable policy.

A delivered tool error and a lost response take different recovery paths: a delivered error is corrected or retried by its business meaning, while a lost response is reconciled before recovery.

Architecture / decision scenario

An invoice assistant performs a read and a notification. The team gives the read one application deadline, assigns transient retries to its HTTP gateway integration, and disables overlapping connector retries where that ownership applies. It configures a bounded retry count, exponential delay attributes, and a forward-request header timeout inside the total budget.

A backend circuit-breaker rule suppresses repeated server failures. When the read cannot recover, the application considers a compatible secondary backend through set-backend-service; it accepts the result only after the same freshness and quality checks. If no approved path fits the remaining time, it returns unavailable.

A tool-code implementation without that gateway can instead use AddStandardResilienceHandler() as its HTTP retry owner, with unsafe-method retries disabled. The notification’s lost response is different. The assistant reconciles the recorded operation identifier before repeating the side effect. It does not turn an uncertain send into a second send at another backend. Telemetry separates retry counts, breaker rejections, timeouts, fallback use, and unresolved completion so the team can diagnose recovery rather than hiding it behind apparent success.

Common exam traps

• Counting API Management retry.count as total executions.
• Multiplying independent client, gateway, and connector retries.
• Treating request buffering as business idempotency.
• Treating a header timeout as a deadline for a complete streamed result.
• Assuming a breaker is an exact counter shared by all gateway instances.
• Switching mutation backends after an uncertain outcome without reconciliation.

What to remember

Classify failure, establish replay safety, and coordinate one finite recovery budget. Backoff spreads attempts, timeouts bound waiting, and breakers reduce pressure. Fallback spends the remaining budget and preserves the same authorization, approval, and result requirements.

Knowledge check

References

• Microsoft, Build resilient HTTP apps: Key development patterns.
• Microsoft, Handle workflow errors and exceptions.
• Microsoft, Azure API Management policy reference - retry.
• Microsoft, Azure API Management policy reference - forward-request.
• Microsoft, Azure API Management backends.
• Model Context Protocol, Tools, revision 2026-07-28.