/**
 * get_knowledge Tool — unified knowledge-lookup entry point.
 *
 * Four kinds behind one tool (KNOWLEDGE_KINDS below is the authority); the
 * first two absorbed the retired standalone knowledge tools:
 *   • knowledge  → queryable X++ rulebook (patterns, BP rules, migration)
 *   • error      → diagnose a D365FO/X++ compiler or runtime error
 *   • op-spec    → parameter contract for one d365fo_file operation/objectType
 *                  or one generate_object mode (issue #825: these no longer ship
 *                  inline in those tools' wire schemas)
 *   • bp-moniker → validate/search a BP-check diagnostic moniker, or render a
 *                  _BPSuppressions.xml block (src/knowledge/bpMonikers/)
 *
 * The knowledge/error handlers take the request only (no context). Handler files
 * stay where they are — only the MCP surface is consolidated.
 */
import type { CallToolRequest } from '@modelcontextprotocol/sdk/types.js';
export declare const KNOWLEDGE_KINDS: readonly ['knowledge', 'error', 'op-spec', 'bp-moniker'];
export type KnowledgeKind = (typeof KNOWLEDGE_KINDS)[number];
export declare function getKnowledgeTool(request: CallToolRequest): Promise<{
    isError?: undefined;
    content: {
        type: string;
        text: string;
    }[];
} | {
    content: {
        type: string;
        text: string;
    }[];
    isError: boolean;
}>;
/** Cap: the point is to save round trips, not to let one call return everything. */
export declare const MAX_TOPICS = 10;
/**
 * Character budget this renderer spends on a multi-topic batch.
 *
 * Sits deliberately BELOW get_knowledge's response cap in toolHandler.ts (16,000),
 * so on a batch that overruns it is THIS code that decides where to stop, not the
 * generic capper. The difference matters: the capper cuts on a block boundary
 * anywhere in the text, which on a topics[] batch means the last topic arrives
 * half-written — an X++ rule truncated mid-sentence is worse than an absent one,
 * because the caller cannot tell it is incomplete. Whole topics only, and a named
 * list of what did not fit so the follow-up call is one topic, not a re-guess.
 *
 * Background: knowledge topics measure 8–12 KB, so under the old 5,000-char
 * default a single one was already halved — which is why topics[] was used 0
 * times in 1,400 sampled calls while op-spec was fetched 186 times one at a time.
 */
export declare const TOPIC_BATCH_BUDGET = 14000;
/**
 * Join rendered topics whole, stopping at the budget and saying what was left out.
 *
 * The first topic is always included even when it alone exceeds the budget: an
 * answer that is only a "did not fit" note is never the useful reply, and the
 * response cap remains the backstop for that case.
 */
export declare function renderTopicBatch(entries: Array<{
    topic: string;
    text: string;
}>, kind: 'knowledge' | 'op-spec', budget?: number): string;
//# sourceMappingURL=getKnowledge.d.ts.map