Skip to content

ToolProvider

Defined in: packages/core/src/tools/provider.ts:70

Tools extends ToolSet = ToolSet

ToolProviderContext = unknown

optional contextSchema?: ZodType<unknown, ToolProviderContext, $ZodTypeInternals<unknown, ToolProviderContext>>

Defined in: packages/core/src/tools/provider.ts:90

Optional — pure introspection metadata, e.g. for a settings UI to build a form from. Never read or parsed by the framework itself; parsing, if you want it, is your own getTools’s job (see createToolProvider’s doc comment for the recipe). agent.tools exposes this on the bound Agent so a caller can find it without knowing which agent it’s looking at.

Typed z.ZodType<unknown, ToolProviderContext> — output left unconstrained (the framework never parses, so there’s nothing to pin it to), but input pinned to ToolProviderContext, the exact raw value getTools receives via ctx.toolProviderContext. So a schema describing a different shape than getTools actually expects is a compile error, not a silent drift — verified via an isolated repro (a mismatched schema is rejected; Tools inference and AgentDefinition.tools, which is never widened, are both unaffected). ToolProviderContext appears fully generic here whether or not this position ends up widened: AgentDefinition.tools never widens at all, and Agent.tools (mirroring it verbatim) widens along with the rest of the agent into AnyAgentany in every slot, so a concretely-typed contextSchema here needs no separate erasure to tolerate that. AgentRunInput.tools’s bare ToolProvider<Tools> is the one exception, defaulting ToolProviderContext to unknown — not for widening, see ExtendedToolProviderContext’s doc comment.

getTools(ctx): Tools | Promise<Tools>

Defined in: packages/core/src/tools/provider.ts:105

ExtendedToolProviderContext<ToolProviderContext>

Tools | Promise<Tools>


optional listTools(): ToolProviderToolSummary[]

Defined in: packages/core/src/tools/provider.ts:104

Optional — static tool names (and descriptions) for a settings UI to list, for a provider whose tool set doesn’t actually vary by call context. Deliberately not passed an ExtendedToolProviderContext: an inspector calling this has no real agentId / memoryScope / toolProviderContext to offer, only a fabricated one, so this exists precisely to avoid needing one. Never read or called by the framework itself — getTools is still the only thing agent.run / agent.stream resolve against.

Skip this when enumerating tool names genuinely requires a resolved context (e.g. the set of tools itself, not just their behavior, differs per toolProviderContext); an inspector should treat a missing listTools as “can’t introspect this provider” rather than guessing by calling getTools with a made-up context.

ToolProviderToolSummary[]