Microsoft Foundry Toolkit for VS Code: Building a Local AI Agent Within the Editor

Data science and developer teams are looking more closely at extensions for their favorite IDE. Visual Studio Code is the most popular IDE, so it is no wonder that the search for extensions (and the extension marketplace) starts with Microsoft.

One of the newest is the Microsoft Foundry Toolkit for Visual Studio Code. It is a VS Code extension that helps you build AI agents quickly, with access to model catalogs, agent tooling, and Foundry resources, and the first steps need no Azure subscription.

You may know this extension by its old name. Microsoft renamed the AI Toolkit to Foundry Toolkit on June 1st, and folded the separate Microsoft Foundry extension into it. One extension now covers what used to be two, and the existing features carried over unchanged. A reader who remembers the old Microsoft Foundry sidebar should know it retired into this single toolkit.

I crafted this article with an eye for the local development path. You will load a model that runs on your own machine, wrap it in an agent, give that agent a tool through the Model Context Protocol, and add the guardrails that the agent will work against. The local loop fits a nmber of concerns: Privacy maintenance, Budget awareness, and centrality of workflow that benefits developer teams in any organization, be it nonprofits, small business, startup crews, or solopreneurs.

Install and load a local model

Installation starts by searching the Visual Studio Code Marketplace for Foundry Toolkit and installing it. You can find the toolkit as a VSC extension in Visual Studio Code.

The next step is looking for your model, which you can do in the Model Catalog. The catalog appears on the lower menu — you can view it in trhe image below. The panels allow you to reviewe model specification, simialr to that of Hugging Face. You have the option to deploy that model to a Foundry account for development.

As another local path choice, you can connect Ollama so a model on your machine shows up under the Ollama provider.

## Start the local runtime, then stage a model the Toolkit can list
ollama serve
ollama pull llama3.2

## Start the local runtime, then stage a model the Toolkit can list
ollama serve
ollama pull llama3.2

ollama serve exposes the local runtime that the Toolkit discovers, and ollama pull downloads the weights so the model card appears under the Ollama provider in the catalog. From that card you pick "Try in Playground" and start testing prompts. The benefit for a resource-constrained team is a working model with no key, no quota, and no data leaving the machine.

One caveat to test on your own setup. Several model-download and acceleration paths in the Toolkit are Windows-first, including DirectML and NPU acceleration on Copilot+ PCs, with some macOS paths staged. Confirm which models download and run on your hardware, and note the operating system you tested.

Build a prompt agent in Foundry

There is an agent builder tool which turns a system prompt into a testable agent inside the editor. It is

To access the builder, you open the Create Agent feature from the Foundry Toolkit sidebar. An icon for the Foundry Toolkit will appear in the standard VSC left side menu for extensions such as Python and LMStudio. In the image below I highted the icon that shows for Foundry Toolkit. Once you click on it you will see drop down menus shown in the image below.

Once you reach the Create Agent menu, you then generate a starter prompt in natural language. Just as you would in a genAI chat, you refine the prompt against the model's responses and define structured outputs so results come back machine-readable. The discussion loop stays inside VS Code, so you iterate in an environment like you would with code, but with prompts managing the underlying code tasks.

## Agent instructions (Agent Builder system prompt)
You are an analytics assistant for a small nonprofit.
List the requested KPIs, then call the available file tool to read the
source CSV before answering. Return the results as structured JSON.

## Agent instructions (Agent Builder system prompt)
You are an analytics assistant for a small nonprofit.
List the requested KPIs, then call the available file tool to read the
source CSV before answering. Return the results as structured JSON.

The instructions do two jobs. They set the task through prompt chaining, which breaks the work into ordered steps, and they request structured outputs, which return JSON instead of prose. That structure is what makes the agent testable rather than a freeform chat, because you can assert against fields in the response.

Give the agent a tool: a local MCP server

An agent in the builder can be set up with a Model Context Protocol (MCP) server so that you can attach the tools that you want the agent to access. MCP is the open standard that GitHub Copilot, Cursor, and Claude Code all speak, and the Toolkit speaks it too.

In the My Resources menu, you begin your MCP set up by opening the Tool section in the menu, then select one of the Type choices in the Catalog menu. You can see it in the image, then Add server, then MCP server. You can pick a featured server, connect an existing one, or scaffold a new one.

You next go to the Custom tab, whicb sits next to the Catalog yab. You then select the MCP panel where you can then configure the MCP specifications. The specifications are added in the configuration panel;, shown in the image below.

For a command-line server, choose the MCP Stdio selector, and then select available tools

MCP servers often need a Node or Python environment, and the Toolkit validates that the dependencies are present. Node servers run through npx, and Python servers run through uv and uvx.

// .vscode/mcp.json  (workspace-scoped, safe to commit)
{
  "servers": {
    "local-files": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./data"]
    }
  }
}

// .vscode/mcp.json  (workspace-scoped, safe to commit)
{
  "servers": {
    "local-files": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./data"]
    }
  }
}

The stdio transport launches the server on demand, so it spins up for a tool call and shuts down after, with nothing to run in the background. The servers object is portable, so committing .vscode/mcp.json shares the exact tool setup with a teammate through source control. This is the same MCP standard behind the mcptools package in R, so an agent built here talks to tools the same way your R workflows do.

Local MCP servers can run arbitrary code on your machine. Add servers only from trusted sources, and read the launch command before you start one.

