/**
 * Deterministic {@link DataContract} derivation from MCP tool schemas.
 *
 * Given a primary data tool (with `outputSchema`) and optional action tools
 * (with `inputSchema`), produces a complete contract — no LLM needed.
 *
 * This is the Screen Designer's Tier 1 fast path: when a ggui-first-party MCP
 * server ships native `outputSchema` on every tool, the contract falls out of
 * the schema automatically. The agent supplies the wiring (data tool + action
 * tools); ggui derives the rendering contract.
 *
 * Tier 2 (learned `generatedOutputSchema`) uses the same deriver — the caller
 * passes the learned schema instead of the native one.
 */
import type { ActionSpec, DataContract, JsonSchema, PropsSpec } from "../types/data-contract.js";
/** An MCP tool spec, as it appears in tools/list (subset we care about). */
export interface McpToolSpec {
    name: string;
    description?: string;
    inputSchema?: JsonSchema;
    outputSchema?: JsonSchema;
}
export interface DeriveContractInput {
    /** Display name of the owning server, used to build the intent string. */
    serverName: string;
    /** Primary tool — its outputSchema becomes the component's props. */
    dataTool: McpToolSpec;
    /** Optional MCP tools the UI hints at on its gestures. Each becomes an ActionEntry with `nextStep` set to the tool name (advisory hint the agent reads on `ggui_consume` to decide which tool to call next). */
    actionTools?: McpToolSpec[];
    /** Optional intent override. Default: derived from serverName + dataTool.name. */
    intent?: string;
    /** Optional tool-name prefix to strip when generating action keys and labels.
     * Only strips when the tool name actually starts with `${toolPrefix}`. Default: none —
     * the full tool name is used. Supply this only for servers that prefix their tools
     * (e.g. `toolPrefix: "gmail_"` turns `gmail_search_messages` into `searchMessages`).
     * Bare-named tools (`get_task`, `complete_task`) must NOT use this. */
    toolPrefix?: string;
}
/**
 * Build a DataContract from native MCP tool schemas.
 *
 * Behavior:
 * - `intent` — "<serverName> — <humanized tool verb>" unless overridden.
 * - `props` — each top-level property of dataTool.outputSchema becomes a PropEntry.
 *   If outputSchema is not an object schema, a single `data` prop wraps the whole thing.
 * - `actions` — one ActionEntry per actionTool, with `nextStep` set to the MCP tool
 *   name (advisory hint) and `schema` set to the tool's inputSchema (if present).
 *
 * Pure — deterministic given identical input.
 */
export declare function deriveContract(input: DeriveContractInput): DataContract;
/** Convert an outputSchema into a PropsSpec. */
export declare function propsFromOutputSchema(outputSchema: JsonSchema | undefined, description?: string): PropsSpec | undefined;
/** Convert a list of action-tools into an ActionSpec, one entry per tool.
 * Collisions (two tools camelCase-ing to the same key) are resolved by appending
 * a numeric suffix — the raw tool name is always preserved on the
 * entry's `nextStep` hint. */
export declare function actionsFromTools(actionTools: McpToolSpec[], toolPrefix?: string): ActionSpec;
/** Humanize a tool name, optionally stripping a known server prefix.
 * `humanizeToolName("gmail_search_messages", "gmail_")` → "Search Messages".
 * `humanizeToolName("get_task")` → "Get Task". */
export declare function humanizeToolName(name: string, toolPrefix?: string): string;
/** Strip `toolPrefix` iff `name` starts with it; otherwise return `name` unchanged. */
export declare function stripPrefix(name: string, toolPrefix?: string): string;
/** "search_messages" → "searchMessages". */
export declare function camelKey(name: string): string;
//# sourceMappingURL=derive-contract.d.ts.map