pub struct ToolSpec {
pub name: String,
pub description: String,
pub schema_json: Value,
pub title: Option<String>,
pub needs_approval: bool,
}Expand description
Declaration of a tool the model may invoke.
Fields§
§name: StringUnique tool name; the model references this when emitting a ToolCall.
description: StringHuman-readable description of what the tool does.
schema_json: ValueJSON Schema object describing the tool’s argument shape.
title: Option<String>MCP-style human display name for this tool (the title annotation):
a friendly label shown to people (e.g. in an approval prompt) while the
machine-facing name stays the audit identifier.
None means no curated label was provided; callers derive a display
name from name via humanize_tool_name.
needs_approval: boolIntrinsic “this tool is side-effecting / requires human approval” flag.
When true the tool must be routed through the harness’s
human-in-the-loop (HITL) approval gate before it executes, even when no
operator-side allow-list names it. Pure, read-only tools leave this
false.
This is the per-tool generalization of the old hard-coded
approval-by-name list: it maps from the MCP destructiveHint tool
annotation, so an upstream connector that advertises a destructive tool
is gated per-tool rather than per-connector.
Defaults to false and is skipped when serializing the safe default, so
older payloads that omit the field still deserialize as ungated.