Today, we're excited to announce the public preview of the plugin marketplace endpoint for Azure API Center. This new capability makes it easier than ever for developers to discover and install AI plugins — including MCP servers and skills — directly from the tools they already use, like Claude Code and GitHub Copilot CLI.

The problem we're solving

As AI plugins and MCP servers become core parts of the developer workflow, teams have struggled with a fundamental challenge: there's no central, governed place to find and manage them. Developers hunt through documentation, Teams messages, and wikis — and platform teams have no reliable way to ensure the right plugins are being used. Azure API Center has built the plugin marketplace to fix this issue

What's new

When you register plugins in your API Center inventory and enable the API Center portal, we now automatically provision a marketplace.git endpoint at your data plane URL:

Your marketplace endpoint is https://<service>.data.<region>.azure-apicenter.ms/workspaces/default/plugins/marketplace.git

This endpoint serves as a live, version-controlled catalog of every plugin in your API Center — with metadata, configuration, and install instructions ready for developer tools to consume.

Get up and running in seconds

We've designed the experience to be as frictionless as possible. Developers can add your organization's marketplace and start installing plugins with just two commands:

In Claude Code

/plugin marketplace add <url>
/plugin install plugin-name@myapicenter

In GitHub Copilot CLI

/plugin marketplace add <url>
/plugin marketplace browse myapicenter

Enterprise-ready from day one

The plugin marketplace isn't just convenient — it's governed. Access to the marketplace endpoint inherits the same authentication model you configured for your API Center portal, so your security and compliance posture stays intact. Platform teams remain in full control of what gets published; developers get a seamless, trusted source of truth.

Documentation

To learn more click here

 

We are thrilled to announce that the Microsoft Foundry Toolkit for VS Code, formerly AI Toolkit, is now Generally Available (GA)!

From first model prompt to production‑grade AI agents, Foundry Toolkit lets you build, debug, and ship AI end to end without ever leaving VS Code.

Same Product. New Name.

You may know this extension as AI Toolkit — and we thank you for using it in the past year and for the continuous feedback that has shaped the product. With this GA release, we’re rebranding AI Toolkit to Microsoft Foundry Toolkit. The new name reflects where we’re headed: a single, unified developer experience for building AI apps and agents on the Microsoft AI platform. Rest assured, this is a name change only — there are no plans to remove or deprecate any existing features.

Empower AI Development from Idea to Production with Foundry Toolkit

The GA release brings together the most requested features into a high-performance workflow:

• 🧪 Curated Model Playground: Don’t waste time with setup. Browse and chat with over 100+ state-of-the-art models from Microsoft Foundry, GitHub, OpenAI, Anthropic, Ollama, and more. Compare performance side-by-side and export production-ready code in seconds.
• 🤖 Agent Builder (No-Code/low code): Experiment with agent ideas or build sophisticated agents without writing boilerplate code. Define instructions, link tools from the Foundry catalog, or connect local MCP (Model Context Protocol) servers to have a functional agent running in minutes.
• ✨GitHub Copilot powered agent development: With Foundry tools and skills built into the Toolkit, GitHub Copilot is equipped with deep context to jumpstart agent creation using the Microsoft Agent Framework - often from a single prompt.
• 🛠️ Deep-Cycle Debugging: Move beyond black-box AI. The Agent Inspector provides real-time workflow visualization, breakpoints, and full local tracing across tool calls and agent chains.
• ⚡ Edge-Optimized Performance: Specialized support for the Phi model family. Fine-tune Phi Silica on your data, quantize for NPU/GPU targets, and profile on-device performance to ensure your models run lean and fast.
• 🚀 Seamless Scale: Transition from local to cloud with one click. Deploy directly to the Microsoft Foundry Agent Service and run continuous evaluations using familiar pytest syntax within the VS Code Test Explorer.

Get Started Today

• Install: Microsoft Foundry Toolkit on VS Code Marketplace.
• Quick Start: Follow our 3-Minute Getting Started Tutorial to build your first AI agent.
• Deep Dive: Check out documentations, Samples, and workshop. 

Join the Community

Join us on Model Monday event on 4/20 where we will talk through Building Foundry Agents using VS Code and GitHub Copilot.

