[FEATURE] Support OpenAI Responses API tool search and deferred tools

[winter-08]

Problem Statement

OpenAIResponsesModel currently does not support the OpenAI Responses API tool-search/deferred-tools workflow. The provider docstring notes that tool_search is unsupported because it requires defer_loading on function tools, and the request formatter currently emits Strands tool specs only as basic function tools with type, name, description, and parameters.

This means Strands users cannot use the Responses API’s native deferred tool loading to work efficiently with large or dynamic tool catalogs. In practice, applications must either send all tool schemas up front, manually prune the tool list outside Strands, or dynamically manage tools in the application. That makes large tool libraries more expensive, more latency-prone, and less cache-friendly.

Proposed Solution

Add first-class OpenAI Responses API tool-search support in OpenAIResponsesModel, including:

• Pass through defer_loading: true for deferred Strands function tools.
• Allow Strands tools to be represented as OpenAI Responses namespace tool groups where appropriate, since namespaces provide better token savings than deferring individual functions.
• Add {"type": "tool_search"} support, including hosted tool search.
• Parse and preserve tool_search_call and tool_search_output response items so loaded tools remain available across turns.
• Support client-executed tool search by allowing applications/plugins to respond with tool_search_output.
• Support additional_tools input items for advanced workflows that dynamically add tools at a specific point in the conversation.
• Add tests for regular tools, deferred tools, namespace-deferred tools, hosted tool search output, client-executed tool search output, and cache-preserving dynamic tool loading.

Use Case

This would enable Strands agents using OpenAIResponsesModel to work with large tool libraries and MCPs without sending every tool schema on every request. It would also unblock tool_search-style workflows for OpenAI Responses API users, reducing prompt size and making dynamic tool discovery practical for agents with many available tools.

Alternatives Solutions

• Rebuild the request with a dynamically selected subset of tools before each model call. This can reduce the number of tool schemas sent, but it moves tool-discovery logic into application code and may reduce prompt-cache effectiveness because changes to the normal tools array alter the request prefix.
• Send all tools up front. This is simplest, but increases input tokens, latency, and context pressure for large tool catalogs.

Additional Context

Current source notes tool_search is not supported because it requires defer_loading on function tools:
https://github.com/strands-agents/harness-sdk/blob/main/strands-py/src/strands/models/openai_responses.py

OpenAI Responses API tool search documentation:
https://developers.openai.com/api/docs/guides/tools-tool-search

Related but not duplicative issue:
#1349 tracks Anthropic advanced tool use, including defer_loading, but does not cover OpenAI Responses API tool search.