/**
 * Transient-error classification for an MCP server, in the shape `toolTransientRetry` already speaks
 * (`classify: (error) => boolean`). {@link import('../tool-retry.js').isTransientToolError}
 * recognizes local database lock contention; a remote MCP server fails in a different vocabulary —
 * JSON-RPC error codes, HTTP statuses, socket errors — which is what this adds.
 */
/**
 * True for a remote-MCP failure that the same call, made again, may well survive: a dropped
 * connection, a request timeout, a retryable HTTP status, a socket error. Checked on the error and
 * one level of `cause` — `fetch` reports a socket failure as a bare `TypeError` wrapping the real
 * one, the same wrapping core's classifier already unwraps for database drivers.
 *
 * A protocol-level refusal (`InvalidParams`, `MethodNotFound`) and a server-side `InternalError`
 * are deliberately NOT transient: the identical request would be refused identically, so retrying
 * only spends the turn's time budget.
 */
export declare function isTransientMcpError(error: unknown): boolean;
/**
 * True only for a failure that PROVES the remote tool did not run: the connection was refused, the
 * host was never reached, or the SDK had no transport to send on. Checked on the error and one level
 * of `cause`, so `fetch`'s bare `TypeError` wrapper is read through to the socket error underneath.
 *
 * Everything {@link isTransientMcpError} also accepts — a request timeout, a dropped connection, a
 * 500/502/503, a reset mid-flight — is deliberately excluded: in each of those the request may have
 * arrived and executed, and only the answer was lost. Retrying them would run the tool twice.
 */
export declare function isPreExecutionMcpError(error: unknown): boolean;
//# sourceMappingURL=transient.d.ts.map