How to customize name and description for built-in tools (e.g. AzureAISearchTool) for use with agents?

Question

Hi, I'm trying to make use of the built-in tools with agents, and they work well enough as-is, but there is just one issue. It seems their names and descriptions are hard-coded, or at least I haven't been able to find a way to change them. To even see the descriptions and names I had to question the model itself. If I understand correctly, the LLM uses these to decide when and how to call the tools, so it seems rather important to have them specified as closely to my usecase as possible, including things like language.

The best practices section here even specifically mentions we should refer to tools by name in the system prompt. And yet the built-in tool names aren't even documented anywhere. I guess I am just confused.
Am I limited to the system prompt in this? What's the deal?

An example for reference, in case it's relevant. I'm using the python SDK. If I try to create a custom AzureAISearchToolDefinition, it won't accept any arguments other than 'type="azure_ai_search"'

        connid = (await client.connections.get_default(ConnectionType.AZURE_AI_SEARCH)).id
        tool = AzureAISearchTool(connid, "myindex", top_k=3)
        tooldef = AzureAISearchToolDefinition({"name":"asdf"})  # fails on request, doesn't accept 'name'
        tooldef = AzureAISearchToolDefinition(name="asdf")  # typing failure, __init__ doesn't take 'name'
        print(tool.definitions[0].items())  # built in is only [('type', 'azure_ai_search)]

Thanks

Answer 1

Hi Mateus Surrage Reis,
At present, the names and descriptions of built-in tools like AzureAISearchTool in the Python SDK are hard-coded and cannot be customized through the SDK’s constructors or definition objects. This means you cannot directly set or change the tool’s name or description by passing arguments such as name or description when creating these tools. The only practical way to influence how the LLM refers to or uses these tools is by carefully crafting your system prompt to explicitly mention the tool’s hard-coded name and provide a description that fits your use case. If you need more control, you would have to create a custom tool wrapper that mimics the built-in functionality but allows you to set your own metadata, though this approach sacrifices some of the convenience of the built-in integrations. For now, direct customization through the SDK is not supported, so prompt engineering remains the main method for tailoring tool usage to your needs.