Set the guardrails: tool approval and the Agent Inspector

Autonomy without oversight is the real risk, and the Toolkit gives you two controls that draw a clear line between automation and an agent.

The first control is tool approval. You configure auto or manual approval for MCP tool calls in Agent Builder, which decides whether the agent fires a tool on its own or waits for your click. Manual approval is the sensible default while you prototype, because you see every action before it runs.

The second control is the Agent Inspector. It brings F5 debugging, step-through execution, variable inspection, and streaming-response visibility to agent development, alongside workflow visualization. Pair it with the "Evaluation as Tests" approach that treats agent evaluations like unit tests.

Manual approval marks the difference between automation and an agent. Automation follows fixed rules with no choice in the moment, and an agent chooses whether to call a tool based on the task. Being able to step through that choice in the Agent Inspector turns an opaque agent into something you can debug like ordinary code, which is the gap between a demo and something you put in front of a client.

Where R fits: consume the local endpoint

Once the model and agent run locally, your R workflow can call the same OpenAI-compatible endpoint you already use with LM Studio.

This is the payoff for an R-centric analytics practice. A single local model serves both the VS Code agent and your reporting scripts, so the reporting layer never has to leave the machine either.

## Point ellmer at a local OpenAI-compatible endpoint
library(ellmer)
chat <- chat_openai(
  base_url = "http://localhost:1234/v1",  ## verify the port for your local server
  model = "llama3.2",
  api_key = "not-needed-for-local"
)
chat$chat("Summarize the KPI results the agent produced.") |>
  cat()

## Point ellmer at a local OpenAI-compatible endpoint
library(ellmer)
chat <- chat_openai(
  base_url = "http://localhost:1234/v1",  ## verify the port for your local server
  model = "llama3.2",
  api_key = "not-needed-for-local"
)
chat$chat("Summarize the KPI results the agent produced.") |>
  cat()

chat_openai with a custom base_url is the bridge that lets ellmer treat any local OpenAI-compatible server as a provider, so the R side of your stack reaches the same model the agent uses. The native pipe carries the response straight into cat(), which keeps the example copy-paste ready.

Verify the base URL and port before you rely on this. The Toolkit's own local REST endpoint, an Ollama endpoint, and an LM Studio endpoint each listen on different ports. Confirm the exact address on your machine, and flag any connection line you could not test.

Where Python fits: the same endpoint, a different client

Python reaches the same local server through the OpenAI SDK, so a team running Python scripts instead of R Programming scripts follows an identical pattern.

The endpoint speaks the OpenAI chat completions format, which means the official client works without modification once you redirect the base URL. Nothing about the model, the agent, or the MCP tools changes.

## Point the OpenAI client at a local OpenAI-compatible endpoint
from openai import OpenAI
client = OpenAI(
    base_url="http://localhost:1234/v1",  ## verify the port for your local server
    api_key="not-needed-for-local",
)
response = client.chat.completions.create(
    model="llama3.2",
    messages=[
        {"role": "user", "content": "Summarize the KPI results the agent produced."}
    ],
)
print(response.choices[0].message.content)

## Point the OpenAI client at a local OpenAI-compatible endpoint
from openai import OpenAI
client = OpenAI(
    base_url="http://localhost:1234/v1",  ## verify the port for your local server
    api_key="not-needed-for-local",
)
response = client.chat.completions.create(
    model="llama3.2",
    messages=[
        {"role": "user", "content": "Summarize the KPI results the agent produced."}
    ],
)
print(response.choices[0].message.content)

OpenAI accepts a custom base_url, which redirects every request to your local server while keeping the standard method signatures. chat.completions.create carries the model name and the message list, and the response arrives in the same shape you would get from a hosted provider. The api_key argument still has to be present because the client validates it, and any placeholder string satisfies a local server that does not check credentials.

The practical benefit is portability. A script written against a local model moves to a hosted provider by changing two lines, the base URL and the real key, so you prototype at no cost and scale without a rewrite.

Test the same caveat here. Confirm the port your local server actually uses, and install the client with pip install openai before running the script.

What Using Foundry Tool Kit Brings To Your Work

The local path lets a small team answer one question cheaply. Is this agent worth building? You get that answer with a model on your laptop, a local MCP tool, and manual approval on every action, all before a single dollar goes to hosted infrastructure. If the answer is yes, the same extension deploys the agent to the Foundry Agent Service when you are ready to scale.

Using Foundry Tool Kit allows you to establish a reusable workflow pattern worth keeping. Load a local model, attach a local tool, approve actions by hand, and move to managed hosting only after the value is proven. That sequence turns agent experiments into decisions you can defend to a client or a board.

I have some related reading that can helop you build a local model environment: My post on LM Studio for local models can help, as can the post featuring an Ollama walkthrough via ollamar, and a R MCP tooling piece featuring MCPTool.

How to Use ollamar, a R Programming Package for Running Local AI Models with Ollama Developers and analysts have been looking at running small language model on their computer — -otherwise called Local…

How To Use LM Studio To Plan Your AI Models Ready to build a Large Language Model on your laptop? Here's a quick overview of how LM Studio can aid your local AI…

MTP in LM Studio: How to Measure Inference With Local AI Models MTP in LM Studio: How to Measure Inference With Local AI Models Better performance for a local AI model is possible…