pub trait ChatbotToolDeclaration {
const NAME: &'static str;
const CATEGORY: ToolCategory;
// Required methods
fn offer_requirements(
user_context: &ChatbotTurnContext,
) -> Vec<ToolRequirement>;
fn get_tool_definition() -> AzureLLMFunctionToolDefinition;
}Expand description
What a tool is called and how it is declared to the LLM.
Shared by the tools the server runs (ChatbotTool) and the tools the client answers (ClientChatbotTool): the two differ in who produces the output, not in how the tool is advertised.
Required Associated Constants§
Sourceconst NAME: &'static str
const NAME: &'static str
The name the LLM calls this tool by. The registries dispatch on it and Self::get_tool_definition must advertise it, so the two cannot drift apart.
Sourceconst CATEGORY: ToolCategory
const CATEGORY: ToolCategory
Which configured category of tools this belongs to. A chatbot offers it only if its configuration lists this category; the caller must still be authorized for it.
Required Methods§
Sourcefn offer_requirements(user_context: &ChatbotTurnContext) -> Vec<ToolRequirement>
fn offer_requirements(user_context: &ChatbotTurnContext) -> Vec<ToolRequirement>
What the caller must be allowed to do against the turn itself for this tool to be offered to the LLM at all.
Coarse on purpose: no call has named a target yet, so this asks about the chatbot’s own
course (or global permissions for a chatbot with none). The binding check is the tool’s
call_requirements, against what the call actually targets. Empty for a tool the
chatbot’s own access check already covers.
Sourcefn get_tool_definition() -> AzureLLMFunctionToolDefinition
fn get_tool_definition() -> AzureLLMFunctionToolDefinition
The definition sent to the LLM as part of a chat request. Azure rejects it unless strict
is true and the parameter schema forbids additional properties.
Dyn Compatibility§
This trait is not dyn compatible.
In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.