/**
 * The single remote-tool builder and the declarative control-tool table.
 *
 * Two ideas live here, and the point of putting them together is that they share
 * one philosophy: **one builder, never a family of near-identical factories.**
 *
 * 1. {@link buildRemoteTool} is the *only* place a catalog operation becomes a
 *    native {@link DefinedTool}. Given a {@link RemoteTool} reference and a backend
 *    port, it mints a tool whose `run` forwards the model's arguments to
 *    `backend.execute(ref.name, …)` and folds the {@link RemoteResult} back into the
 *    kernel's {@link ToolResult} shape. This is the `CONNECTOR_TOOLS` concept: a
 *    remote tool is data (`ref`) plus this single rendering function — not a
 *    bespoke class per operation.
 *
 * 2. The four **control** tools (attach / run / link / status) are described as
 *    DATA in {@link CONNECTOR_TOOLS}: each entry is an `id`, a JSON-Schema
 *    `parameters`, a `description`, and a `run(backend, input)` thunk. A single
 *    {@link buildControlTools} maps over the table and calls {@link defineTool}
 *    once per row. There is no `createXTool` per control tool and no trailing
 *    singleton — the repetition a clone detector loves is gone.
 *
 * The vendor SDK is nowhere in sight: everything routes through the
 * {@link SaasBackend} port, so this whole module is testable with a plain object.
 */
import type { DefinedTool, ToolResult } from "../../../capabilities";
import type { JsonSchema } from "../../../llmgateway/contract";
import type { RemoteTool, SaasBackend } from "./port";
/** What every tool built here is handed: the backend port it routes through. */
export interface ToolDeps {
    /** The inverted backend the tool's `run` calls into. */
    readonly backend: SaasBackend;
    /**
     * Optional pinned account to execute remote operations under. Omit to let the
     * backend choose the appropriate connected account.
     */
    readonly accountId?: string;
}
/**
 * Mint a native {@link DefinedTool} from one catalog operation.
 *
 * The returned tool advertises the operation's own `inputSchema` to the model and,
 * on invocation, forwards the parsed arguments straight to
 * `deps.backend.execute(ref.name, input, { accountId })`, mapping the
 * {@link RemoteResult} onto a {@link ToolResult}. This is the single bridge from
 * "a remote tool reference" to "a tool the agent can call" — there is no per-
 * operation subclass or factory.
 */
export declare function buildRemoteTool(ref: RemoteTool, deps: ToolDeps): DefinedTool;
/**
 * One row of the control-tool table: a control tool described purely as data.
 *
 * `id` is the model-facing tool name, `parameters` its JSON Schema, `description`
 * its prose, and `run` a backend-driven thunk. Instantiation into a
 * {@link DefinedTool} is done once, generically, by {@link buildControlTools}.
 */
export interface ControlToolSpec {
    /** The model-facing tool name (e.g. `"saas.run"`). */
    readonly id: string;
    /** Model-facing description of the control tool. */
    readonly description: string;
    /** JSON-Schema object for the control tool's parameters. */
    readonly parameters: JsonSchema;
    /** The control tool's behavior, expressed against the backend port. */
    run(backend: SaasBackend, input: Record<string, unknown>): Promise<ToolResult>;
}
/** Read a string-array field from a loose argument bag, dropping non-strings/blanks. */
declare function strList(input: Record<string, unknown>, key: string): string[];
/**
 * The control tools, as one declarative table.
 *
 * `saas.attach` hydrates a toolkit's operations (discovery of what can be made
 * native), `saas.run` executes a single operation directly, `saas.link` opens an
 * authorization flow, and `saas.status` inspects connection state. Each is a row;
 * none is a hand-written factory.
 */
export declare const CONNECTOR_TOOLS: readonly ControlToolSpec[];
/**
 * Instantiate every row of {@link CONNECTOR_TOOLS} into a {@link DefinedTool},
 * binding each to the supplied backend.
 *
 * This is the single factory the spec calls for: one map over the data table, one
 * `defineTool` per row, no per-control-tool boilerplate. The `strList` helper is
 * exported-adjacent here so future control rows can read array fields uniformly.
 */
export declare function buildControlTools(backend: SaasBackend): DefinedTool[];
export { strList as readStringList };
