# Pamela Fox Published articles for Pamela Fox. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Browser automation with Pydantic AI + Playwright DevFeed: [Browser automation with Pydantic AI + Playwright]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2026-08-20T21:57:18Z Content type: tutorial Language: en Sources: [Pamela Fox]() Topics: [Playwright](), [Pydantic](), [Browser Automation](), [Artificial Intelligence](), [Azure OpenAI](), [Entra ID](), [Authentication](), [OAuth 2.0](), [OpenTelemetry]() Tags: [agents](), [ai](), [api-keys](), [authentication](), [automation](), [azure-openai](), [browser](), [microsoft](), [microsoft-foundry](), [openai](), [playwright](), [python]() ### AI overview This tutorial explains how to combine Pydantic AI with Playwright to build agents that browse websites programmatically. It covers connecting Pydantic AI to Microsoft Foundry models through an OpenAI-compatible endpoint, using Entra token-based authentication, and applying Playwright for browsing, manual QA, and design iteration. ### Source excerpt When we build agents, we often want to give them the ability to browse the web: open webpages, navigate from one page to the other, and read the content of a webpage. By combining Pydantic AI with the Playwright capability from Pydantic AI Harness, we can build agents that browse the web safely and programmatically. Using Pydantic AI with Microsoft Foundry models Pydantic AI is an open-source model-agnostic framework from Pydantic for building LLM-based applications and agents. It's type-safe and supports OpenTelemetry, making it a great choice for robust production applications. We can use Pydantic-AI with Microsoft Foundry models using either API keys or Entra token-based authentication. When possible, we always recommend the keyless route, so that's what we'll demonstrate here. We use the azure-identity package to authenticate with Entra, using either local or managed identity, and get back a token provider callback function for that credential: from azure.identity.aio import AzureDeveloperCliCredential, get_bearer_token_provider credential = AzureDeveloperCliCredential() token_provider = get_bearer_token_provider(credential, "https://cognitiveservices.azure.com/.default") Then we use the OpenAI package to configure the model connection: from openai import AsyncOpenAI client = AsyncOpenAI( base_url=os.environ["AZURE_OPENAI_ENDPOINT"] + "/openai/v1", api_key=token_provider, ) model = OpenAIChatModel( model_name=os.environ["AZURE_OPENAI_CHAT_DEPLOYMENT"], provider=OpenAIProvider(openai_client=client), ) Let's explain the options used above: base_url: We point this at the OpenAI-compatible endpoint for our Foundry model. This endpoint works for Azure OpenAI models (like gpt-5.4, which this project deploys), and for cross-provider Foundry models that support the OpenAI v1 API, like Kimi-K2.7-Code. The base URL looks like "https://AZURE_OPENAI_SERVICE_NAME.openai.azure.com/openai/v1". api_key: We pass in the token provider callback function that generates OAuth2 token ## Building safe MCP servers for your PostgreSQL database DevFeed: [Building safe MCP servers for your PostgreSQL database]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2026-08-12T18:07:30Z Content type: article Language: en Sources: [Pamela Fox]() Topics: [Model Context Protocol](), [MCP Server](), [PostgreSQL](), [SQL](), [Python](), [GitHub Copilot](), [Open Source](), [LangChain]() Tags: [github-copilot](), [langchain](), [mcp](), [mcp-server](), [open-source](), [postgresql](), [python](), [sql]() ### AI overview This tutorial explains how to build MCP servers for PostgreSQL databases and how to control the level of agent access. It compares flexible servers that accept generated SQL with stricter servers using typed tools and templated queries, using Python and FastMCP examples. ### Source excerpt Model Context Protocol (MCP) is an open protocol that describes how agents can connect to external tools and data sources, and is now widely supported by the most popular coding agents (like GitHub Copilot, Claude Code, and Codex) and agent frameworks (like LangChain and Pydantic AI). If you want to give agents a standard way to access the data in a database, you can build your own MCP server and expose tools for the agent to query or even modify data. But you need to design your MCP server carefully, to ensure that agents can do everything that users want - but nothing that you don't want them to do! In this blog post, we'll walk through the range of ways to build MCP servers on top of a PostgreSQL database, since PostgreSQL is the most popular open source database and is production-ready with hosted offerings like Azure Database for PostgreSQL. You can apply these same principles to any database, however. There's a spectrum of ways to build MCP servers on top of a database. We'll start with the most flexible option, exploratory servers that allow the agent to generate full SQL queries, conclude with the strictest option, fully typed tools for templated queries, and explore options in the middle too. Free-form SQL Let's take a look at a simple MCP server that gives the agent as much information and control as possible. For all of our examples, we use the Python language and the FastMCP package, but SDKs are available in multiple languages. All code is available in the GitHub repository. We start off by giving the server a name, which the agent will see and consider when deciding which MCP server to invoke for a given user query: mcp = FastMCP("Bees database MCP server") For this example, my database stores observations of bees, so I name it accordingly. We then define an execute_sql tool that accepts any SQL string, executes it against the database, and returns the rows. @mcp.tool() async def execute_sql(sql: str) -> str: """Execute a SQL query against the database ## My experience at PyCon US 2026 DevFeed: [My experience at PyCon US 2026]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2026-05-20T05:41:47Z Content type: opinion Language: en Sources: [Pamela Fox]() Topics: [Python](), [MCP](), [MCP Server](), [Tutorial]() Tags: [2026](), [conference](), [experience](), [mcp](), [mcp-server](), [python](), [tutorial]() ### AI overview A personal recap of PyCon US 2026 describing the author's tutorial on building MCP servers, including its preparation, delivery to 84 attendees, and use of coding agents, agent frameworks, FastMCP, and Keycloak. ### Source excerpt I'm writing this post on the flight back from PyCon US 2026 in Long Beach, California. It was my second time attending PyCon, and it was a fantastic conference - a cornocopia of Python knowledge, but more importantly, a coming-together of developers across the Python ecosystem. I'll recap my PyCon US 2026 experience in this post, both what I contributed and what thousands of others contributed. First, a big old disclaimer: part of my job as a developer advocate at Microsoft is to attend conferences like PyCon, so I was able to expense my travel and spend my work days on my PyCon contributions. But that's also why I picked my job, as it gives me the excuse to do things that I'd want to do anyway, like attending the largest gathering of Python devs in the world. My tutorial Since I've been spending so much time on Model Context Protocol (MCP) in the past year, I submitted an idea to the PyCon CFP to run a tutorial walking developers through the process of building their first MCP server. I was thrilled that the tutorial was accepted, but nervous since I'd never delivered a tutorial at a PyCon before. Fortunately, I was able to test it out with the SF Python meetup group a few days before, and their feedback helped me streamline the tutorial experience immensely. I delivered the tutorial at PyCon to a packed room: 84 people, all seats filled, bright and early at 9AM on Wednesday morning, the first slot of the week-long conference. We started off the tutorial with an icebreaker, which included attendees inventing their own meaning for "MCP". Of course, my not-so-secret goal was for them to get to know their neighbor, to encourage pair debugging during the exercises. I alternated between slides and exercises in the 3.5 hours tutorial, trying to give attendees enough background knowledge while also giving them the time to get hands-on. We started off with attendees using MCP servers, via both coding agents (Copilot/Claude Code) and agent frameworks (Pydantic AI, Langchain ## Building MCP servers with Entra ID and pre-authorized clients DevFeed: [Building MCP servers with Entra ID and pre-authorized clients]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2026-04-02T23:44:00Z Content type: tutorial Language: en Sources: [Pamela Fox]() Topics: [Model Context Protocol](), [Entra ID](), [OAuth](), [Python](), [vs-code](), [Security]() Tags: [entra-id](), [mcp](), [model-context-protocol](), [oauth](), [python](), [security](), [vs-code]() ### AI overview This tutorial explains how to build a Python MCP server with FastMCP that authenticates users with Microsoft Entra ID when they connect through a pre-authorized client such as VS Code. It outlines the MCP authorization flow, OAuth 2.1 roles, and why arbitrary-client support may require an OAuth proxy. ### Source excerpt The Model Context Protocol (MCP) gives AI agents a standard way to call external tools, but things get more complicated when those tools need to know who the user is. In this post, I'll show how to build an MCP server with the Python FastMCP package that authenticates users with Microsoft Entra ID when they connect from a pre-authorized client such as VS Code. If you need to build a server that works with any MCP clients, read my previous blog post. With Microsoft Entra as the authorization server, supporting arbitrary clients currently requires adding an OAuth proxy in front, which increases security risk. This post focuses on the simpler pre-authorized-client path instead. MCP auth Let's start by digging into the MCP auth spec, since that explains both the shape of the flow and the constraints we run into with Entra. The MCP specification includes an authorization protocol based on OAuth 2.1, so an MCP client can send a request that includes a Bearer token from an authorization server, and the MCP server can validate that token. In OAuth 2.1 terms, the MCP client is acting as the OAuth client, the MCP server is the resource server, the signed-in user is the resource owner, and the authorization server issues an access token. In this case, Entra will be our authorization server. We can't necessarily use any OAuth-compatible authorization servers, as MCP auth requires more than just the core OAuth 2.1 functionality. In OAuth, the authorization server needs a relationship with the client. MCP auth describes three options: Pre-registration: the auth server has a pre-existing relationship and has the client ID in its database already CIMD (Client Identity Metadata Document): the MCP client sends the URL of its CIMD, a JSON document that describes its attributes, and the auth server bases its interactions on that information. DCR (Dynamic Client Registration): when the auth server sees a new client, it explicitly registers it and stores the client information in its own ## Do stricter MCP tool schemas increase agent reliability? DevFeed: [Do stricter MCP tool schemas increase agent reliability?]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2026-03-17T06:13:00Z Content type: article Language: en Sources: [Pamela Fox]() Topics: [Model Context Protocol](), [MCP Server](), [Python](), [Large Language Model](), [Prompt Engineering]() Tags: [agent](), [ai](), [llms](), [mcp](), [mcp-server](), [python](), [schema]() ### AI overview The article investigates whether stricter MCP tool schemas make agents more reliable. It describes an expense-tracking MCP server built with Python FastMCP and examines how metadata, parameter descriptions, and type constraints affect tool-calling behavior. ### Source excerpt MCP servers contain tools, and each tool is described by its name, description, input parameters, and return type. When an agent is calling a tool, it formulates its call based on only that metadata; it does not know anything about the internals of a tool. For my PyAI talk last week, I investigated this hypothesis: If we use stricter types for MCP tool schemas, then agents calling those tools will be more successful. This was a hypothesis based on my personal experience over the last year of developing with agents and MCP servers, where I'd started with MCP servers with very minimal schemas, witnessed agents failing to call them correctly, and then iterated on the schemas to improve tool-calling success. I thought for sure that my hypothesis would be validated with flying colors. Let's see what I discovered instead... Table of contents: A basic MCP tool and schema Annotating parameters with descriptions Constraining parameters with types Setting up evaluations Evaluation results: category Evaluation results: date Cross-model evaluations Impact of reasoning effort Comparing agent frameworks Takeaways A basic MCP tool and schema For this experiment, I built an MCP server that can add expenses to a database. My add_expense tool needs four pieces of information: date: The date that the expense was incurred amount: The amount of the expense category: The category of the expense description: A free-form description of the expense This is what a first attempt at the tool might look like, using the Python FastMCP framework, and a Python type annotation for each parameter: @mcp.tool async def add_expense( expense_date: str, amount: float, category: str, description: str, ): """Add a new expense.""" ... See full code in expenses_mcp.py. When FastMCP generates the schema based on that function signature, it produces this JSON schema: { "name": "add_expense", "description": "Add a new expense.", "inputSchema": { "properties": { "expense_date": {"type": "string"}, "amount": {"ty ## Building an MCP Clothing Search Server with Azure AI Search and an Image Slideshow DevFeed: [Building an MCP Clothing Search Server with Azure AI Search and an Image Slideshow]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2026-03-13T05:49:00Z Content type: tutorial Language: en Sources: [Pamela Fox]() Topics: [Model Context Protocol](), [MCP Server](), [AI search](), [Azure](), [Embeddings](), [vs-code]() Tags: [ai-search](), [azure](), [copilot](), [embeddings](), [image](), [images](), [javascript](), [mcp](), [mcp-server](), [model-context-protocol](), [python](), [vs]() ### AI overview This tutorial explains how to build a closet MCP server that searches clothing from a user query and presents matching items as images. It uses FastMCP, Azure AI Search hybrid retrieval, multimodal embeddings, LLM-generated image descriptions, and an MCP app with a JavaScript-powered slideshow. ### Source excerpt When I was a kid, one of my first Java applets was a UI for choosing outfits by mixing and matching different articles of clothing. Now, with the advent of agents and MCP, I realized that I could make a modern, more dynamic version: an MCP server that can find relevant clothing based off a user query, and render matching clothing as a slideshow. Let's walk through the experience and code powering it. Searching for relevant clothing After connecting VS Code to my closet MCP server, I ask a query like: i am presenting at PyAI about MCP, do I have MCP themed clothing? show me the best option. GitHub Copilot decides that it can use the closet MCP server to answer that question, and it calls the image_search tool with these arguments: { "query": "MCP Model Context Protocol themed clothing", "max_results": 5 } The tool call returns a mix of binary files - thumbnails for each matching article of clothing, and structured data- a JSON containing filename, display name, and description for each article. { "results": [ { "filename": "IMG_3234.jpg", "display_name": "IMG_3234.jpg", "description": "The image shows a black sleeveless dress hanging on a white hanger against a plain wall. The dress has a printed text on the front that reads: \"YOU DOWN WITH MCP? Yeah, you know me!\" The first line is in large white uppercase letters, and the second line is in smaller pink cursive letters. The dress has a fitted top and a flared skirt." },... Here's what that looks like in the GitHub Copilot chat interface. Notice that Copilot attaches the images, so I can actually click on them to see each result directly in VS Code, as if they were a file in the workspace. Now let's look at the code powering that tool call. I built the server using FastMCP, so I declare my tools by wrapping functions in mcp.tool() decorator and annotating the arguments with types and helpful descriptions. Inside the function, I use Azure AI Search with hybrid retrieval on both the text query and the query's vector, ## Key takeaways from the PyAI conference on AI evaluation, software design, and open-source maintenance DevFeed: [Key takeaways from the PyAI conference on AI evaluation, software design, and open-source maintenance]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2026-03-12T06:40:00Z Content type: article Language: en Sources: [Pamela Fox]() Topics: [Artificial Intelligence](), [Python](), [AI-assisted coding](), [MCP](), [SDKs](), [Pydantic](), [FastAPI]() Tags: [agents](), [ai](), [ai-evals](), [code](), [coding](), [coding-agents](), [conference](), [data-science](), [fastapi](), [github](), [maintainers](), [mcp](), [open-source](), [python](), [sdk]() ### AI overview The article summarizes lessons from PyAI conference sessions on evaluating AI systems, designing Python software for maintainability by coding agents, and handling AI-generated pull requests in open-source projects. It recommends validating LLM judges with labeled data and conventional evaluation metrics, using clearer software abstractions, and developing systems to triage low-quality contributions. ### Source excerpt I recently spoke at the PyAI conference, put on by the good folks at Prefect and Pydantic, and I learnt so much from the talks I attended. Here are my top takeaways from the sessions that I watched: AI Evals Pitfalls Hamel Husain 📺 Watch the video recording | 📊 View slides Hamel cautioned against blindly using automated evaluation frameworks and built-in evaluators (like helpfulness and coherence). Instead, we should adopt a data science approach to evaluation: explore the data, discover what's actually breaking, identify the most important metric, and iterate as new data comes in. We shouldn't just trust an LLM-as-a-judge to be given accurate scores. Instead, we should validate it like we would validate a ML classifier- with labeled data, train/dev/test splits, and precision/recall metrics. LLM-judges should always give pass/fail results, instead of 1-5 scores, so that there's no ambiguity in their judgment. When generating synthetic data, first come up with dimensions (such as persona), generate combinations based off dimensions, and convert those into realistic queries. Hamel created evals-skills, a collection of skills for coding agents that can be run against evaluation pipelines to find issues like poorly designed LLM-judges. Build Reasonable Software Jeremiah Lowin (FastMCP/Prefect) 📺 Watch the video recording Write your Python programs in a way that coding agents can reason about them, so that they can more easily maintain and build them. For example, FastMCP v2 SDK was not well designed (bad abstractions) so a new CodeMod feature required 4,000 lines of code. In the new FastMCP v3 SDK (same functional API, different abstractions backing it), the same feature only required 500 lines of code. To make Python FastMCP servers more Pythonic, Jeremiah is developing a new package for MCP apps which includes the most common UIs (forms/tables/charts), called PreFab: https://github.com/PrefectHQ/prefab Panel: Open Source in the Age of AI Guido van Rossum (CPython), Sa ## Using on-behalf-of flow for Entra-based MCP servers DevFeed: [Using on-behalf-of flow for Entra-based MCP servers]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2026-01-16T20:34:00Z Content type: tutorial Language: en Sources: [Pamela Fox]() Topics: [Model Context Protocol (MCP)](), [Entra ID](), [OAuth 2.0](), [Authentication](), [Python](), [API](), [Authorization](), [client]() Tags: [api](), [authentication](), [authorization](), [delegation](), [identity](), [mcp](), [mcp-server](), [microsoft](), [oauth2](), [python]() ### AI overview This tutorial explains how to use Microsoft Entra authentication and the OAuth on-behalf-of flow in a Python FastMCP server. It describes how an MCP server can use a user's identity to call another API, such as Microsoft Graph, and how FastMCP implements dynamic client registration through an OAuth proxy for arbitrary MCP clients. ### Source excerpt In December, we presented a series about MCP, culminating in a session about adding authentication to MCP servers. I demoed a Python MCP server that uses Microsoft Entra for authentication, requiring users to first login to the Microsoft tenant before they could use a tool. Many developers asked how they could take the Entra integration further, like to check the user's group membership or query their OneDrive. That requires using an "on-behalf-of" flow, also known as "delegation" in OAuth, where the MCP server uses the user's identity to call another API, like the Microsoft Graph API. In this blog post, I will explain how to use Entra with OBO flow in a Python FastMCP server. How MCP servers can use Entra authentication The MCP authorization specification is based on OAuth2, but with some additional features tacked on top. Every MCP client is actually an OAuth2 client, and each MCP server is an OAuth2 resource server. MCP auth adds these features to help clients determine how to authorize a server: Protected resource metadata (PRM): Implemented on the MCP server, provides details about the authorization server and method Authorization server metadata: Implemented on the authorization server, gives URLs for OAuth2 endpoints Additionally, to allow MCP servers to work with arbitrary MCP clients, MCP auth supports either of these client registration methods: Dynamic Client Registration (DCR): Implemented on the authorization server, it can register new MCP clients as OAuth2 clients, even if it hasn't seen them before. Client ID Metadata Documents (CIMD): An alternative to DCR, this requires both the MCP client to make a CIMD document available on a server, and requires the authorization server to fetch the CIMD document for details about the client. Microsoft Entra does support authorization server metadata, but it does not support either DCR or CIMD. That's actually fine if you are building an MCP server that's only going to be used with pre-authorized clients, like i ## Watch the recordings from my Python + MCP series DevFeed: [Watch the recordings from my Python + MCP series]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-12-19T15:50:00Z Content type: tutorial Language: en Sources: [Pamela Fox]() Topics: [Model Context Protocol](), [MCP Server](), [Python](), [Azure](), [OAuth](), [Docker](), [OpenTelemetry](), [LangChain](), [GitHub Copilot](), [vs-code](), [Microsoft Agent Framework]() Tags: [agent-framework](), [azure](), [code](), [deployment](), [docker](), [github-copilot](), [langchain](), [mcp](), [mcp-server](), [microsoft-agent-framework](), [model-context-protocol](), [oauth](), [opentelemetry](), [python](), [vs-code]() ### AI overview A three-part Python and MCP series provides recordings, slides, and open-source code covering MCP server development with FastMCP, cloud deployment on Azure, observability, networking, and authentication. ### Source excerpt MCP is one of the fastest growing technologies in the Generative AI space this year, and the first AI related standard that the industry has really embraced wholeheartedly. I just gave a three-part live stream series all about Python + MCP. I showed how to: Build MCP servers in Python using FastMCP Deploy them into production on Azure (Container Apps and Functions) Add authentication, using either Keycloak and Microsoft Entra as the OAuth provider All of the materials from our series are available and linked below: Video recordings of each stream Powerpoint slides Open-source code samples complete with Azure infrastructure and 1-command deployment If you're an instructor, feel free to use the slides and code examples in your own classes. Spanish speaker? My colleague delivered a fantastic Spanish version of the series. Building MCP servers with FastMCP 📺 Watch YouTube recording In the intro session of our Python + MCP series, we dive into MCP (Model Context Protocol). This open protocol makes it easy to extend AI agents and chatbots with custom functionality, making them more powerful and flexible. We demonstrate how to use the Python FastMCP SDK to build an MCP server running locally. Then we consume that server from chatbots like GitHub Copilot in VS Code, using it's tools, resources, and prompts. Finally, we discover how easy it is to connect AI agent frameworks like Langchain and Microsoft agent-framework to the MCP server. Slides for this session Code repository with examples: python-mcp-demos Deploying MCP servers to the cloud 📺 Watch YouTube recording In our second session of the Python + MCP series, we deploy MCP servers to the cloud! We walk through the process of containerizing a FastMCP server with Docker and deploying to Azure Container Apps. Then we instrument the MCP server with OpenTelemetry and observe the tool calls using Azure Application Insights and Logfire. Finally, we explore private networking options for MCP servers, using virtual networks th ## Watch the recordings from my Python + AI series DevFeed: [Watch the recordings from my Python + AI series]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-10-31T14:22:00Z Content type: article Language: en Sources: [Pamela Fox]() Topics: [Python](), [Large Language Model](), [Embeddings](), [Retrieval Augmented Generation (RAG)](), [Azure OpenAI](), [Model Context Protocol](), [LangChain](), [SDK](), [OpenAI](), [Ollama]() Tags: [ai](), [embeddings](), [generative-ai](), [langchain](), [large-language-models-llms](), [mcp](), [ollama](), [openai](), [python](), [rag]() ### AI overview A blog article provides recordings and materials from a nine-part Python and generative AI series. It covers language models, embeddings, retrieval-augmented generation, evaluation and safety, AI agents, Model Context Protocol, and related Python examples using services including GitHub Models, Ollama, Azure OpenAI, and OpenAI models. ### Source excerpt My colleague and I just wrapped up a live series on Python + AI, a nine-part journey diving deep into how to use generative AI models from Python. I gave the english streams while my colleague Gwen gave the spanish streams (and I hung out in her live chat, working on my technical spanish!). The series introduced multiple types of models, including LLMs, embedding models, and vision models. We dug into popular techniques like RAG, tool calling, and structured outputs. We assessed AI quality and safety using automated evaluations and red-teaming. Finally, we developed AI agents using popular Python agents frameworks and explored the new Model Context Protocol (MCP). To apply the concepts, we put together code examples that run for free thanks to GitHub Models, a service that provides free models to every GitHub account holder for experimentation and education. The examples are also compatible with local models (via Ollama), Azure OpenAI, or OpenAI.com models. Even if you missed the live series, you can still access all the material using the links below! If you're an instructor, feel free to use the slides and code examples in your own classes. Python + AI: Large Language Models 📺 Watch recording In this session, we explore Large Language Models (LLMs), the models that power ChatGPT and GitHub Copilot. We use Python to interact with LLMs using popular packages like the OpenAI SDK and LangChain. We experiment with prompt engineering and few-shot examples to improve outputs. We also demonstrate how to build a full-stack app powered by LLMs and explain the importance of concurrency and streaming for user-facing AI apps. Slides for this session Code repository with examples: python-openai-demos Python + AI: Vector embeddings 📺 Watch recording In our second session, we dive into a different type of model: the vector embedding model. A vector embedding is a way to encode text or images as an array of floating-point numbers. Vector embeddings enable similarity search across ## Filter the tools from MCP servers DevFeed: [Filter the tools from MCP servers]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-09-18T17:35:00Z Content type: tutorial Language: en Sources: [Pamela Fox]() Topics: [Model Context Protocol (MCP)](), [GitHub Copilot](), [agentic-coding](), [vs-code](), [LangChain](), [Pydantic]() Tags: [agentic-coding](), [github-copilot](), [langchain](), [mcp](), [mcp-server](), [openai](), [python](), [vs-code]() ### AI overview A tutorial on filtering tools exposed by MCP servers to reduce LLM confusion, token usage, latency, context-window pressure, and unintended destructive actions. It covers GitHub Copilot in VS Code, LangChain v1, and Pydantic AI. ### Source excerpt What I like about MCP servers: they give me lots of great tools that can make my agents more powerful, with very little work on my side. 🎉 What I don't like about MCP servers: they give me TOO many tools! I usually only need a handful of tools for a task, but a server can expose dozens. 😿 The problems with too many tools: LLM confusion. The LLM will be presented with the tool definition for every single tool in the server, and it needs to decide which tool (if any) is the best for the job. That's a hard decision for an LLM - it's always better to make it easier for the LLM by narrowing the tool list. Increased tokens. The tool call definitions require more tokens, which can cost more money, increase latency, and potentially even go over the context window limit of the model. Destructive actions. A server may include tools that are read-only, just sending down data to serve as context, but many servers expose tools that do write operations, like the GitHub MCP server's tools for creating issues, closing issues, pushing branches, and many more. It's possible your task requires some of those write ops, but you generally want to be very explicit about whether an agent is allowed to take action that can actually change something about your accounts and environments. Otherwise, you can be in for a nasty surprise when the agent took actions that you weren't expecting. (Ask me how I know...) Fortunately, there is almost always a way to configure agents to only allow a subset of the tools from an MCP server. In this blog post, I'll share ways to filter tools in my favorite agentic coder, GitHub Copilot in VS Code, plus two popular AI agent frameworks, Langchain v1 and Pydantic AI. Agentic coding with GitHub Copilot in VS Code Global configuration When you are using agent mode in VS Code, configure the tools by selecting the gear icon near the chat input window. That will pop-up a window showing all your available tools, coming from both installed MCP servers and VS Code exte ## How I learn about generative AI DevFeed: [How I learn about generative AI]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-08-19T05:59:00Z Content type: opinion Language: en Sources: [Pamela Fox]() Topics: [Generative AI](), [AI Engineering](), [LLM evaluation / benchmarking](), [web applications](), [LLMs](), [Retrieval Augmented Generation (RAG)](), [Python](), [PyTorch](), [AI-assisted coding](), [Transformer](), [Deep learning](), [Language models]() Tags: [ai](), [ai-assisted-coding](), [ai-engineering](), [deep-learning](), [evaluation](), [generative-ai](), [llm](), [openai](), [python](), [pytorch](), [transformer-architecture]() ### AI overview The author shares the books, videos, newsletters, communities, and blogs they used to learn generative AI. The resources cover AI engineering, building large language models with Python and PyTorch, neural networks, model evaluation, retrieval-augmented generation, and AI-assisted coding. ### Source excerpt I do not consider myself an expert in generative AI, but I now know enough to build full-stack web applications on top of generative AI models, evaluate the quality of those applications, and decide whether new models or frameworks will be useful. These are the resources that I personally used for getting up to speed with generative AI. AI foundation Let's start first with the long-form content: books and videos that gave me a more solid foundation. AI Engineering By Chip Huyen This book is a fantastic high-level overview of the AI Engineering industry from an experienced ML researcher. I recommend that everybody read this book at some point in your learning journey. Despite Chip's background in ML, the book is very accessible - no ML background is needed, though a bit of programming with LLMs would be a good warm-up for the book. I loved how Chip included both research and industry insights, and her focus on the need for evaluation in the later chapters. Please, read this book! Build a Large Language Model By Sebastian Raschka This book is a deep dive into building LLMs from scratch using Python and Pytorch, and includes a GitHub repository with runnable code. I found it helpful to see that LLMs are all about matrix manipulation, and to wrap my head around how the different layers in the LLM architecture map to matrices. I recommend it to Python developers who want to understand concepts like the transformer architecture, or even just common LLM parameters like temperature and top p. If you're new to Pytorch, this book thankfully includes an intro in the appendix, but I also liked the Deep Learning with PyTorch book. Zero to Hero By Andrej Karpathy This video series builds neural networks from scratch, entirely in Jupyter notebooks. Andrej is a fantastic teacher, and has a great way of explaining complex topics. Admittedly, I have not watched every video from start to finish, but every time I do watch a video from Andrej, I learn so much. Andrej also gives great ta ## Evaluating GPT-5 for hallucination handling in RAG applications DevFeed: [Evaluating GPT-5 for hallucination handling in RAG applications]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-08-11T18:40:00Z Content type: opinion Language: en Sources: [Pamela Fox]() Topics: [Retrieval-Augmented Generation](), [Artificial Intelligence](), [OpenAI](), [SDKs](), [Azure](), [Ground truth / benchmark quality]() Tags: [ai](), [azure](), [evaluation](), [gpt](), [hallucinations](), [llm](), [models](), [openai](), [rag](), [sdk]() ### AI overview The article evaluates GPT-5 models in an Azure AI Foundry RAG template. It reports that GPT-5 identified when the source documents lacked enough information to answer a question, and describes broader bulk evaluations using the azure-ai-evaluations SDK across 50 question-and-answer pairs. ### Source excerpt OpenAI released the GPT-5 model family today, with an emphasis on accurate tool calling and reduced hallucinations. For those of us working on RAG (Retrieval-Augmented Generation), it's particularly exciting to see a model specifically trained to reduce hallucination. There are five variants in the family: gpt-5 gpt-5-mini gpt-5-nano gpt-5-chat: Not a reasoning model, optimized for chat applications gpt-5-pro: Only available in ChatGPT, not via the API As soon as GPT-5 models were available in Azure AI Foundry, I deployed them and evaluated them inside our popular open source RAG template. I was immediately impressed - not by the model's ability to answer a question, but by it's ability to admit it could not answer a question! You see, we have one test question for our sample data (HR documents for a fictional company's) that sounds like it should be an easy question: "What does a Product Manager do?" But, if you actually look at the company documents, there's no job description for "Product Manager", only related jobs like "Senior Manager of Product Management". Every other model, including the reasoning models, has still pretended that it could answer that question. For example, here's a response from o4-mini: However, the gpt-5 model realizes that it doesn't have the information necessary, and responds that it cannot answer the question: As I always say: I would much rather have an LLM admit that it doesn't have enough information instead of making up an answer. Bulk evaluation But that's just a single question! What we really need to know is whether the GPT-5 models will generally do a better job across the board, on a wide range of questions. So I ran bulk evaluations using the azure-ai-evaluations SDK, checking my favorite metrics: groundedness (LLM-judged), relevance (LLM-judged), and citation_match (regex based off ground truth citations). I didn't bother evaluating gpt-5-nano, as I did some quick manual tests and wasn't impressed enough - plus, we've never ## Red-teaming a RAG app: gpt-4o-mini v. llama3.1 v. hermes3 DevFeed: [Red-teaming a RAG app: gpt-4o-mini v. llama3.1 v. hermes3]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-08-04T17:08:00Z Content type: article Language: en Sources: [Pamela Fox]() Topics: [Artificial Intelligence](), [Retrieval Augmented Generation (RAG)](), [PostgreSQL](), [Python](), [Azure](), [Open Source]() Tags: [ai](), [azure](), [gpt](), [llama3](), [open-source](), [openai](), [postgresql](), [python](), [rag](), [red-teaming](), [testing]() ### AI overview This article examines red-teaming a retrieval-augmented generation application using an automated Red Teaming agent from the azure-ai-evaluations Python package. It describes how adversarial questions are generated, transformed with the open-source pyrit package, sent to a RAG-on-PostgreSQL application, and evaluated for unsafe responses across models including gpt-4o-mini, llama3.1, and hermes3. ### Source excerpt When we develop user-facing applications that are powered by LLMs, we're taking on a big risk that the LLM may produce output that is unsafe in some way - like responses that encourage violence, hate speech, or self-harm. How can we be confident that a troll won't get our app to say something horrid? We could throw a few questions at it while manually testing, like "how do I make a bomb?", but that's only scratching the surface. Malicious users have gone to far greater lengths to manipulate LLMs into responding in ways that we definitely don't want happening in domain-specific user applications. Red-teaming That's where red teaming comes in: bring in a team of people that are expert at coming up with malicious queries and that are deeply familiar with past attacks, give them access to your application, and wait for their report of whether your app successfully resisted the queries. But red-teaming is expensive, requiring both time and people. Most companies don't have the resources nor expertise to have a team of humans red-teaming every app, plus every iteration of an app each time a model or prompt changes. Fortunately, my colleagues at Microsoft developed an automated Red Teaming agent, part of the azure-ai-evaluations Python package. The agent uses an adversarial LLM, housed safely inside an Azure AI Foundry project such that it can't be used for other purposes, in order to generate unsafe questions across various categories. The agent then transforms the questions using the open-source pyrit package, which uses known attacks like base-64 encoding, URL encoding, Ceaser Cipher, and many more. It sends both the original plain text questions and transformed questions to your app, and then evaluates the response to make sure that the app didn't actually answer the unsafe question. RAG application So I red-team'ed a RAG app! My RAG-on-PostgreSQL sample application answers questions about products from a database representing a fictional outdoors store. It uses a basi ## Automated repo maintenance via GitHub Copilot coding agent DevFeed: [Automated repo maintenance via GitHub Copilot coding agent]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-07-24T15:05:00Z Content type: tutorial Language: en Sources: [Pamela Fox]() Topics: [GitHub Copilot](), [GitHub](), [coding](), [Model Context Protocol](), [Large Language Model](), [Pull Request](), [GitHub Actions](), [Python](), [npm](), [Terraform]() Tags: [agent](), [coding](), [github](), [github-actions](), [github-copilot](), [mcp](), [npm](), [pull-request](), [python](), [review](), [terraform](), [tooling]() ### AI overview The author describes using the GitHub Copilot coding agent to automate repetitive maintenance across many GitHub repositories. The agent handles assigned issues by creating pull requests, documenting a plan, and iterating based on review comments. The author also created GitHub Repo Maintainer to identify repositories needing specific maintenance tasks and create detailed Copilot issues. ### Source excerpt I have a problem: I'm addicted to making new repositories on GitHub. As part of my advocacy role at Microsoft, my goal is to show developers how to combine technology X with technology Y, and a repository is a great way to prove it. But that means I now have hundreds of repositories that I am trying to keep working, and they require constant upgrades: Upgraded Python packages, npm packages, GitHub Actions Improved Python tooling (like moving from pip to uv, or black to ruff) Hosted API changes (versions, URLs, deprecations) Infrastructure upgrades (Bicep/Terraform changes) All of those changes are necessary to keep the repositories working well, but they're both pretty boring changes to make, and they're very repetitive. In theory, GitHub already offers Dependabot to manage package upgrades, but unfortunately Dependabot hasn't worked for my more complex Python setups, so I often have to manually take over the Dependabot PRs. These are the kinds of changes that I want to delegate, so that I can focus on new features and technologies. Fortunately, GitHub has introduced the GitHub Copilot coding agent, an autonomous agent powered by LLMs and MCP servers that can be assigned issues in your repositories. When you assign an issue to the agent, it will create a PR for the issue, put a plan in that PR, and ask for a review when it's made all the changes necessary. If you have comments, it can continue to iterate, asking for a review each time it thinks it's got it working. I started off with some manual experimentation to see if GitHub Copilot could handle repo maintenance tasks, like tricky package upgrades. It did well enough that I then coded GitHub Repo Maintainer, a tool that searches for all my repos that require a particular maintenance task and creates issues for @Copilot in those repos with detailed task descriptions. Here's what an example issue looks like: A few minutes after filing the issue, Copilot agent sends a pull request to address the issue: To give you a ## Choosing Between MCP Agents and Scripted Automation with LLM Assistance DevFeed: [Choosing Between MCP Agents and Scripted Automation with LLM Assistance]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-07-21T14:43:00Z Content type: opinion Language: en Sources: [Pamela Fox]() Topics: [Model Context Protocol](), [Large Language Model](), [Automation](), [SDKs](), [Framework]() Tags: [apis](), [automation](), [automation-tools](), [cost](), [energy](), [frameworks](), [llms](), [mcp](), [sdks]() ### AI overview The author compares MCP-based agents with scripted automation that uses APIs and SDKs alongside LLMs for selected decisions. They favor the scripted approach because it offers more control and potentially better accuracy, while requiring fewer tokens, lower cost, and less energy than MCP-powered workflows. ### Source excerpt When we're building automation tools in 2025, I see two main approaches: Agent + MCP: Point an LLM-powered Agent at MCP servers, give the Agent a detailed description of the task, and let the Agent decide which tools to use to complete the task. For this approach, we can use an existing Agent from agentic frameworks like PydanticAI, OpenAI-Agents, Semantic Kernel, etc., and we can either use an existing MCP server or build a custom MCP server depending on what tools are necessary to complete the range of tasks. Old school with LLM sprinkles: This is the way we would build it before LLMs: directly script the actions that are needed to complete the task, using APIs and SDKs, and then bring in an LLM for fuzzy decision/analysis points, where we might previously use regular expressions or loving handcrafted if statements. There's a big obvious benefit to approach #1: we can theoretically give the agent any task that is possible with the tools at its disposal, and the agent can complete that task. So why do I keep writing my tools using approach #2?? Control: I am a bit of a control freak. I like knowing exactly what's going on in a system, figuring out where a bug is happening, and fixing it so that bug never happens again. The more that my tools rely on LLMs for control flow, the less control I have, and that gives me the heebie jeebies. What if the agent only succeeds in the task 90% of the time, as it goes down the wrong path 10% of the time? What if I can't get the agent to execute the task exactly the way I envisioned it? What if it makes a horrible mistake, and I am blamed for its incompetence? Accuracy: Very related to the last point -- the more LLM calls are added to a system, the harder it is to guarantee accuracy. The impossibility of high accuracy from multi-LLM workflows is discussed in detail in this blog post from an agent developer. Cost: The MCP-powered approach requires far more tokens, and thus more cost and more energy consumption, all things that I'd ## How MCP Servers Enable Agent-Driven API Mashups DevFeed: [How MCP Servers Enable Agent-Driven API Mashups]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-07-18T14:12:00Z Content type: opinion Language: en Sources: [Pamela Fox]() Topics: [Model Context Protocol](), [MCP Server](), [Artificial Intelligence](), [Claude](), [GitHub Copilot](), [Large Language Model](), [Playwright]() Tags: [agent](), [ai](), [apis](), [claude](), [code](), [copilot](), [llms](), [mcp](), [news](), [playwright]() ### AI overview The article compares MCP servers with the web APIs used in 2000s mashups. It explains that MCP's predictable tool interface lets AI agents combine capabilities from multiple servers, LLMs, and code interpreters to create integrated results for tasks such as matching lyrics to videos or generating documentation with screenshots. ### Source excerpt In the summer of 2006, I discovered the blossoming world of web APIs: HTTP APIs like the Flickr API, JavaScript APIs like Google Maps API, and platform APIs like the iGoogle gadgets API. I spent my spare time making "mashups": programs that connected together multiple APIs to create new functionality. For example: A search engine that found song lyrics from Google and their videos from YouTube A news site that combined RSS feeds from multiple sources A map plotting Flickr photos alongside travel recommendations I adored the combinatorial power of APIs, and felt like the world was my mashable oyster. Mashups were actually the reason that I got back into web development, after having left it for a few years. And now, with the growing popularity of MCP servers, I am getting a sense of deja vu. An MCP server is an API: it exposes functionality that another program can use. An MCP server must expose the API in a very strict way, outputting the tools definition to follow the MCP schema. That allows MCP clients to use the tools (API) from any MCP server, since their interface is predictable. But now it is no longer the programmers that are making the mashups: it's the agents. When using Claude Deskop, you can register MCP servers for searching videos, and Claude can match song lyrics to videos for you. When using GitHub Copilot Agent Mode, you can register the Playwright MCP server for browser automation, and it can write full documentation with screenshots for you. When using any of the many agent frameworks (Autogen, Openai-Agents, Pydantic AI, Langgraph, etc), you can point your Agent at MCP servers, and the agent will call the most relevant tools as needed, weaving them together with calls to LLMs to extract or summarize information. To really empower an agent to make the best mashups, give them access to a Code interpreter, and then they can write and run code to put all the tool outputs together. And so, we have brought mashups back, but we programmers are no longer ## Proficient Python: A free interactive online course DevFeed: [Proficient Python: A free interactive online course]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-06-23T21:17:00Z Content type: tutorial Language: en Sources: [Pamela Fox]() Topics: [Python](), [Learning](), [Programming](), [browser](), [Code]() Tags: [browser](), [course](), [development](), [free](), [learning](), [python]() ### AI overview Pamela Fox introduces ProficientPython.com, a free interactive course for learning introductory Python. The course teaches standard topics using a functions-first approach, with browser-based coding exercises that require no local Python setup. ### Source excerpt There are many ways to learn Python online, but there are also many people out there that want to learn Python for multiple reasons - so hey, why not add one more free Python course into the mix? I'm happy to finally release ProficientPython.com, my own approach to teaching introductory Python. The course covers standard intro topics - variables, functions, logic, loops, lists, strings, dictionaries, files, OOP. However, the course differs in two key ways from most others: It is based on functions from the very beginning (instead of being based on side effects). The coding exercises can be completed entirely in the browser (no Python setup needed). Let's explore those points in more detail. A functions-based approach Many introductory programming courses teach first via "side effects", asking students to either print out values to a console, draw some graphics, manipulate a webpage, that sort of thing. In fact, many of my courses have been side-effects-first, like my Intro to JS on Khan Academy that uses ProcessingJS to draw pictures, and all of our web development workshops for GirlDevelopIt. There's a reason that it's a popular approach: it's fun to watch things happen! But there's also a drawback to that approach: students struggle when it's finally time to abstract their code and refactor it into functions, and tend not to use custom functions even when their code would benefit from them. When I spent a few years teaching Python at UC Berkeley for CS61A, the first course in the CS sequence, I was thrown heads-first into the pre-existing curriculum. That course had originally been taught 100% in Scheme, and it stayed very functions-first when they converted it to Python in the 2000s. (I am explicitly avoiding calling it "functional programming" as functional Python is a bit more extreme than functions-first Python.) Also, CS61A had thousands of students, and functions-based exercises were easier to grade at scale - just add in some doctests! It was my first time ## Teaching Python with Codespaces DevFeed: [Teaching Python with Codespaces]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-06-01T15:14:00Z Content type: tutorial Language: en Sources: [Pamela Fox]() Topics: [Python](), [GitHub](), [Development](), [configuration](), [vs-code](), [Docker](), [Docker Image](), [Dockerfile]() Tags: [configuration](), [docker](), [github](), [python](), [tutorials](), [vs-code](), [vscode]() ### AI overview A tutorial on using GitHub Codespaces to teach Python, including browser-based VS Code environments and dev container configurations. It covers simple devcontainer.json files, Python-specific images, custom Dockerfiles, and Docker-based project setup for web app, data science, and generative AI classes. ### Source excerpt Whenever I am teaching Python workshops, tutorials, or classes, I love to use GitHub Codespaces. Any repository on GitHub can be opened inside a GitHub Codespace, which gives the student a full Python environment and a browser-based VS Code. Students spend less time setting up their environment and more time actually coding - the fun part! In this post, I'll walk through my tips for using Codespaces for teaching Python, particularly for classes about web apps, data science, or generative AI. Getting started You can start a GitHub Codespace from any repository. Navigate to the front page of the repository, then select "Code" > "Codespaces" > "Create codespace on main": By default, the Codespace will build an environment based off a universal Docker image, which includes Python, NodeJS, Java, and other popular languages. But what if you want more control over the environment? Dev Containers A dev container is an open specification for describing how a project should be opened in a development environment, and is supported by several IDEs, including GitHub Codespaces and VS Code (via Dev Containers extension). To define a dev container for your repository, add a devcontainer.json that describes the desired Docker image, VS Code extensions, and project settings. Let's look at a few examples, from simple to complex. A simple dev container configuration The simplest devcontainer.json specifies a Docker image, like from Docker Hub or the Microsoft Artifact Registry. Microsoft provides several Python-specific images optimized for dev containers. For example, my python-3.13-playground repository sets up Python 3.13 using one of those images, and also configures a few settings and default extensions: { "name": "Python 3.13 playground", "image": "mcr.microsoft.com/devcontainers/python:3.13-bullseye", "customizations": { "vscode": { "settings": { "python.defaultInterpreterPath": "/usr/local/bin/python", "python.linting.enabled": true }, "extensions": [ "ms-python.python", "ms-p ## A visual introduction to vector embeddings DevFeed: [A visual introduction to vector embeddings]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-05-28T20:10:00Z Content type: tutorial Language: en Sources: [Pamela Fox]() Topics: [Embeddings](), [OpenAI](), [dataset]() Tags: [azure](), [dataset](), [developers](), [embedding](), [embeddings](), [google](), [model](), [models](), [openai](), [vector]() ### AI overview A visual and textual introduction to vector embeddings, explaining how inputs are mapped to numerical vectors and comparing word2vec with OpenAI's text-embedding-ada-002 and text-embedding-3-small models. ### Source excerpt For Pycon 2025, I created a poster exploring vector embedding models, which you can download at full-size. In this post, I'll translate that poster into words. Vector embeddings A vector embedding is a mapping from an input (like a word, list of words, or image) into a list of floating point numbers. That list of numbers represents that input in the multidimensional embedding space of the model. We refer to the length of the list as its dimensions, so a list with 1024 numbers would have 1024 dimensions. Embedding models Each embedding model has its own dimension length, allowed input types, similarity space, and other characteristics. word2vec For a long time, word2vec was the most well-known embedding model. It could only accept single words, but it was easily trainable on any machine, it is very good at representing the semantic meaning of words. A typical word2vec model outputs vectors of 300 dimensions, though you can customize that during training. This chart shows the 300 dimensions for the word "queen" from a word2vec model that was trained on a Google News dataset: text-embedding-ada-002 When OpenAI came out with its chat models, it also offered embedding models, like text-embedding-ada-002 which was released in 2022. That model was significant for being powerful, fast, and significantly cheaper than previous models, and is still used by many developers. The text-embedding-ada-002 model accepts up to 8192 "tokens", where a "token" is the unit of measurement for the model (typically corresponding to a word or syllable), and outputs 1536 dimensions. Here are the 1536 dimensions for the word "queen": Notice the strange spike downward at dimension 196? I found that spike in every single vector embedding generated from the model - short ones, long ones, English ones, Spanish ones, etc. For whatever reason, this model always produces a vector with that spike. Very peculiar! text-embedding-3-small In 2024, OpenAI announced two new embedding models, text-embedding-3 ## Using DefaultAzureCredential across multiple tenants DevFeed: [Using DefaultAzureCredential across multiple tenants]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-04-29T05:51:00Z Content type: tutorial Language: en Sources: [Pamela Fox]() Topics: [Azure](), [Authentication](), [SDKs](), [Command-line interface](), [azd]() Tags: [authentication](), [azd](), [azure](), [cli](), [python](), [sdk]() ### AI overview This tutorial explains how to use DefaultAzureCredential when an Azure account is associated with multiple tenants. It presents two approaches: configuring the environment and active tenant, or selecting a specific credential and passing the desired tenant ID. ### Source excerpt If you are using the DefaultAzureCredential class from the Azure Identity SDK while your user account is associated with multiple tenants, you may find yourself frequently running into API authentication errors (such as HTTP 401/Unauthorized). This post is for you! These are your two options for successful authentication from a non-default tenant: Setup your environment precisely to force DefaultAzureCredential to use the desired tenant Use a specific credential class and explicitly pass in the desired tenant ID Option 1: Get DefaultAzureCredential working The DefaultAzureCredential class is a credential chain, which means that it tries a sequence of credential classes until it finds one that can authenticate successfully. The current sequence is: EnvironmentCredential WorkloadIdentityCredential ManagedIdentityCredential SharedTokenCacheCredential AzureCliCredential AzurePowerShellCredential AzureDeveloperCliCredential InteractiveBrowserCredential For example, on my personal machine, only two of those credentials can retrieve tokens: AzureCliCredential: from logging in with Azure CLI (az login) AzureDeveloperCliCredential: from logging in with Azure Developer CLI (azd auth login) Many developers are logged in with those two credentials, so it's crucial to understand how this chained credential works. The AzureCliCredential is earlier in the chain, so if you are logged in with that, you must have the desired tenant set as the "active tenant". According to Azure CLI documentation, there are two ways to set the active tenant: az account set --subscription SUBSCRIPTION-ID where the subscription is from the desired tenant az login --tenant TENANT-ID, with no subsequent az login commands after Whatever option you choose, you can confirm that your desired tenant is currently the default by running az account show and verifying the tenantId in the account details shown. If you are only logged in with the azd CLI and not the Azure CLI, you have a problem: the azd cli does no ## Use any Python AI agent framework with free GitHub Models DevFeed: [Use any Python AI agent framework with free GitHub Models]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-04-11T07:30:00Z Content type: tutorial Language: en Sources: [Pamela Fox]() Topics: [GitHub](), [AI Agent](), [Python](), [API](), [LLMs]() Tags: [ai-agent](), [api](), [azure](), [github](), [llms](), [python](), [sdk]() ### AI overview This tutorial explains how to use GitHub Models with Python AI agent frameworks through OpenAI-compatible chat completion endpoints. It demonstrates examples for eight frameworks and describes how to access models through the GitHub Models playground and generated SDK code. ### Source excerpt I ❤ when companies offer free tiers for developer services, since it gives everyone a way to learn new technologies without breaking the bank. Free tiers are especially important for students and people between jobs, where the desire to learn is high but the available cash is low. That's why I'm such a fan of GitHub Models: free, high-quality generative AI models available to anyone with a GitHub account. The available models include the latest OpenAI LLMs (like o3-mini), LLMs from the research community (like Phi and Llama), LLMs from other popular providers (like Mistral and Jamba), multimodal models (like gpt-4o and llama-vision-instruct) and even a few embedding models (from OpenAI and Cohere). So cool! With access to such a range of models, you can prototype complex multi-model workflows to improve your productivity or heck, just make something fun for yourself. 🤗 To use GitHub Models, you can start off in no-code mode: open the playground for a model, send a few requests, tweak the parameters, and check out the answers. When you're ready to write code, select "Use this model". A screen will pop up where you can select a programming language (Python/JavaScript/C#/Java/REST) and select an SDK (which varies depending on model). Then you'll get instructions and code for that model, language, and SDK. But here's what's really cool about GitHub Models: you can use them with all the popular Python AI frameworks, even if the framework has no specific integration with GitHub Models. How is that possible? The vast majority of Python AI frameworks support the OpenAI Chat Completions API, since that API became a defacto standard supported by many LLM API providers besides OpenAI itself. GitHub Models also provide OpenAI-compatible endpoints for chat completion models. Therefore, any Python AI framework that supports OpenAI-like models can be used with GitHub Models as well. 🎉 To prove my claim, I've made a new repository with examples from eight different Python AI agent ## Building a streaming DeepSeek-R1 app on Azure DevFeed: [Building a streaming DeepSeek-R1 app on Azure]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-04-02T18:15:00Z Content type: tutorial Language: en Sources: [Pamela Fox]() Topics: [Artificial Intelligence](), [deepseek](), [Azure](), [Deployment](), [Infrastructure as code](), [Python](), [Serverless](), [Inference]() Tags: [ai](), [azure](), [code](), [deepseek](), [deployment](), [inference](), [infrastructure-as-code](), [openai](), [python](), [serverless](), [streaming]() ### AI overview A tutorial on building a streaming DeepSeek-R1 application on Azure. It explains how to deploy the model as a serverless Azure AI Services resource, use keyless authentication, connect from Python, and present reasoning thoughts separately from the final answer. ### Source excerpt Update: The approach has slightly changed (in a good way!). Read this Microsoft Learn article for an updated guide. This year, we're seeing the rise in "reasoning models", models that include an additional thinking process in order to generate their answer. Reasoning models can produce more accurate answers and can answer more complex questions. Some of those models, like o1 and o3, do the reasoning behind the scenes and only report how many tokens it took them (quite a few!). The DeepSeek-R1 model is interesting because it reveals its reasoning process along the way. When we can see the "thoughts" of a model, we can see how we might approach the question ourself in the future, and we can also get a better idea for how to get better answers from that model. We learn both how to think with the model, and how to think without it. So, if we want to build an app using a transparent reasoning model like DeepSeek-R1, we ideally want our app to have special handling for the thoughts, to make it clear to the user the difference between the reasoning and the answer itself. It's also very important for a user-facing app to stream the response, since otherwise a user will have to wait a very long time for both the reasoning and answer to come down the wire. Here's an app with streamed, collapsible thoughts: You can deploy that app yourself from github.com/Azure-Samples/deepseek-python today, or you can keep reading to see how it's built. Deploying DeepSeek-R1 on Azure We first deploy a DeepSeek-R1 model on Azure, using Bicep files (infrastructure-as-code) that provision a new Azure AI Services resource with the DeepSeek-R1 deployment. This deployment is what's called a "serverless model", so we only pay for what we use (as opposed to dedicated endpoints, where the pay is by hour). var aiServicesNameAndSubdomain = '${resourceToken}-aiservices' module aiServices 'br/public:avm/res/cognitive-services/account:0.7.2' = { name: 'deepseek' scope: resourceGroup params: { name: aiServi ## Evaluating gpt-4o-mini vs. gpt-3.5-turbo for RAG applications DevFeed: [Evaluating gpt-4o-mini vs. gpt-3.5-turbo for RAG applications]() Original publisher: [Read original article]() Author: Pamela Fox (noreply@blogger.com) Published: 2025-03-06T08:22:00Z Content type: comparison Language: en Sources: [Pamela Fox]() Topics: [Retrieval Augmented Generation (RAG)](), [Artificial Intelligence](), [Azure]() Tags: [ai](), [azure](), [cost](), [evaluation](), [gpt](), [gpt-3](), [latency](), [openai](), [rag](), [vs]() ### AI overview The article evaluates gpt-4o-mini against gpt-35-turbo as the default model for the Azure RAG sample application. Across evaluations using HR documents and the author's blog, gpt-4o-mini had comparable groundedness and relevance, produced longer answers, took more generation time, and had lower overall cost because of its lower per-token pricing. ### Source excerpt The azure-search-openai-demo repository was first created in March 2023 and is now the most popular RAG sample solution for Azure. Since the world of generative AI changes so rapidly, we've made many upgrades to its underlying packages and technologies over the past two years. But we've never changed the default GPT model used for the RAG flow: gpt-35-turbo. Why, when there are new models that are cheaper and reportedly better, such as gpt-4o-mini? Well, changing the model is one of the most significant changes you can make to impact RAG answer quality, and I did not want to make the change without thorough evaluation. Good news! I have now run several bulk evaluations on different RAG knowledge bases, and I feel fairly confident that a switch to gpt-4o-mini is a positive overall change, with some caveats. In my evaluations, gpt-4o-mini generates answers with comparable groundedness and relevance. The time-per-token is slightly less, but the answers are 50% longer on average, thus they take 45% more time for generation. The additional answer length often provides additional details based off the context, especially for questions where the answer is a list or a sequential process. The gpt-4o-mini per-token pricing is about 1/3 of gpt-35-turbo pricing, which works out to a lower overall cost. Let's dig into the results more in this post. Evaluation results I ran bulk evaluations on two knowledge bases, starting with the sample data that we include in the repository, a bunch of invented HR documents for a fictitious company. Then, since I always like to evaluate knowledge that I know deeply, I also ran evaluations on a search index composed entirely of my own blog posts from this very blog. Here are the results for the HR documents, for 50 Q/A pairs: metric stat gpt-35-turbo gpt-4o-mini gpt_groundedness pass_rate 0.98 0.98 mean_rating 4.94 4.9 gpt_relevance pass_rate 0.98 0.96 mean_rating 4.42 4.54 answer_length mean 667.7 934.36 latency mean 2.96 3.8 citations_matched