deepseek-harness/packages/core/tools/src/index.ts

/**
 * Tool registry and execution waterfall. Plugins register tools; the registry
 * feeds schemas into the system prompt, and `execute()` dispatches each call
 * through the `tools/execute` waterfall for sandbox, permission, and hook
 * plugins to wrap or veto.
 *
 * @module @deepseek-ai/dsh-tools
 */

import { Context, Service } from 'cordis'
import type { CallId, ContentBlock, ToolSchema } from '@deepseek-ai/dsh-llm'
import { HarnessError } from '@deepseek-ai/dsh-llm'
import type { Agent } from '@deepseek-ai/dsh-agent'
import type {} from '@deepseek-ai/dsh-system-prompt'

export {
  defineTool,
  schemaSpecToJsonSchema,
  validateArgs,
  ToolArgsError,
  type SchemaSpec,
  type SchemaProp,
  type SchemaType,
  type InferArgs,
  type DefineToolOptions,
  type JsonSchemaObject,
} from './schema.ts'

declare module 'cordis' {
  interface Context {
    tools: ToolRegistry
  }

  interface Events {
    /**
     * Waterfall around every tool execution — the single seam where sandbox,
     * permission, hook, and plan-mode plugins wrap or veto a call. Listeners
     * receive `(exec, next)`: call `next()` to proceed (possibly around your
     * own logic), or return a {@link ToolExecutionResult} without calling
     * `next()` to short-circuit (veto).
     * @mode waterfall
     */
    'tools/execute'(this: ToolRegistry, exec: ToolExecution, next: () => Promise<ToolExecutionResult>): Promise<ToolExecutionResult>
    /**
     * A tool was registered or unregistered (the available tool set changed).
     * @mode emit
     */
    'tools/change'(): void
  }
}

// TODO(review): revisit these shapes when the first real tools and
// sandbox/permission plugins land (e.g. a concurrency-safety hint for
// parallel execution — Claude Code partitions read-only tools; phase 1
// executes sequentially).

/**
 * Category of a tool call, used by a UI to pick an icon / treatment. A neutral
 * vocabulary owned here (NOT an ACP type) so tools describe themselves without
 * depending on any client protocol; a UI bridge maps it to its own enum. The
 * member set mirrors the common ACP `ToolKind` values; `other` is the default.
 */
export type ToolCallKind = 'read' | 'edit' | 'delete' | 'move' | 'search' | 'execute' | 'fetch' | 'other'

// FIXME(tool-presentation): the ToolCallPresentation / ToolResultPresentation /
// ToolTerminal shapes need a rethink. They grew incrementally (title/kind/
// rawInput, then a `content` block, then a `terminal` sub-shape carrying cwd/
// output/exit) and the split of responsibility is now muddy: the call vs result
// terminal fields overlap, the bridge has to reconcile a `content` block AND a
// `terminal` block AND `rawInput` per call, and the "pending vs completed"
// boundary doesn't cleanly map to how editors actually render (terminal card,
// diff, generic card). Before more tools/UIs depend on this, redesign the type
// so a tool declares its render INTENT once (e.g. a tagged union over card
// kinds) rather than a bag of optional fields the bridge stitches together.
// Pin the design in an RFC and migrate dsh-tool-bash + the ACP bridge together.

/**
 * How a tool wants ONE of its calls shown in a UI (an editor's tool-call card,
 * a CLI log line) BEFORE the result is known — the *pending* state. Provider-
 * neutral: a tool returns this from {@link ToolDefinition.presentCall} and a UI
 * plugin (e.g. the ACP bridge) maps it to its own wire shape. The tool owns its
 * own presentation — the UI must not special-case tool names.
 */
export interface ToolCallPresentation {
  /**
   * Human-readable, always-visible label describing what THIS call does (e.g.
   * the model-written one-line summary of a bash command). Keep it short — a UI
   * shows it as a card header / log line. Required: a presentation must have a
   * title (a UI falls back to the tool name only when `presentCall` is absent).
   */
  title: string
  /** Category for icon/treatment; defaults to `other` when omitted. */
  kind?: ToolCallKind
  /**
   * The salient input to surface in a detail/expanded view — e.g. the bash
   * COMMAND itself (as a string), so the title can stay a readable summary
   * while the exact command is still visible. Omit to show nothing; a string is
   * rendered as-is, an object as pretty JSON. NOT the full raw args object
   * unless that is genuinely what a reader wants.
   */
  rawInput?: unknown
  /**
   * UI-facing content to show on the PENDING call alongside the title/card —
   * harness {@link ContentBlock}s, in render order. A terminal tool uses this to
   * surface its human-readable `description` as a text block ABOVE the terminal
   * card (the card itself is requested via {@link terminal} and labelled by the
   * command in `title`), since the card has no description slot. Omit to show no
   * extra content. A UI maps these to its own content blocks and renders a
   * {@link terminal} block (if any) as a terminal card.
   */
  content?: ContentBlock[]
  /**
   * Ask a capable UI to render this call as a TERMINAL (a command running in a
   * working directory), not a generic tool card — set by a tool whose call IS a
   * shell command (e.g. `bash`). Provider-neutral; a UI bridge maps it to its
   * own terminal affordance and a UI that can't falls back to the normal card.
   * Pair with {@link ToolResultPresentation.terminal} for the output/exit.
   */
  terminal?: ToolTerminal
}

