import { ToolHandler } from "../../confluent/tools/base-tools.js";
import { ToolDisabledReason } from "../../confluent/tools/connection-predicates.js";
import { ToolName } from "../../confluent/tools/tool-name.js";
import { ServerRuntime } from "../../server-runtime.js";
/**
 * One bucket of disabled tools sharing a single {@linkcode ToolDisabledReason}
 * — the unit operators use to read the diagnostic surface ("what would I add
 * to the connection config to unlock these tools?"). Tool order within
 * `tools` follows the order handlers were iterated.
 */
export interface DisabledToolsByReason {
    readonly reason: ToolDisabledReason;
    readonly tools: readonly ToolName[];
}
/**
 * Output of {@linkcode buildToolGatingReport}; drives the
 * `explain-disabled-tools` diagnostic tool. Tools advertised via
 * `tools/list` are intentionally absent — the report carries the
 * negative signal only.
 *
 * Single-connection scope today (the server enforces one connection; see
 * `enforceSingleConnectionOnly()` in `src/config/models.ts`). When
 * multi-connection support lands as part of issue #151's follow-ups the
 * shape regrows around connections — per-connection sections plus a
 * cross-connection-deltas section calling out tools enabled on some
 * connections but not others.
 */
export interface ToolGatingReport {
    readonly disabledGroups: readonly DisabledToolsByReason[];
    readonly enabledCount: number;
    readonly disabledCount: number;
}
/**
 * One bucket of tools sharing the same `(connectionId, reason)` pair — the
 * unit of one grouped log line at server startup. `toolNames` preserves
 * input iteration order.
 */
export interface DisabledToolGroup {
    readonly connectionId: string;
    readonly reason: ToolDisabledReason;
    readonly toolNames: ToolName[];
}
/**
 * Group fully-disabled tools by `(connectionId, reason)`. A tool is "fully
 * disabled" when every configured connection reports a non-enabled verdict;
 * tools enabled on at least one connection are omitted entirely (they are
 * already going to be advertised by the server, so they don't belong in a
 * disabled-tool log line).
 *
 * Returned groups are sorted lexicographically by `connectionId`. Stable
 * sort preserves the relative order of groups within the same connection.
 */
export declare function groupDisabledToolsByReason(handlers: Iterable<readonly [ToolName, ToolHandler]>, runtime: ServerRuntime): DisabledToolGroup[];
/**
 * Assemble a {@linkcode ToolGatingReport} for the given handler set against
 * the configured connection.
 *
 * v1 (single-connection scope):
 * - `disabledGroups` is sorted lex by reason; tools within a group follow
 *   handler iteration order.
 * - Each tool contributes once to `enabledCount` *or* `disabledCount`:
 *   a tool whose predicate produces an `enabled: true` verdict on at
 *   least one configured connection counts as enabled (and is omitted
 *   from `disabledGroups`); otherwise it counts as disabled and lands
 *   under the first disabled verdict's reason. This flatten is lossy
 *   on a multi-connection runtime — see the handler module-doc for
 *   the consequences and the v2 (multi-connection) shape on
 *   {@linkcode ToolGatingReport}.
 * - Throws `Wacky -- ...` if any handler returns an empty verdict map
 *   (a runtime-shaped invariant violation rather than a tool-state
 *   condition; see `classifyTool` for the rationale).
 */
export declare function buildToolGatingReport(handlers: Iterable<readonly [ToolName, ToolHandler]>, runtime: ServerRuntime): ToolGatingReport;
//# sourceMappingURL=tool-availability.d.ts.map