Decouple toolbox tool schemas

[viswabalaji]

Summary

• add a dedicated ToolboxTool hierarchy for toolbox version payloads, separate from OpenAI.Tool
• limit toolbox-supported tool variants to the public toolbox set plus WorkIQ, FabricIQ, and internal toolbox search
• keep tool_configs on ToolboxTool instead of OpenAI/agent tool schemas
• keep toolbox-only toolbox_search_preview out of OpenAI.Tool[], which is also used by prompt/hosted agents
• make toolbox file search vector_store_ids optional while leaving OpenAI file search unchanged
• support custom_search_configuration on both prompt-agent WebSearchTool and toolbox WebSearchToolbox
• move toolbox-specific types and toolbox copy decorators into src/toolboxes/models.tsp
• regenerate Foundry OpenAPI outputs

SDK caller experience

Before, toolbox version creation reused OpenAI.Tool[], so callers could pass the same broad tool set used by prompt/hosted agents. That meant unsupported toolbox tools like SharePoint grounding could appear valid in typed SDK code:

from azure.ai.projects.models import SharepointGroundingToolParameters, SharepointPreviewTool, ToolProjectConnection

# Before: toolbox tools were modeled as OpenAI.Tool[], so agent-only tools like SharePoint grounding could type-check.
toolbox_version = project.beta.toolboxes.create_toolbox_version(
    toolbox_name="my-toolbox",
    tools=[
        SharepointPreviewTool(name="corp-sharepoint", sharepoint_grounding=SharepointGroundingToolParameters(project_connections=[ToolProjectConnection(project_connection_id="sharepoint-connection")]))
    ],
)

After, toolbox version creation accepts the narrower ToolboxTool[] model. SDK callers use toolbox tool shapes such as FileSearchToolbox and WebSearchToolbox, and unsupported tools like SharepointPreviewTool are not part of the generated toolbox SDK model:

from azure.ai.projects.models import FileSearchToolbox, WebSearchConfiguration, WebSearchToolbox

# After: toolbox tools are modeled as ToolboxTool[], so only supported toolbox tool shapes are exposed.
toolbox_version = project.beta.toolboxes.create_toolbox_version(
    toolbox_name="my-toolbox",
    tools=[
        FileSearchToolbox(),  # vector_store_ids can be omitted for toolbox file search.
        WebSearchToolbox(
            custom_search_configuration=WebSearchConfiguration(
                project_connection_id="bing-custom-search-connection",
                instance_name="learn-domain-search",
            )
        ),
    ],
)

Prompt agents continue to use OpenAI.Tool[], so the OpenAI/agent tool contract remains separate. For example, prompt-agent web search uses WebSearchTool and can use the Microsoft custom search extension documented for Foundry web search:

from azure.ai.projects.models import PromptAgentDefinition, WebSearchConfiguration, WebSearchTool

agent = project.agents.create_version(
    agent_name="MyAgent",
    definition=PromptAgentDefinition(
        model="gpt-5-mini",
        tools=[
            WebSearchTool(
                custom_search_configuration=WebSearchConfiguration(
                    project_connection_id="bing-custom-search-connection",
                    instance_name="learn-domain-search",
                )
            )
        ],
    ),
)

File search before/after

Before, toolbox file search was coupled to OpenAI file search, so callers had to provide vector_store_ids on the OpenAI-style FileSearchTool shape:

from azure.ai.projects.models import FileSearchTool

toolbox_version = project.beta.toolboxes.create_toolbox_version(
    toolbox_name="my-toolbox",
    tools=[
        FileSearchTool(vector_store_ids=["vs_123"]),
    ],
)

After, toolbox file search can evolve independently and callers use FileSearchToolbox, where vector_store_ids can be omitted:

from azure.ai.projects.models import FileSearchToolbox

toolbox_version = project.beta.toolboxes.create_toolbox_version(
    toolbox_name="my-toolbox",
    tools=[
        FileSearchToolbox(),
    ],
)

Unsupported toolbox tools

Before, toolbox payloads reused OpenAI.Tool[], so unsupported OpenAI/agent-only tools such as SharePoint grounding could be modeled in a toolbox request. Now toolbox payloads use the narrower ToolboxToolType union and toolbox-specific models. Unsupported toolbox tools are no longer part of the generated toolbox schema/client model, so they can be caught at compile time in typed SDKs instead of only failing later at runtime.

Validation

• npx tsp format src/tools/models.tsp src/toolboxes/models.tsp
• npx tsp compile .

[github-actions]

Next Steps to Merge

⌛ Please wait. Next steps to merge this PR are being evaluated by automation. ⌛

Comment generated by summarize-checks workflow run.