import { CallToolResult } from "../../../../confluent/schema.js";
import { BaseToolHandler, ToolConfig, ToolHandler } from "../../../../confluent/tools/base-tools.js";
import { ToolName } from "../../../../confluent/tools/tool-name.js";
import { ServerRuntime } from "../../../../server-runtime.js";
/**
 * Diagnostic tool that surfaces *why* tools are absent from `tools/list`.
 *
 * The MCP protocol already advertises the enabled tool set via `tools/list`;
 * what it does not surface is the predicate-driven decision behind every
 * absence — which config piece is missing, and which tools each gap would
 * unlock. This handler returns that view.
 *
 * v1 scope (today's release): the server enforces a single configured
 * connection (see `enforceSingleConnectionOnly()` in
 * `src/config/models.ts`), so the output is a flat list of disabled tools
 * grouped by the missing config piece (kafka block, flink block, schema
 * registry block, …). Tools enabled on the active connection are
 * intentionally absent — `tools/list` already advertises them.
 *
 * v2 plan (when multi-connection support lands — issue #151's follow-ups):
 * regrow output around connections. The text body becomes one block per
 * connection (header + per-connection gaps) plus a `Cross-connection
 * deltas` section that surfaces tools enabled on some connections but not
 * others — the canonical "what does connection B need to reach parity with
 * connection A?" view. The structured `_meta` shape mirrors that change;
 * see the {@linkcode ToolGatingReport} JSDoc in `tool-availability.ts` for
 * the exact target type.
 *
 * Until v2 lands, the helper accepts a multi-connection runtime without
 * crashing, but the v1 flatten is *lossy*: a tool whose predicate is
 * enabled on at least one configured connection is reported as enabled
 * (and therefore omitted from `disabledGroups` entirely), and a tool
 * disabled on multiple connections with different reasons is bucketed
 * under the first disabled verdict its iteration produces — the
 * cross-connection asymmetry vanishes from the output. Today's
 * single-connection invariant means neither lossy case can fire in
 * production; this paragraph exists so a future reader does not mistake
 * defensive iteration for parity reporting.
 *
 * Always enabled (predicate is `alwaysEnabled`) so an operator can call it
 * to diagnose a config that left every other tool disabled.
 *
 * The handlers iterable is supplied at construction time via a thunk so
 * this module does not need to import `ToolHandlerRegistry`. Importing the
 * registry from a registered handler would create an ESM cycle, leaving
 * the registry's static initializer running before this class's binding
 * is set. The thunk is invoked at request time, after every module is
 * fully loaded, sidestepping the cycle entirely.
 */
export declare class ExplainDisabledToolsHandler extends BaseToolHandler {
    private readonly listHandlers;
    constructor(listHandlers: () => Iterable<readonly [ToolName, ToolHandler]>);
    handle(runtime: ServerRuntime): CallToolResult;
    getToolConfig(): ToolConfig;
    readonly predicate: import("../../../../confluent/tools/connection-predicates.js").ConnectionPredicate;
}
//# sourceMappingURL=explain-disabled-tools-handler.d.ts.map