We can’t wait to see what you build. Share your projects, file issues, or suggest features on our GitHub repository. Welcome to the next chapter of AI development!

Today we're expanding model choice in Microsoft 365 Copilot with the addition of Anthropic's latest model—Claude Opus 4.7—now available in Copilot Cowork (Frontier) and Copilot Studio early release cycle environments, and rolling out to Copilot in Excel.

Opus 4.7 is designed to be faster and more precise, with improved ability to select the right tool for the task. It handles complex, multi-step work with rigor—following your instructions more closely, checking its own outputs before responding, and reading images at higher resolution—so Copilot can interpret visual content with more detail and pull in relevant context with Work IQ to take action more precisely.

We are committed to bringing you the latest cutting-edge AI innovation and model choice built for work and tailored to your business needs—with the security, compliance, and privacy that you expect from Microsoft.  

Get started today

Claude Opus 4.7 is now available in the model selector in Copilot Cowork, Copilot Studio, and rolling out to Copilot in Excel.

Our team will continue to refine the experience based on your feedback.

For more details, learn more about Claude Opus 4.7 here

In the last post, we looked at the workflow: assess, plan, execute. You get reports you can review and the agent makes changes you can inspect.

If you don’t know, GitHub Copilot Modernization is the new agentic tool that supports you to in modernizing older applications. Could it support you with that old 4.8 Framework app, even that forgotten VB.NET script?

You're probably not modernizing one small app. It is probably a handful of projects, each with its own stack of blockers. Different frameworks, different databases, different dependencies frozen in time because nobody wants to touch them.

GitHub Copilot modernization handles two big categories: upgrading .NET projects to newer versions and migrating .NET apps to Azure. But what does that look like?

Upgrading .NET Projects

Let’s say, you've got an ASP.NET app running on .NET Framework 4.8 or it's a web API stuck on .NET Core 3.1. Unfortunately, getting it to .NET 9 or 10 isn't just updating a target framework property.

Here's what the upgrade workflow handles in Visual Studio:

Assessment first. - The agent examines your project structure, dependencies, and code patterns. It generates an Assessment Report UI, which shows both the app information, to create the plan, and the Cloud Readiness, for Azure deployment.

Then planning. - Once you approve the assessment, it moves to planning. Here you get upgrade strategies, refactoring approaches, dependency upgrade paths, and risk mitigations documented in a plan.md file at .appmod/.migration, you can check and edit that Markdown before moving forward or ask in the Copilot Chat window to change it.

# .NET 10.0 Upgrade Plan ## Execution Steps Execute steps below sequentially one by one in the order they are listed. 1. Validate that a .NET 10.0 SDK required for this upgrade is installed on the machine and if not, help to get it installed. 2. Ensure that the SDK version specified in global.json files is compatible with the .NET 10.0 upgrade. 3. Upgrade src\eShopLite.StoreFx\eShopLite.StoreFx.csproj ## Settings This section contains settings and data used by execution steps. ### Excluded projects No projects are excluded from this upgrade. ### Aggregate NuGet packages modifications across all projects NuGet packages used across all selected projects or their dependencies that need version update in projects that reference them

 

Then execution. - After you approve the plan, and the agent breaks it into discrete tasks in a tasks.md file. Each task gets validation criteria. As it works, it updates the file with checkboxes and completion percentages so you can track progress. It makes code changes, verifies builds, runs tests. If it hits a problem, it tries to identify the cause and apply a fix.

Go to the GitHub Copilot Chat window and type: 

• The plan and progress tracker look good to me. Go ahead with the migration.

It usually creates Git commits for each portion so you can review what changed or roll back if you need to. In case you don’t have a need for the Git commits for the change, you can ask the agent at the start to not commit anything.

The agent primarily focuses on ASP.NET, ASP.NET Core, Blazor, Razor Pages, MVC, and Web API. It can also handle Azure Functions, WPF, Windows Forms, console apps, class libraries, and test projects.

