import type { ChatMessageBase } from '../../components';
import type { ApplyFiltersParams, ChatToolMessage, ClientSideToolShouldRenderContext, ResolvedSearchParams, SearchToolInput } from '../../components/chat/types';
/**
 * The shape `getResolvedSearchParams` needs from a chat message: just its
 * parts, structurally. Kept local so the lookup works against any message
 * list, including one whose data-part registry does not declare
 * `tool-output-metadata`.
 */
type ChatMessageWithParts = {
    parts?: ReadonlyArray<{
        type: string;
        data?: unknown;
    }>;
};
export declare const getTextContent: (message: ChatMessageBase) => string;
export declare const hasTextContent: (message: ChatMessageBase) => boolean;
export declare const isPartText: (part: ChatMessageBase["parts"][number]) => part is Extract<ChatMessageBase["parts"][number], {
    type: "text";
}>;
export declare const isPartTool: (part: ChatMessageBase["parts"][number]) => part is ChatToolMessage;
export declare function isReasoningPartActive(parts: ChatMessageBase['parts'], index: number): boolean;
/**
 * Whether a text part renders nothing. `text-start` creates the part before its
 * first delta, and `<context>` wrappers are a shim `ChatMessage` also drops.
 */
export declare const isPartTextEmpty: (part: Extract<ChatMessageBase["parts"][number], {
    type: "text";
}>) => boolean;
/**
 * Whether a part says something about the turn's progress. Data parts and
 * unwritten text parts render nothing, so reading them would answer "what is
 * this turn doing" with a part that changed nothing on screen.
 */
export declare const isPartProgressSignal: (part: ChatMessageBase["parts"][number]) => boolean;
export declare const findLastProgressPart: (parts: ChatMessageBase["parts"] | undefined) => ChatMessageBase["parts"][number] | undefined;
/**
 * Resolves the tool a message part belongs to, from either a part type
 * (`tool-algolia_search_index`) or a bare tool name.
 *
 * An exact registration wins. Otherwise only tools whose `matchesToolName`
 * claims the name are considered, most specific first, for servers that name a
 * call after the registered tool: the Algolia MCP Server appends the index name
 * (`algolia_search_index_products`).
 *
 * Generic over the tool shape: the renderer, the loader, the widget and the
 * connector hold different subsets of the tool contract.
 */
export declare const findTool: <TTool>(partType: string, tools: Record<string, TTool>) => TTool | undefined;
/**
 * Reads the resolved search params a search tool call was answered with.
 *
 * The metadata arrives as a transient data part next to the tool call. It is
 * read from `messages` rather than through `onData` because the chat retains
 * every `data-*` part on the message, which covers the live and the replayed
 * conversation with one path. Returns `undefined` when the part is absent —
 * the case whenever the server does not emit `_meta` — or when its value is
 * not a single params bag, so that the caller falls back to the raw
 * `facet_` keys instead of searching with no filters at all.
 */
export declare const getResolvedSearchParams: (messages: readonly ChatMessageWithParts[] | undefined, toolCallId: string | undefined) => ResolvedSearchParams | undefined;
/**
 * Extracts the refinements a search tool searched with, in the shape
 * `applyFilters` expects.
 *
 * The default search tool provides a ready-to-use `facet_filters` array. The
 * Algolia MCP Server search tool instead expresses refinements as individual
 * `facet_<attribute>` keys (e.g. `facet_categories: ['Books', 'Toys']`), which
 * are converted here into `[['attribute:value']]`.
 *
 * Pass `resolved` (from `getResolvedSearchParams`) to use the filters the
 * server actually searched with instead of re-deriving them from the raw keys.
 * That is the only way to apply a numeric refinement.
 */
export declare const getApplyFiltersParamsFromToolInput: (input: SearchToolInput | undefined, resolved?: ResolvedSearchParams) => ApplyFiltersParams;
/**
 * Whether the agent handed the turn to the Grouped Results tool for this
 * message, i.e. that tool renders the records and the search tool must not.
 *
 * The backend sets exactly one of the two flags, depending on which tool name
 * the agent was configured with: `groupedResultsEnabled` for
 * `algolia_grouped_results`, `displayResultsEnabled` for agents still on the
 * legacy `algolia_display_results`.
 */
export declare const isGroupedResultsEnabled: (metadata: unknown) => boolean;
/**
 * `shouldRender` for the search tool: it presents its own records only on turns
 * the agent did not hand to the Grouped Results tool, which would otherwise
 * present the same records a second time.
 */
export declare const shouldSearchToolRenderResults: ({ parentMessage, }: ClientSideToolShouldRenderContext) => boolean;
export {};