Microsoft Discovery tools and model integration

This guide covers how tools work in Microsoft Discovery and how to integrate your models into agent workflows. It explains tool types, integration patterns, and how to get started.

What are tools?

Tools allow agents to perform specific operations in a repeatable, consistent, and efficient manner. Many operations are already reliably implemented in the form of Software Development Kits (SDK) or Application Programming Interfaces (API). For example, reading and writing to a database happens through a vendor API, which is typically well-documented and optimized. Other examples of where to use a tool include complex or performance-based algorithms or simulations that can't tolerate stochasticity. Tools enable AI models and their agents to direct their workflow reliably and efficiently to interact with existing systems. Examples of tool uses include:

• Computational tools provide the necessary algorithms to solve complex mathematical problems, simulate physical phenomena or engineering systems, and analyze large scientific datasets.

• Data processing tools manage and refine data collected from various sources. They allow users to extract relevant information, remove noise, and preprocess data for further analysis within the Discovery platform.

• Simulation tools can model and simulate physical, chemical, or biological processes, and complex engineering systems using the platform's Supercomputer resources. These tools are crucial for experimentation that can't feasibly be conducted in practice due to constraints such as time, cost, or safety concerns.

• Visualization tools interpret scientific data or engineering design data and communicate findings graphically. These tools transform data into graphical representations like charts, graphs, and 3D models, making it easier to explore models, identify patterns, and uncover trends and anomalies.

Tool types

Containerized Discovery tools expose actions, code environments, or both. These are authoring patterns within a tool definition, not separate ARM resource types. All are registered as Microsoft.Discovery/tools. See Create a tool definition.

Action-based tools

Action-based tools are used when the software requires an operating system, such as with commercial, proprietary, or open-source packages. These packages are commonly distributed as binaries or have complex installation requirements. Examples are simulators, emulators, compilers, visualizers, linters, design automation tools, modeling packages, and similar complex software packages.

Tools are installed in a Docker image that is then stored in a container registry. The execution profile of each action the tool should perform, along with arguments, required inputs, and expected outputs, is annotated in the tool's profile. The tool definition's annotations provide the agent with the context of the execution and purpose so that it can effectively plan the invocation.

Code-environment based tools

A code-environment based tool enables a Microsoft Discovery agent to run custom code or generate an on-demand tool. Any language that the controlling agent can generate and a software development kit is accessible can be used. Code-environment based tools allow an agent to quickly author and execute code. Novel algorithms or dynamically created tools generated by a model are the most likely target scenarios for code-environment based tools.

Hybrid tools

A hybrid definition includes both actions and code_environments, backed by container infrastructure. It combines predefined operations with agent-generated code that uses the container's installed libraries.

Requirements for authoring tools

Both action-based and code-environment tools require container infrastructure and a tool definition. Store the image in a registry accessible to the Microsoft Discovery Supercomputer. For a code environment, the definition specifies the runtime, installed capabilities, and command used to execute generated code.

Cardinality and execution profile

Store a tool definition in a resource-group-level Microsoft.Discovery/tools resource, not as a child of a workspace or project. Projects can reference an existing tool instead of creating a separate resource for each project. Creating the resource doesn't automatically add it to every project or grant access to it. See Deploy a tool to Microsoft Discovery.

The shared definition isn't a running instance. Tools run when invoked, and multiple agents can reference the same definition. Keep invocation-specific values and data out of the shared definition and execution profile.

Model integration patterns

Microsoft Discovery provides multiple flexible patterns for integrating scientific machine learning models into its workflows. At a high level, there are four primary approaches, each designed to support different levels of complexity, control, and integration with external systems:

The following patterns distinguish hosting a model from calling a model endpoint. OpenAPI and MCP describe endpoint integrations, not additional container tool types. Registering an endpoint tool in Foundry alone doesn't create a Microsoft.Discovery/tools resource. For agent-side integration options, see Agent types in Microsoft Discovery.

Container-based client tool (Python)

In this pattern, the agent invokes a containerized tool that acts as a client for an already deployed model. The container doesn’t host the model itself—instead, it handles communication with the model service, applies any required logic, and returns the final output to the agent. This approach is best when you need precise control over preprocessing, postprocessing, or how multiple steps are orchestrated.

How it works

1. Your agent selects the tool
2. A container is launched with your inputs
3. Your Python script:
   • Validates and prepares inputs
   • Sends a request to the deployed model endpoint
   • Applies any custom preprocessing or postprocessing logic
   • Optionally orchestrates multiple calls or additional steps
4. Results are returned to the agent

How to set it up

• Deploy a model (e.g., in Foundry or another endpoint)
• Build a Docker image with your Python code and push it to your Azure Container Registry (ACR)
• Configure secure access (managed identity recommended)
• Register the container as a tool in Microsoft Discovery

Container-based model (Supercomputer)

Package your scientific model into a container and deploy it as a scalable service. This approach is ideal when you need full control over dependencies, runtime, and custom logic. Choose this when your model needs high-performance compute (HPC), such as large-scale training or heavy inference.

Key idea

• Your model runs inside a container on the Discovery Supercomputer
• Agents don't call it directly—you access it through a tool or service layer

How to set it up

• Package your model and dependencies into a container
• Push the image to your Azure Container Registry (ACR)
• Register it as a tool in Microsoft Discovery

OpenAPI-based

Expose your model through a standardized API interface and connect it to Discovery using an OpenAPI specification. This is useful when your model is already hosted as a service and you want a standard, schema-driven integration.

How it works

• Your model/service is exposed via an HTTP endpoint
• You define an OpenAPI (Swagger) spec
• Agents use the spec to discover and call operations

How to set it up

• Deploy your model behind an API endpoint
• Write an OpenAPI specification (requests, responses, auth)
• Register the API as a tool in Foundry

MCP-based

Choose this for advanced scenarios that require rich, multi-step, context-aware interactions.

How it works

• Your tool implements the Model Context Protocol (MCP)
• Agents send and receive structured context
• Supports stateful, multi-turn workflows

How to set it up

• Deploy your model behind an endpoint
• Use or build an MCP server
• Register the MCP tool in Foundry

How to choose the right pattern

Use this quick guidance:

• Use container-based tools → when you need custom logic around models
• Use Supercomputer (HPC) → when compute scale is the main constraint
• Use OpenAPI tools → when you already have REST APIs
• Use MCP tools → when workflows require memory and context across steps

Security best practices

No matter which pattern you choose, follow these:

• Use managed identities and RBAC (avoid hardcoding credentials)
• Use versioned, scanned container images, and lock deployed image versions to prevent overwrites and deletion.
• Use encryption (HTTPS + encrypted storage)
• Enable logging and monitoring for all tool and model calls

Related content

• Microsoft Discovery agents
• What is Azure AI Foundry?
• Workflows in Microsoft Foundry
• Get started with containers on Azure
• What is Azure RBAC?
• Microsoft OpenAPI documentation
• Microsoft Discovery REST API reference