import { CallToolResult } from "../../../../confluent/schema.js";
import { ToolCategory, ToolConfig } from "../../../../confluent/tools/base-tools.js";
import { ToolMetadataHandler } from "../../../../confluent/tools/tool-metadata-handler.js";
import { ServerRuntime } from "../../../../server-runtime.js";
/**
 * Diagnostic tool that surfaces *why* tools are absent from `tools/list` or
 * unavailable on a given connection.
 *
 * `tools/list` advertises the enabled tool set but not the predicate-driven
 * decision behind every absence. This handler returns that view, shaped around
 * connections: one section per configured connection listing the tools
 * disabled on it (bucketed by the missing config piece, or by functional area
 * under `group_by="category"`). A tool enabled on one connection and disabled
 * on another shows up in the latter's section, so the cross-connection
 * asymmetry is readable by comparing sections. A zero-connection config
 * collapses to a dedicated summary; a single-connection config is simply one
 * section. Connection-independent tools are advertised everywhere and never
 * appear in a section.
 *
 * The structured `_meta` mirrors the rendered text; see the
 * {@linkcode ToolGatingReport} JSDoc in `tool-availability.ts`.
 *
 * Always enabled (predicate is `alwaysEnabled`) so an operator can call it
 * to diagnose a config that left every other tool disabled.
 *
 * The tool catalog is supplied through the thunk that {@link
 * ToolMetadataHandler} owns, for the ESM-cycle reason documented there.
 */
export declare class ExplainDisabledToolsHandler extends ToolMetadataHandler {
    handle(runtime: ServerRuntime, toolArguments: Record<string, unknown> | undefined): CallToolResult;
    getToolConfig(): ToolConfig;
    readonly category = ToolCategory.McpServerDiagnostics;
    readonly predicate: import("../../../../confluent/tools/connection-predicates.js").ConnectionPredicate;
}
//# sourceMappingURL=explain-disabled-tools-handler.d.ts.map