|
| 1 | +--- |
| 2 | +title: Microsoft Discovery tools and model integration |
| 3 | +description: Learn about tools in Microsoft Discovery, including tool types, how tools are deployed, and how to integrate models into agent workflows using common integration patterns. |
| 4 | +author: anzaman |
| 5 | +ms.author: alzam |
| 6 | +ms.service: azure |
| 7 | +ms.topic: conceptual |
| 8 | +ms.date: 04/17/2026 |
| 9 | +--- |
| 10 | + |
| 11 | +# Microsoft Discovery tools and model integration |
| 12 | + |
| 13 | +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. |
| 14 | + |
| 15 | +## What are tools? |
| 16 | + |
| 17 | +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: |
| 18 | + |
| 19 | +- **Computational tools** provide the necessary algorithms to solve complex mathematical problems, simulate physical phenomena or engineering systems, and analyze large scientific datasets. |
| 20 | + |
| 21 | +- **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. |
| 22 | + |
| 23 | +- **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. |
| 24 | + |
| 25 | +- **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. |
| 26 | + |
| 27 | +## Tool types |
| 28 | + |
| 29 | +Microsoft Discovery supports two types of tools: **action** and **code-environment based** tools. |
| 30 | + |
| 31 | +### Action-based tools |
| 32 | + |
| 33 | +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. |
| 34 | + |
| 35 | +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. |
| 36 | + |
| 37 | +### Code-environment based tools |
| 38 | + |
| 39 | +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. |
| 40 | + |
| 41 | +### Hybrid tools |
| 42 | + |
| 43 | +Code-environment and action-based tools can be combined to create a hybrid tool. Hybrid tools combine action-based tools in container images with code-environment tools dynamically generated by the platform's AI capabilities. Hybrid tools create a dynamic execution environment allowing AI models to generate code that is executed in the structured environment of action-based tools. |
| 44 | + |
| 45 | +## Requirements for authoring tools |
| 46 | + |
| 47 | +Action-based tools must be packaged in a Docker container and stored in a registry accessible to the Microsoft Discovery Supercomputer. A tool definition must be written that has the required specifications. Code-environment based tools also require a tool definition; however, the associated action is directly running the generated code and little else. |
| 48 | + |
| 49 | +## Cardinality and execution profile |
| 50 | + |
| 51 | +Tool definitions can be shared across an entire subscription because the tool definition isn't a unique instantiation. Tools are only instantiated when invoked. Multiple agents can all reference the same tool without conflict as each is instantiated in isolation. As such, care must be taken to ensure that tools don't have any values or data hardcoded either in the profile or the execution profile. |
| 52 | + |
| 53 | +--- |
| 54 | + |
| 55 | +## Model integration patterns |
| 56 | + |
| 57 | +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: |
| 58 | + |
| 59 | +| Pattern | How it works | Where models run | Best for | |
| 60 | +|---|---|---|---| |
| 61 | +| Container-based client tool (Python) | Run custom code inside a container | Foundry or external endpoint | Custom logic and orchestration | |
| 62 | +| Container-based model (Supercomputer) | Run containers in HPC environment | Discovery Supercomputer | Large-scale training/inference | |
| 63 | +| OpenAPI-based | Use REST APIs with schema | Foundry or external service | Existing APIs and services | |
| 64 | +| MCP-based | Exchange structured context | Foundry or external endpoint | Stateful, multi-step workflows | |
| 65 | + |
| 66 | +### Container-based client tool (Python) |
| 67 | + |
| 68 | +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. |
| 69 | + |
| 70 | +#### How it works |
| 71 | + |
| 72 | +1. Your agent selects the tool |
| 73 | +2. A container is launched with your inputs |
| 74 | +3. Your Python script: |
| 75 | + - Validates and prepares inputs |
| 76 | + - Sends a request to the deployed model endpoint |
| 77 | + - Applies any custom preprocessing or postprocessing logic |
| 78 | + - Optionally orchestrates multiple calls or additional steps |
| 79 | +4. Results are returned to the agent |
| 80 | + |
| 81 | +#### How to set it up |
| 82 | + |
| 83 | +- Deploy a model (e.g., in Foundry or another endpoint) |
| 84 | +- Build a Docker image with your Python code and push it to your Azure Container Registry (ACR) |
| 85 | +- Configure secure access (managed identity recommended) |
| 86 | +- Register the container as a tool in Microsoft Discovery |
| 87 | + |
| 88 | +### Container-based model (Supercomputer) |
| 89 | + |
| 90 | +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. |
| 91 | + |
| 92 | +#### Key idea |
| 93 | + |
| 94 | +- Your model runs inside a container on the Discovery Supercomputer |
| 95 | +- Agents don't call it directly—you access it through a tool or service layer |
| 96 | + |
| 97 | +#### How to set it up |
| 98 | + |
| 99 | +- Package your model and dependencies into a container |
| 100 | +- Push the image to your Azure Container Registry (ACR) |
| 101 | +- Register is as a tool in Microsoft Discovery |
| 102 | + |
| 103 | +### OpenAPI-based |
| 104 | + |
| 105 | +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. |
| 106 | + |
| 107 | +#### How it works |
| 108 | + |
| 109 | +- Your model/service is exposed via an HTTP endpoint |
| 110 | +- You define an OpenAPI (Swagger) spec |
| 111 | +- Agents use the spec to discover and call operations |
| 112 | + |
| 113 | +#### How to set it up |
| 114 | + |
| 115 | +- Deploy your model behind an API endpoint |
| 116 | +- Write an OpenAPI specification (requests, responses, auth) |
| 117 | +- Register the API as a tool in Foundry |
| 118 | + |
| 119 | +### MCP-based |
| 120 | + |
| 121 | +Choose this for advanced scenarios that require rich, multi-step, context-aware interactions. |
| 122 | + |
| 123 | +#### How it works |
| 124 | + |
| 125 | +- Your tool implements the Model Context Protocol (MCP) |
| 126 | +- Agents send and receive structured context |
| 127 | +- Supports stateful, multi-turn workflows |
| 128 | + |
| 129 | +#### How to set it up |
| 130 | + |
| 131 | +- Deploy your model behind an endpoint |
| 132 | +- Use or build an MCP server |
| 133 | +- Register the MCP tool in Foundry |
| 134 | + |
| 135 | +## How to choose the right pattern |
| 136 | + |
| 137 | +Use this quick guidance: |
| 138 | + |
| 139 | +- Use **container-based tools** → when you need custom logic around models |
| 140 | +- Use **Supercomputer (HPC)** → when compute scale is the main constraint |
| 141 | +- Use **OpenAPI tools** → when you already have REST APIs |
| 142 | +- Use **MCP tools** → when workflows require memory and context across steps |
| 143 | + |
| 144 | +> [!NOTE] |
| 145 | +> You can combine multiple patterns in a single workflow. |
| 146 | +
|
| 147 | +--- |
| 148 | + |
| 149 | +## Security best practices |
| 150 | + |
| 151 | +No matter which pattern you choose, follow these: |
| 152 | + |
| 153 | +- Use **managed identities and RBAC** (avoid hardcoding credentials) |
| 154 | +- Use **immutable container images** (version and scan them) |
| 155 | +- Use **encryption** (HTTPS + encrypted storage) |
| 156 | +- Enable **logging and monitoring** for all tool and model calls |
| 157 | + |
| 158 | +--- |
| 159 | + |
| 160 | +## Related content |
| 161 | + |
| 162 | +- [Microsoft Discovery agents](concept-discovery-agent.md) |
| 163 | +- [What is Azure AI Foundry?](/azure/foundry/what-is-foundry) |
| 164 | +- [Workflows in Microsoft Foundry](/azure/foundry/agents/concepts/workflow) |
| 165 | +- [Get started with containers on Azure](/azure/architecture/containers/container-get-started) |
| 166 | +- [What is Azure RBAC?](/azure/role-based-access-control/overview) |
| 167 | +- [Microsoft OpenAPI documentation](/openapi/) |
| 168 | +- [Microsoft Discovery REST API reference](/rest/api/discovery/) |
0 commit comments