import { CallToolResult } from "../../../../confluent/schema.js";
import { BaseToolHandler, ToolCategory, ToolConfig } from "../../../../confluent/tools/base-tools.js";
import { ServerRuntime } from "../../../../server-runtime.js";
import { z } from "zod";
export declare const getPartitionOffsetsArgs: z.ZodObject<{
    topicName: z.ZodString;
    partition: z.ZodOptional<z.ZodNumber>;
    cluster_id: z.ZodOptional<z.ZodString>;
    environment_id: z.ZodOptional<z.ZodString>;
}, z.core.$strip>;
/**
 * One partition's offset metadata as the tool returns it. `lowWatermark` and
 * `highWatermark` are strings to preserve int64 precision past JS's 2^53
 * safe-integer boundary; `messageCount` is a `Number` because the BigInt
 * subtraction is done server-side and asking an LLM caller to subtract two
 * int64-typed strings is the wrong ergonomic trade.
 */
export type PartitionOffsetInfo = {
    partition: number;
    lowWatermark: string;
    highWatermark: string;
    messageCount: number;
};
/** Structured response payload mirrored into `result.structuredContent`. */
export type GetPartitionOffsetsResponse = {
    topicName: string;
    partitions: PartitionOffsetInfo[];
};
/**
 * Read-only tool that returns per-partition low/high watermarks (and the
 * derived message count) for a single Kafka topic. Thin wrapper over the
 * broker's `Admin.fetchTopicOffsets` admin call — the metadata primitive
 * that `consume-messages` already relies on internally for `start:
 * "earliest" / "latest" / {timestamp} / {tail}` resolution but doesn't
 * surface in its response.
 */
export declare class GetPartitionOffsetsHandler extends BaseToolHandler {
    handle(runtime: ServerRuntime, toolArguments: Record<string, unknown>): Promise<CallToolResult>;
    getToolConfig(): ToolConfig;
    readonly category = ToolCategory.Kafka;
    readonly predicate: import("../../../../confluent/tools/connection-predicates.js").ConnectionPredicate;
}
//# sourceMappingURL=get-partition-offsets-handler.d.ts.map