What It Handles Well (and What It Doesn't)

The agent is good at code-level transformations: updating TargetFramework in .csproj files, upgrading NuGet packages, replacing deprecated APIs with their modern equivalents, fixing breaking changes like removed BinaryFormatter methods, running builds, and validating test suites. It can handle repetitive work across multiple projects in a solution without you needing to track every dependency manually.

It's also solid at applying predefined Azure migration patterns, swapping plaintext credentials for managed identity, replacing file I/O with Azure Blob Storage calls, moving authentication from on-prem Active Directory to Microsoft Entra ID. These are structured transformations with clear before-and-after code patterns.

But here's where you may need to pay closer attention:

Language and framework coverage: It works with C# projects mainly. If your codebase includes complex Entity Framework migrations that rely on hand-tuned database scripts, the agent won't rewrite those for you. It also won't handle third-party UI framework patterns that don't map cleanly to ASP.NET Core conventions that have breaking changes between .NET Framework and later .NET versions. Web Forms migration is underway.

Configuration and infrastructure: The agent doesn't migrate IIS-specific web.config settings that don't have direct equivalents in Kestrel or ASP.NET Core. It won't automatically set up a CI/CD pipeline or any modernization features; for that, you need to implement it with Copilot’s help. If you've got frontend frameworks bundled with ASP.NET (like an older Angular app served through MVC), you'll need to separate and upgrade that layer yourself.

Learning and memory: The agent uses your code as context during the session, and if you correct a fix or update the plan, it tries to apply that learning within the same session. But those corrections don't persist across future upgrades. You can encode internal standards using custom skills, but that requires deliberate setup.

Offline and deployment: There's no offline mode. The agent needs connectivity to run. And while it can help prepare your app for Azure deployment, it doesn't manage the actual infrastructure provisioning or ongoing operations, that's still on you.

Guarantees: The suggestions aren't guaranteed to follow best practices. The agent won't always pick the best migration path. It won't catch every edge case. You're reviewing the work; pay attention to the results before putting it into production.

What it does handle: the tedious parts. Reading dependency graphs. Finding all the places a deprecated API is used. Updating project files. Writing boilerplate for managed identity. Fixing compilation errors that follow a predictable pattern.

Where to Start

If you've been staring at a modernization backlog, pick one project. See what it comes up with! You don't have to commit to upgrading your entire portfolio. Try it on one project and see if it saves you time. Modernization at scale still happens application by application, repo by repo, and decision by decision. GitHub Copilot modernization just makes each one a little less painful. Experiment with it! 

Anthropic continues to push the frontier of AI for real-world, production work with its new model Claude Opus 4.7.  Opus 4.7 is Anthropic’s most advanced generally available model.  Teams building on Azure can access Claude Opus 4.7 through Microsoft Foundry  , today. This model is designed for the workflows enterprises run and delivers meaningful gains across agentic coding, long-running autonomous tasks, and professional work.  

For organizations already building with Claude Opus 4.6, Opus 4.7 represents a powerful upgrade bringing stronger instruction following, better vision and office outputs, and improved memory capabilities to enable enhanced performance across complex, multi-step workflows..  

 

What Microsoft Foundry brings to the table  

Microsoft Foundry is Microsoft's unified platform for building, deploying, and governing AI applications at scale. It gives enterprise teams a single control plane for model selection, data connections, observability and access controls all backed by Azure's global infrastructure and security layer.  

Bringing Claude Opus 4.7 into that environment means enterprises get frontier model capability without compromising governance properties their security and legal teams require.  

Developers call Claude Opus 4.7 through Foundry's standard model APIs, which means existing tool chains, SDKs, and prompt harnesses require minimal changes. For teams already running Opus 4.6 in Microsoft Foundry, this is a direct upgrade path.  

 

What Opus 4.7 adds for enterprise workloads  

These improvements land directly in production workflows. Enterprises running Opus 4.6 today should see measurable gains in long-running tasks, coding,  visual capabilities, instruction following, and reasoning. .  

The model reasons through underspecified requests, making sensible assumptions and stating them clearly rather than stalling on clarifying questions  a practical improvement for any workflow that touches real-world data.  Check out Anthropic blog for benchmark table 

 

Built-in enterprise governance  

Running Opus 4.7 through Microsoft Foundry means every inference request inherits Foundry's enterprise controls: Azure Active Directory for identity and access, private networking via VNet and private endpoints, logging and audit trails through Azure Monitor.   

Teams don't need to build a separate governance layer around the model. Foundry handles it, and security teams already know how to audit it.  

 

Key use cases by vertical  

 

 

Getting started  

Claude Opus 4.7 is available today in Microsoft Foundry's model catalog. Teams already using Anthropic models on Microsoft Foundry can upgrade through the catalog with no infrastructure changes. New teams can deploy through the standard Foundry provisioning flow.  

Claude Code is available via the Anthropic API routed through Microsoft Foundry; teams can point their existing Claude Code installations at their Foundry endpoint with a single configuration change.

GitHub Copilot CLI with Claude is also available to GitHub Copilot Enterprise subscribers today.   

Anthropic has provided a migration guide covering the key differences between Opus 4.6 and Opus 4.7 to help teams get the most out of the new model with minimal harness changes. 

 

Key capabilities in this preview

Foundry Local exposes standard REST and OpenAI‑compatible APIs, enabling IT and AI teams to deploy and operate local AI workloads using familiar, cloud‑aligned patterns across edge and on‑prem environments.

In this public preview, we deliver the following capabilities:  

• Azure Arc extension for Foundry Local
  Deploy and manage Foundry Local via an Azure Arc extension, enabling consistent install, configure, update, and governance workflows across Arc‑enabled Kubernetes clusters, in addition to Helm‑based installation.
• Built‑in generative models from the Foundry Local catalog
  Deploy pre‑built generative models directly from the Foundry Local model catalog using a simple control‑plane API request.
• Bring‑your‑own predictive models (ONNX) from OCI registries
  Deploy custom predictive models (such as ONNX models) securely pulled from customer‑managed OCI registries and run locally.
• REST and OpenAI‑compatible inference endpoints
  Consume both generative and predictive models through standard HTTP endpoints.
• Multi‑model orchestration for agent‑style applications
  Enable applications that coordinate multiple local models—for example, generative models guiding calls to predictive models—within a single Kubernetes cluster.

Running Foundry Local on Azure Local single-node gives you:

• A validated, supported hardware foundation for running AI inference at the edge, from compact 1U nodes on the factory floor to rugged form factors in remote sites, using hardware from the Azure Local catalog
• AKS on Azure Local as the deployment target, so Foundry Local runs as a containerized workload managed by Kubernetes - the same operational model you use for any other workload on the cluster
• GPU access through the NVIDIA device plugin on AKS, giving Foundry Local's ONNX Runtime direct access to the node's discrete GPU without requiring Windows or host-OS-level configuration

Two installation Options for single node deployment:

The preview includes the Foundry Local Azure Arc extension, providing a consistent installation, deployment, and lifecycle management experience through Azure Arc, while also supporting Helm‑based installation

Choose one of two installation paths:

Option 1 - Arc-enabled Kubernetes Extension

Recommended when: your organization manages multiple Azure Local instances and wants Microsoft to handle the deployment lifecycle — version updates, configuration drift detection, health monitoring — through the Azure portal without the team needing to manage Helm releases manually.

Arc-enabled Kubernetes extensions deploy and manage workloads on AKS clusters registered with Azure. The extension operator runs in the cluster and reconciles the desired state declared in Azure, which means you don't need direct kubectl or helm access to the node to push updates. This is the lower-operational-overhead path for OT teams who are not Kubernetes specialists.

 

 

Once installed, the extension appears in the Azure portal under your AKS cluster's Extensions blade. Model updates and configuration changes are pushed by modifying the extension configuration in Azure — no shell access to the node required. For disconnected or intermittently connected deployments, the extension operator caches its desired state and continues operating; it reconciles with Azure when connectivity resumes.

 

Option 2 - Helm Chart

Recommended when: your team manages AKS workloads with Helm or GitOps (Flux), and you need precise control over GPU resource allocation, node affinity, model pre-loading, or persistent volume configuration.

The Helm chart gives you full control over the deployment manifest. You decide exactly how much GPU memory is requested per pod, which node the inference pod is pinned to, and what StorageClass backs the model cache. This matters on a single-node Azure Local deployment where you're sharing one physical GPU between the inference workload and potentially other AKS workloads.

 

 

With Helm you can also integrate with Flux for GitOps-managed deployment — useful when you manage multiple Azure Local single-node instances across plant sites and want to push model or configuration updates from a central Git repository.      

 

Example of a model deployment YAML file

 

Note: Verify the chart repository URL, chart name, and exact values.yaml parameters from the official Foundry Local documentation before deploying to production.

 

Choosing Between the Two

 

Early Customer Validation and Key Scenarios

Early customer validation is shaping the preview -helping ensure Foundry Local meets real-world requirements for latency, data control, and operating in constrained or disconnected environments across industries such as energy, manufacturing, government, financial services, and retail.

Based on this early feedback, customers are prioritizing scenarios such as:

• Sovereign and regulated

o   On-site inference with data, models, and processing under customer control

o   Decision support in disconnected or restricted-network environments

o   In-jurisdiction processing for sensitive records and casework

o   Real-time detection and situational awareness within secure facilities

• Industrial and critical infrastructure

o   Edge operations assistants combining sensor telemetry with conversational AI

o   Low-latency quality inspection and process verification on factory floors

o   Predictive maintenance for remote or intermittently connected equipment

o   Local safety monitoring and operational oversight close to systems

This input is guiding improvements across deployment flows, model catalog experience, hardware coverage, telemetry visibility, and documentation -so teams can evaluate and adopt Foundry Local more quickly and confidently in the environments above.

Examples:

CNC Anomaly Explanation: A machine vision system on a CNC line classifies a surface defect and passes the classification JSON to the Foundry Local endpoint. Phi-4-mini generates a plain-language root-cause hypothesis for the operator, referencing the specific machining parameters.

Disconnected Safety Procedure Lookup: An offshore platform or remote mine site loses WAN connectivity. The Foundry Local pods continue serving requests from the AKS cluster on the Azure Local node - Kubernetes keeps the pods running, the model is already on the local PersistentVolume, and no external dependency is required. Workers query safety procedures (LOTO sequences, chemical handling) from an intranet application backed by the same inference endpoint. Qwen2.5-7B fits within 8–12 GB VRAM and supports a 32K token context window, making it viable for inline procedure retrieval without a separate vector database - useful when plant-floor infrastructure is minimal.

 

Foundry Local for Devices and Foundry Local on Azure Local: What's Different

Foundry Local for devices reached general availability for developer devices -Windows 10/11, macOS (Apple Silicon), and Android. That release targets a specific scenario: a developer or end user running AI inference on their own machine, with the model executing locally on their CPU, GPU, or NPU. The install is a single command (winget or brew), the service runs directly on the host OS, and there is no Azure subscription or infrastructure required. It is a developer tool and an application-embedded runtime.

General overview of Foundry Local is available here: What is Foundry Local? - Foundry Local | Microsoft Learn

The public preview for Azure Local single node is a different deployment target built for a different operational context. The runtime is the same - ONNX Runtime, the same model catalog, the same OpenAI-compatible API - but where it runs, how it is deployed, and how it is managed are entirely different.

 

The short version: the GA device release is for building and running AI-enabled applications on a single machine. The Azure Local single-node preview is for deploying Foundry Local as a shared, production inference service that runs continuously on validated industrial hardware, survives WAN outages, and is consumed by multiple workloads running on the same edge cluster.

If you are prototyping an application on your laptop using the GA release, the same application code - specifically the OpenAI-compatible API calls - runs unchanged against the Azure Local deployment. You change only the base_url from localhost to the Kubernetes Service

Built for Secure Industrial and Sovereign Operations

Foundry Local supports Microsoft’s sovereign cloud principles—allowing AI workloads to operate fully locally, with customer‑controlled data boundaries and governance.

Integration with Azure Arc provides unified management, configuration, and monitoring across hybrid and disconnected landscapes, enabling organizations to meet stringent compliance and operational requirements while adopting advanced AI capabilities.

 

Learn more about Foundry Local on Azure Local

• RECOMMENDED participate in Foundry Local on Azure Local preview form link
• Foundry Local on Azure Local Documentation link
• Reach out to the team for support requests, feedback or suggestions here: FoundryLocal_Support@microsoft.com
• Foundry Local on Azure Local: HELM deployment Demo - link
• Foundry Local is now Generally Available link