VIDIZMO integration brief · Microsoft Foundry · vidizmo.ai/integrations/catalog/microsoft-foundry

Integrations / Microsoft Foundry

Microsoft Foundry

Run and manage models through Microsoft Foundry. Visit website

Microsoft Foundry is Azure's platform for deploying and managing models from several vendors in one place.

It gives access to a catalogue of models under one Azure tenancy rather than a separate contract per provider.

The Models You Already Pay Azure For

Open as a two-page brief

Microsoft Foundry is Azure's platform for deploying and managing models from several vendors in one place, which is how a lot of organizations end up with one model contract instead of five. Where that is the arrangement, AI Intelligence Hub uses those deployments rather than a separate provider relationship, and Foundry's own MCP server is reachable as a tool source. Model governance stays in Azure, under the tenancy and the commercial terms already agreed.

Nexus your video, audio, images and documents, indexed under your access rules content the asking user may see AI Intelligence Hub agents, chat, workflows, retrieval with citations; model chosen per agent prompts and embeddings over API Microsoft Foundry model endpoint, hosted by the provider or on your own servers answers Users chat, search, workflow output Microsoft Foundry VIDIZMO

How it connects

Two connections, and they do different jobs. A Foundry-deployed model is reached through its OpenAI-compatible endpoint, configured under the platform's OpenAI provider rather than a Foundry-specific one. The model behind an agent or a node is configuration rather than code, chosen per deployment or per agent, so which Foundry deployment answers a given workflow is a setting. A native Foundry provider, as distinct from the OpenAI-compatible path, is added per engagement.

The second connection is Foundry's MCP server, which Microsoft runs as a hosted endpoint with Entra ID authentication. The platform is an MCP client, and the connection is configured once with a name, the server URL, the transport and the headers carrying its credential. Streamable HTTP, Server-Sent Events and WebSocket are the transports carried. The server's tool list is fetched when the connection binds rather than coded in, so a tool added on the Azure side is usable without reconfiguration.

The connection carries the credential it is configured with, so what it can do in Foundry is bounded by what that credential is granted there. Nothing about model selection is locked: hosted providers and self-hosted servers are both supported, so a deployment can run Foundry models for one agent and something else for another.

What you can do together

  • Point an agent at a model already deployed in your Azure tenancy, so inference runs under the contract, region and commercial terms you have rather than a new one.
  • Change the model behind a workflow as a configuration setting, without rebuilding the workflow.
  • Reach Foundry's own tools through its MCP server, discovered at bind, when a step needs to act on the Azure side.
  • Keep some agents on Foundry and others on a self-hosted model, where cost, latency or data-residency reasons differ per use case.

A scenario

  1. Provider setupAn administrator configures the Foundry deployment as a provider through its OpenAI-compatible endpoint. No model leaves the insurer's Azure tenancy arrangement.
  2. Agent configurationThe claims assistant in AI Intelligence Hub is set to that deployment. A summarization node in a separate workflow is pointed at a smaller, cheaper deployment.
  3. ToolingFoundry's MCP server is added with a scoped credential, and its tool list appears in the workflow editor without development.
  4. In useAn adjuster asks a question and the answer is generated by the Azure-hosted model, with retrieval over the library running under the adjuster's own identity.
  5. A changeSix months later the insurer moves to a newer model in Foundry. The agent's provider setting is updated and nothing else changes.

What stays where

Model governance stays in Azure

Deployments, regions, quotas and the commercial relationship are managed in Foundry, and the platform consumes what is deployed there.

Content stays in the library

Retrieval runs over the platform's own content under the asking user's identity, and what is sent to the model is what that retrieval returned.

The credential is the boundary on the Foundry side

What the MCP connection can do is what its configured credential is granted, so scoping it is the control.

Processing runs where you deploy the platform

Shared or dedicated SaaS, your own cloud subscription, or your own servers. Reaching a hosted Foundry endpoint needs a network path to it, which an air-gapped deployment does not have; a self-hosted model is the option there.

Products and solutions

Next step

See it on your own Microsoft Foundry instance. We will show the connection made, the data moving and the output, then size it for your deployment.

Request a demonstration  or write to sales@vidizmo.ai

sales@vidizmo.ai  ·  vidizmo.ai/integrations/catalog/microsoft-foundry

Not what you need?

We build it

Send us your API documentation and we build, test and maintain the connector, at no development cost to you.

Request this integration

Bring an MCP server

If the system publishes a Model Context Protocol server, AI Intelligence Hub connects to it as a client with configuration alone.

Define a REST endpoint

Describe your endpoint and it becomes a node in an agent workflow, without waiting on our roadmap.

Product names, logos and trademarks shown here are the property of their respective owners. Their use does not imply any affiliation with or endorsement by them.