A slow database plus eager agent retries is an outage multiplier, argues Mads Hansen in a Dev.to post. The retry traffic consumes the capacity the database needs to recover.
Key facts
- Retry traffic consumes capacity DB needs to recover
- MCP server should interrupt loop before connection acquisition
- Count logical operations separately from attempts
- Half-open state admits few time-bounded requests
- 11 CVEs disclosed across 7,000+ MCP instances in July 2026
A slow database rarely fails alone. Queries take longer. Connection pools fill. Agent requests hit deadlines. Clients retry. The retry traffic consumes the capacity the database needs to recover. This is the classic retry storm, and the Model Context Protocol (MCP) architecture makes it worse because every layer — client, gateway, tool wrapper, driver, scheduler — can retry independently.
Key Takeaways
- A slow database plus eager agent retries is an outage multiplier.
- MCP servers should shed work before connection acquisition to preserve recovery capacity.
Interrupting the loop before connection acquisition
Hansen's argument is that an MCP database server should interrupt this loop before connection acquisition, not after. The recommended controls are admission-time authorization and budgeting, bounded queues by length and age, workload-class isolation via bulkheads, circuits that open only on dependency-health signals, and shedding expired, duplicate, speculative, and low-priority work first. The server should also preserve capacity for cancellation, reconciliation, health, and operator access, and return typed retry guidance instead of an exception sentence.
The half-open state matters as much as the open state. Do not release the whole retry backlog as a recovery probe. Admit a few lightweight, time-bounded requests, add jitter across server instances, and require sustained success before closing the circuit.
Counting logical operations separately from attempts
The most important operational detail is counting logical operations separately from attempts. If the client, gateway, tool wrapper, driver, and scheduler each retry independently, a single user request becomes a small denial-of-service attack. This is not theoretical: the July 2026 CVE disclosures across 7,000+ MCP instances highlighted STDIO transport security risks, and the same layering that creates security surface area also multiplies retry traffic.
This matters more than the press release suggests because MCP is becoming the default tool-calling interface. The stateless MCP spec released July 28, 2026 removed sessions and the initialize handshake, which means more servers will rely on connection-level controls like these. Hansen's guide is prescriptive but does not include benchmark data or production incident numbers; the source is silent on how much capacity is preserved by each control.
What to watch
Watch for MCP server frameworks (TypeScript, Python, C# SDKs) to add built-in circuit-breaker and load-shedding primitives. The C# SDK hit stable 1.0.0 on July 31, 2026; if the spec adds retry-guidance fields in the next release, that signals the ecosystem is adopting Hansen's controls.
Source: dev.to
