Support for tool_search in AzureChatCompletion

[AisheeDasgupta]

Hi team,

I’m exploring the new tool search capability available in the OpenAI Responses API, where tools can be dynamically discovered and loaded at runtime using:

client = OpenAI()
client.responses.create(
    model="gpt-5.4",
    input="List open orders for customer CUST-12345.",
    tools=[
        crm_namespace,
        {"type": "tool_search"},
    ],
    parallel_tool_calls=False,
)

This is very useful for reducing token usage and improving latency by avoiding preloading all tool definitions.

However, when using the Semantic Kernel connector with AzureChatCompletion, I don’t see any equivalent support for tool_search, if I did not miss it. The class currently only exposes configuration-related parameters (e.g., deployment, endpoint, credentials), and there doesn’t appear to be a way to pass dynamic tool discovery options.

Questions:
Are there plans to support tool_search (or similar dynamic tool loading) in AzureChatCompletion within Semantic Kernel?
If not, is there a recommended workaround to achieve similar behavior when using Azure OpenAI deployments?

Any guidance or roadmap insights would be greatly appreciated.

Thanks!

[Manoj-Gujare]

Hi @AisheeDasgupta,

Great question-this is a very relevant gap when moving toward more agentic / dynamic tool usage patterns.

Current Situation

As of now, Semantic Kernel’s AzureChatCompletion connector does not natively support tool_search (or dynamic tool discovery) like the newer OpenAI Responses API.

The connector is primarily designed around:

• Predefined plugins / functions
• Static tool registration at initialization time

So you're correct-there isn’t a direct way today to pass something like:

{"type": "tool_search"}

and have tools dynamically resolved at runtime.

---

Recommended Workarounds

1. Manual Tool Routing Layer (Closest to tool_search)

You can implement a lightweight “tool registry + selector” before invoking Semantic Kernel:

• Maintain a registry of available tools (name + description + schema)
• Use a model call to select relevant tools dynamically
• Pass only those selected tools into Semantic Kernel execution

This mimics tool_search behavior while keeping SK in the loop.

---

2. Planner-Based Approach (Semantic Kernel Native)

Leverage SK planners (like stepwise planners):

• Let the planner decide which functions/plugins to call
• Tools are still preloaded, but usage becomes dynamic

Limitation:
Tools are not discovered at runtime, only selected.

---

3. Hybrid Approach (Recommended for Agentic Systems)

Combine:

• External orchestration (agent layer)
• Semantic Kernel execution

Flow:

User Query → Tool Selector (LLM) → Filter Tools → Pass to SK → Execute

This gives:

• Lower token usage
• Dynamic behavior
• Better scalability

---

Azure Limitation Note

Even when using Azure OpenAI deployments, feature parity with the Responses API (like tool_search) may lag or differ depending on API version.

---

Summary

• No native tool_search support in AzureChatCompletion (currently)
• Achievable via custom orchestration layer
• Best approach: hybrid agent design + dynamic tool filtering

---

Suggestion

If this capability is important, it might be worth opening a feature request in the Semantic Kernel repo to support:

• Dynamic tool providers
• Runtime tool resolution

[jagmarques]

Tool search works with AzureOpenAI but you need to use the Azure OpenAI Responses API, not the Chat Completions API. The tool_search feature is part of the Responses API which requires a compatible model deployment (GPT-4o or newer). Make sure your AzureChatCompletion service is configured to use the responses endpoint rather than the legacy completions path. If you are on an older API version, you may need to bump api_version to 2025-03-01-preview or later.

[moonbox3]

We recommend migrating to our SK V2 SDK - Microsoft Agent Framework.