/**
 * A request to render a tool call as a terminal. The pending presentation
 * supplies the working directory; the result presentation (see
 * {@link ToolResultPresentation.terminal}) supplies the captured output and exit
 * status. Provider-neutral — no client-protocol types. A UI that supports
 * terminals shows a cwd-headed terminal card with the command, its output, and
 * an exit-status pill; a UI that does not ignores this and renders the ordinary
 * card/content.
 */
export interface ToolTerminal {
  /**
   * Working directory the command ran in, shown as the terminal header. An
   * ABSOLUTE path is used as-is; a RELATIVE path is resolved by the UI bridge
   * against the session workspace (the pure tool presenter can't see the
   * session cwd). Omit entirely to let the bridge use the session workspace.
   */
  cwd?: string
  /** Captured command output (stdout+stderr as the tool chooses to combine them). Result-state only. */
  output?: string
  /**
   * Process exit code, when the run ended by exiting (not a signal). Result-state
   * only; lets a capable UI show an exit-status pill on the terminal card. Omit
   * when the command was killed by a signal or the exit code is unknown.
   */
  exitCode?: number
  /**
   * Signal name that killed the process (e.g. `SIGTERM`), when it died by signal
   * rather than exiting. Result-state only; mutually exclusive with `exitCode`.
   */
  signal?: string
}

/**
 * How a tool wants the COMPLETED call shown — the *result* state, after
 * `execute` returns. Lets the tool reformat its result for a UI distinctly from
 * the model-facing text it returned from `execute` (e.g. wrap command output in
 * a fenced ```console block for monospace rendering, which the model-facing
 * result must NOT carry). All fields optional: a UI keeps the pending-state
 * title and renders the raw result content for anything left unset.
 */
export interface ToolResultPresentation {
  /** Replacement title for the completed call (e.g. append an exit status). Omit to keep the pending-state title. */
  title?: string
  /**
   * UI-facing result content (harness {@link ContentBlock}s), reformatted from
   * the model-facing result. Omit to let the UI render the raw result content.
   * Stays in harness vocabulary; the UI maps these to its own content blocks.
   */
  content?: ContentBlock[]
  /**
   * Terminal output/exit for a call the pending presentation marked as a
   * terminal (see {@link ToolCallPresentation.terminal}). A capable UI renders
   * `output` in the terminal card and shows the exit status; an incapable UI
   * uses `content` (the tool should supply a text fallback there too).
   */
  terminal?: ToolTerminal
}

/** A registered tool: its schema plus the execution function. */
export interface ToolDefinition extends ToolSchema {
  execute(args: unknown, exec: ToolExecution): Promise<ContentBlock[]>
  /**
   * Optional: how to present the PENDING state of one call in a UI, derived
   * from the call's `args` (parsed arguments, `unknown` — the tool validates/
   * narrows its own input). Returning `undefined` (or omitting the method) tells
   * a UI to fall back to a generic presentation (title = tool name, raw args as
   * input). Pure and side-effect-free: a UI may call it during live streaming
   * AND a session-log replay, so it must depend only on `args`.
   */
  presentCall?(args: unknown): ToolCallPresentation | undefined
  /**
   * Optional: how to present the COMPLETED state, given the same `args` and the
   * `result` (`execute`'s content + whether it errored). Returning `undefined`
   * (or omitting the method) tells a UI to keep the pending title and render the
   * raw result content. Pure and side-effect-free for the same replay reason.
   */
  presentResult?(args: unknown, result: ToolResult): ToolResultPresentation | undefined
}

/** The completed outcome handed to {@link ToolDefinition.presentResult}. */
export interface ToolResult {
  /** The model-facing content `execute` returned (or the error text on failure). */
  content: ContentBlock[]
  /** Whether the call failed. */
  isError: boolean
}

/** One pending tool call, as it flows through the execution waterfall. */
export interface ToolExecution {
  callId: CallId
  name: string
  /** Parsed JSON arguments (unknown — tools validate their own input). */
  arguments: unknown
  /** The agent on whose behalf the call runs (set by the agent loop). */
  agent?: Agent
  signal?: AbortSignal
}

/** Structured error metadata for a failed tool call (alongside the model-facing text). */
export interface ToolErrorInfo {
  name: string
  code: string
}

/**
 * Thrown (internally) when the model requests a tool that isn't registered.
 * Extends {@link HarnessError} (`code: 'UNKNOWN_TOOL'`) so an unknown-tool
 * failure is as routable as a tool-thrown one — retry/sandbox/replay code can
 * distinguish it from a tool body's own error.
 */
export class ToolNotFoundError extends HarnessError {
  constructor(public readonly toolName: string) {
    super(`unknown tool "${toolName}"`, 'UNKNOWN_TOOL')
    this.name = 'ToolNotFoundError'
  }
}

