/**
 * Find a tool by what you want to do, without loading every schema first.
 *
 * This server ships 229 tools. Handing all of them to a model costs ~47k
 * tokens of schema before it reads the user's message, and tool-selection
 * accuracy is measured to fall sharply as the count grows — which is why only
 * the 38-tool `core` set is on by default and the rest sit behind toolsets.
 *
 * That trade has a cost of its own: a tool you cannot see is a tool you cannot
 * know exists. `list_toolsets` answers "what groups are there", which is 21
 * names and no help when you do not know which group owns "make a tilemap
 * autotile". This answers the question actually being asked — "which tool does
 * X" — over every tool, enabled or not, for the price of one small result.
 */
import type { ToolDefinition } from './types.js';
export interface ToolSearchHit {
    name: string;
    toolset: string;
    enabled: boolean;
    summary: string;
    score: number;
    inputSchema?: ToolDefinition['inputSchema'];
}
/**
 * Rank tools against a free-text query.
 *
 * Scoring is deliberately blunt: a term in the NAME is worth much more than
 * one in the description, because tool names in this surface are verb_object
 * and are what the query usually paraphrases.
 *
 * Matching is by rank, not by AND. Requiring every word read well until it met
 * real questions — "bake a navmesh", "see collision shapes", "why is my sprite
 * floating" all returned nothing, because one word of each was absent from the
 * tool that answers it. A query is a description of a goal, not a filter, so
 * every extra word a tool does match lifts it above one that matches fewer.
 */
export declare function searchTools(tools: ToolDefinition[], query: string, options?: {
    limit?: number;
    includeSchema?: boolean;
    enabledNames?: Set<string>;
}): ToolSearchHit[];
//# sourceMappingURL=tool-search.d.ts.map