Expand description
Salvor tools: the typed tool-contract layer for the agent runtime.
A tool is a typed, effect-classified operation a model may call. This crate defines what a tool is and how the runtime dispatches one; it declares contracts and performs no IO. Persisting tool-call events and driving the dispatch is the runtime’s job, built on the seam this crate exposes.
§The layers
- The typed contract.
ToolMetacarries a tool’s identity andEffect;ToolHandleradds its typedInput,Output, and asynccall. The split is the seam the future#[derive(Tool)]macro cuts: the macro generatesToolMeta, the user writesToolHandler. SeeToolMeta’s docs for the exact contract. - The tool outcome.
ToolHandler::callreturns aToolOutcome: either anOutput, or aSuspensionthat parks the run for a human. Suspension is a return value in v0.1, not a runtime call. - Type-erased dispatch.
DynToolis theValue-in/Value-out, dyn-compatible trait the runtime dispatches through.TypedTooladapts anyToolHandlerinto aDynTool, validating the model’s JSON against the input type before the handler runs. MCP-backed tools (a later task) implementDynTooldirectly. - The registry.
ToolSetregisters tools by name, looks them up, and enumerates them asToolDescriptors for a model. Duplicate names are aRegistryError. - Retry policy.
RetryPolicyencodes the per-effect rule for retrying a failed live execution. It classifies; the runtime loop enforces. - MCP tools. Behind the
mcpcargo feature (on by default), themcpmodule connects to an MCP server over stdio and surfaces each of its tools as aDynTool, registering alongside native tools. All of the MCP dependency surface (the rmcp SDK, a Tokio runtime) is gated behind that feature, so the contract layer above still builds with--no-default-features. MCP stays isolated to that one module by design: rmcp/MCP protocol churn is a standing risk.
§Errors
A tool’s own failure is a HandlerError. The erased layer’s error is a
ToolError, whose InvalidInput variant (the
model sent malformed arguments, and the handler never ran) is deliberately
distinct from Handler (the tool ran and failed), so
the runtime loop can route them differently.
Modules§
- mcp
- Model Context Protocol (MCP) integration: connect to an MCP server over
stdio (a spawned child process) or streamable HTTP (a remote server by URL),
and surface each tool it reports as a
DynToolthe runtime dispatches through like any native tool.
Structs§
- Handler
Error - The error a
ToolHandlerreturns from its own code. - Suspension
- A tool’s request to park the run and wait for a human (or any out-of-band) input before continuing.
- ToolCtx
- What the runtime hands a tool for one execution attempt.
- Tool
Descriptor - The metadata a
ToolSetexposes for one tool when enumerating tools for a model: everything the model needs to decide whether and how to call it. - ToolSet
- A collection of tools keyed by name.
- Typed
Tool - Wraps a typed
ToolHandleras a type-erasedDynTool.
Enums§
- Effect
- The side-effect classification a tool declares, re-exported from
salvor_coreso a tool author needs only this crate. Both the hand-writtenToolMeta::EFFECTand theToolderive name it through here. How a tool call may be retried and how it behaves on replay. - Registry
Error - The error
ToolSetregistration returns. - Retry
Policy - Whether and how a failed live tool execution may be retried, as a function
of the tool’s
Effect. - Tool
Error - The error the type-erased dispatch layer
(
DynTool::call_json) returns. - Tool
Outcome - The
Okside of a tool call: either the tool’s normal output, or aSuspension.
Traits§
- DynTool
- A tool with its types erased:
Valuein,Valueout, dispatched by name. - Tool
Handler - The behavior half of the tool contract: typed input, typed output, and the
async
callthat turns one into the other. - Tool
Meta - A tool’s static identity: the name a model calls it by, a human
description, and its side-effect
Effectclass.