import type { JinnMcpContext, JinnMcpTool } from "./toolkit.js";
/**
 * GRS-018 (§3b) — bearer resolution with a gateway.json fallback.
 *
 * Precedence: explicit opts.token → inherited JINN_GATEWAY_TOKEN env → the
 * `token` field of the 0600 `<JINN_HOME>/gateway.json`.
 *
 * Why the fallback exists: codex spawns MCP stdio servers with a CLEAN env
 * (probe-verified — ~8 baseline keys), so under codex the inherited-env channel
 * is cut and, with auth enabled, every builtin-jinn call would 401. The engine
 * adapters pass the non-secret JINN_HOME through their allowlisted per-session
 * config channel; this function then reads the token from the SAME 0600
 * same-uid file the gateway minted it into — the token itself never rides argv
 * or any jinn-written config. No widening: third-party servers get the scrubbed
 * env (no JINN_HOME grant), and a same-uid process could already read the file.
 */
export declare function resolveServerToken(explicit?: string): string | undefined;
export { gatewayGet, gatewayRequest, JinnMcpToolError, type JinnMcpContext, type JinnMcpTool } from "./toolkit.js";
/**
 * Build the full tool set, one group per company surface: org, sessions,
 * company-reference search, scoped knowledge, Notes, Experiments, cost reads,
 * cron reads, the delegation transaction, Todos/work-items, approvals, managed
 * files, connectors, session-armed heartbeats, and Workflows.
 * Growth discipline: the belt budget lives in the GRS-017 design §7 and the
 * GRS-020 design §4 (net context diet positive — measured in
 * mcp/__tests__/context-diet.test.ts and knowledge-diet.test.ts); at this
 * current size the hand-rolled protocol below is still comfortably sufficient —
 * revisit the SDK question only if a future group needs capabilities beyond
 * tools/list + tools/call (resources, prompts, progress).
 */
export declare function buildTools(opts?: {
    notesEnabled?: boolean;
    workflowAttempt?: boolean;
}): JinnMcpTool[];
/** Read once at MCP startup: each engine receives a stable tool manifest. */
export declare function notesEnabledFromConfig(): boolean;
interface JsonRpcRequest {
    jsonrpc?: string;
    id?: string | number | null;
    method?: string;
    params?: Record<string, unknown>;
}
interface JsonRpcResponse {
    jsonrpc: "2.0";
    id: string | number | null;
    result?: unknown;
    error?: {
        code: number;
        message: string;
    };
}
/**
 * Handle a single parsed JSON-RPC message. Returns the response to write, or
 * `null` for notifications (no `id`) and other no-reply messages. Pure except for
 * the gateway HTTP call a `tools/call` makes through `ctx` — so it is directly
 * unit-testable with a stub fetch.
 */
export declare function handleMcpRequest(msg: JsonRpcRequest, tools: JinnMcpTool[], ctx: JinnMcpContext): Promise<JsonRpcResponse | null>;
/**
 * Run the stdio MCP server: read newline-delimited JSON-RPC from stdin, dispatch,
 * write newline-delimited JSON-RPC responses to stdout. Blocks (keeps the process
 * alive) until stdin closes.
 */
export declare function runJinnMcpServer(opts?: {
    gatewayUrl?: string;
    token?: string;
    callerSessionId?: string;
    sessionCapability?: string;
    workflowAttempt?: boolean;
    input?: NodeJS.ReadableStream;
    output?: NodeJS.WritableStream;
}): void;
//# sourceMappingURL=server.d.ts.map