/**
 * Tool-hosted authorization wiring for authored tools that resolve auth
 * providers inline with {@link ToolContext.getToken} and
 * {@link ToolContext.requireAuth}.
 *
 * Mirrors the connection authorization flow (see
 * `runtime/framework-tools/connection-search-dynamic.ts`) but scopes the
 * per-step token cache and framework-owned callback URL by the tool's
 * path-derived name and provider key instead of a connection name. All the shared
 * machinery — principal resolution, cache reads/writes, the park/resume
 * webhook dance, and the loop guard — lives in
 * `runtime/connections/scoped-authorization.ts`; this module is the thin
 * execution-layer adapter that wraps one tool's `execute`.
 */
import type { ToolExecuteOptions } from "#shared/tool-definition.js";
/**
 * Wraps one authored tool's `execute` with a context that supports inline
 * provider auth (`ctx.getToken(connect("..."))`).
 *
 * On a thrown provider-scoped authorization request — implicit from
 * `ctx.getToken(provider)` or explicit via `ctx.requireAuth(provider)` — the
 * wrapper either fails terminally (token rejected immediately after sign-in)
 * or evicts the rejected token from the per-step cache and starts the
 * interactive flow, returning an `AuthorizationSignal` to park the turn.
 * Interactive strategies never rethrow the raw `Required` into the model: if
 * no callback URL can be minted, they fail with a classified
 * {@link ConnectionAuthorizationFailedError} instead. Non-interactive
 * strategies rethrow the original error because they have no consent flow to
 * park on.
 */
export declare function createToolExecuteWithAuth(input: {
    readonly scope: string;
    readonly execute: (toolInput: unknown, ctx: unknown) => unknown;
}): (toolInput: unknown, options: ToolExecuteOptions) => Promise<unknown>;