/** The outcome of one tool call. */
export interface ToolExecutionResult {
  callId: CallId
  content: ContentBlock[]
  isError: boolean
  /**
   * Set when the call failed with a {@link HarnessError}: machine-routable
   * `{ name, code }` for retry/sandbox plugins and replay. The model-facing
   * text in `content` is always present; this is extra structure for code.
   */
  error?: ToolErrorInfo
}

/**
 * Best-effort human-readable message from an arbitrary thrown value: Error
 * instances use `.message`; non-Error objects with a string `message`
 * property (e.g. `throw { message: 'denied' }`) use it too; everything else
 * is stringified.
 */
function errorMessage(error: unknown): string {
  if (error instanceof Error) return error.message
  if (typeof error === 'object' && error !== null
    && 'message' in error && typeof error.message === 'string') {
    return error.message
  }
  return String(error)
}

/** Structured `{ name, code }` for a thrown HarnessError, else undefined. */
function errorInfo(error: unknown): ToolErrorInfo | undefined {
  return error instanceof HarnessError ? { name: error.name, code: error.code } : undefined
}

/**
 * Tool registry (`ctx.tools`): tool plugins register definitions; the agent
 * loop executes calls through the `tools/execute` waterfall. The registry
 * contributes its schemas into the system-prompt assembly.
 */
export class ToolRegistry extends Service {
  static inject = ['systemPrompt']

  private store = new Map<string, ToolDefinition>()

  constructor(ctx: Context) {
    super(ctx, 'tools')
    ctx.systemPrompt.tools(() => this.schemas())
  }

  /**
   * Register a tool. Throws if a tool with the same name is already
   * registered. The tool's schema (minus the `execute` function) is
   * automatically contributed to the system-prompt assembly. Disposed
   * with the calling fiber. Emits `tools/change` on register/unregister.
   */
  register(definition: ToolDefinition): () => void {
    const dispose = this.ctx.effect(function* (this: ToolRegistry) {
      if (this.store.has(definition.name)) {
        throw new Error(`tool "${definition.name}" is already registered`)
      }
      this.store.set(definition.name, definition)
      // Yield the rollback BEFORE emitting `tools/change`: a generator effect
      // collects each yielded disposer before the next step runs, so a throwing
      // `tools/change` listener removes the tool instead of leaking it (a leak
      // would wedge the duplicate-name check until restart). The duplicate
      // throw above fires before any mutation — it leaks nothing.
      yield () => {
        this.store.delete(definition.name)
        this.ctx.emit('tools/change')
      }
      this.ctx.emit('tools/change')
    }.bind(this), 'tools.register()')
    // ctx.effect's disposer returns Promise<void>; our disposer API is
    // synchronous fire-and-forget — discard the (always-resolved) promise.
    return () => void dispose()
  }

  get(name: string): ToolDefinition | undefined {
    return this.store.get(name)
  }

  /**
   * Return all registered tool schemas — exactly the model-facing fields
   * (`name`, `description`, `parameters`, and `strict` when set), as sent to the
   * model via the system-prompt assembly. Constructed EXPLICITLY rather than by
   * stripping known non-schema members: a `ToolDefinition` also carries
   * `execute` and the optional `presentCall`/`presentResult` UI callbacks, and
   * those (especially the functions) must never leak into a model request. An
   * allowlist can't drift when a new non-schema member is added to the
   * definition; a denylist (rest-destructure) would silently leak it.
   */
  schemas(): ToolSchema[] {
    return [...this.store.values()].map(({ name, description, parameters, strict }): ToolSchema => ({
      name,
      description,
      parameters: structuredClone(parameters),
      ...strict !== undefined ? { strict } : {},
    }))
  }

  /**
   * Execute one tool call through the `tools/execute` waterfall. If the tool is
   * not registered, the result is an `isError` carrying a `UNKNOWN_TOOL`
   * structured error. If the tool or a waterfall listener throws, the error is
   * caught and returned as an `isError` result so the loop records a failed tool
   * call instead of failing the whole turn; a thrown {@link HarnessError}
   * surfaces its `{ name, code }` on the result.
   */
  async execute(exec: ToolExecution): Promise<ToolExecutionResult> {
    try {
      return await this.ctx.waterfall(this, 'tools/execute', exec, async (): Promise<ToolExecutionResult> => {
        try {
          const tool = this.store.get(exec.name)
          // Unknown tool routes through the same catch as a tool-thrown error, so
          // both failure classes get structured `{ name, code }` from one path.
          if (!tool) throw new ToolNotFoundError(exec.name)
          const content = await tool.execute(exec.arguments, exec)
          return { callId: exec.callId, content, isError: false }
        } catch (error: unknown) {
          return toolErrorResult(exec.callId, error)
        }
      })
    } catch (error: unknown) {
      return toolErrorResult(exec.callId, error)
    }
  }
}

function toolErrorResult(callId: ToolExecution['callId'], error: unknown): ToolExecutionResult {
  const info = errorInfo(error)
  return {
    callId,
    content: [{ type: 'text', text: `Error: ${errorMessage(error)}` }],
    isError: true,
    ...info ? { error: info } : {},
  }
}

export default ToolRegistry