An anonymous reader quotes a report from Ars Technica: A Donald Trump-backed push has failed to wedge a federal measure that would block states from passing AI laws for a decade into the National Defense Authorization Act (NDAA). House Majority Leader Steve Scalise (R-La.) told reporters Tuesday that a sect of Republicans is now "looking at other places" to potentially pass the measure. Other Republicans opposed including the AI preemption in the defense bill, The Hill reported, joining critics who see value in allowing states to quickly regulate AI risks as they arise. For months, Trump has pressured the Republican-led Congress to block state AI laws that the president claims could bog down innovation as AI firms waste time and resources complying with a patchwork of state laws. But Republicans have continually failed to unite behind Trump's command, first voting against including a similar measure in the "Big Beautiful" budget bill and then this week failing to negotiate a solution to pass the NDAA measure. [...] "We MUST have one Federal Standard instead of a patchwork of 50 State Regulatory Regimes," Trump wrote on Truth Social last month. "If we don't, then China will easily catch us in the AI race. Put it in the NDAA, or pass a separate Bill, and nobody will ever be able to compete with America." If Congress bombs the assignment to find another way to pass the measure, Trump will likely release an executive order to enforce the policy. Republicans in Congress had dissuaded Trump from releasing a draft of that order, requesting time to find legislation where they believed an AI moratorium could pass. "The controversial proposal had faced backlash from a nationwide, bipartisan coalition of state lawmakers, parents, faith leaders, unions, whistleblowers, and other public advocates," the NDAA, a bipartisan group that lobbies for AI safety laws, said in a press release. This "widespread and powerful" movement "clapped back" at Republicans' latest "rushed attempt to sneak preemption through Congress," Brad Carson, ARI's president, said, because "Americans want safeguards that protect kids, workers, and families, not a rules-free zone for Big Tech."

Read more of this story at Slashdot.

Our Python + MCP series is a three-part, hands-on journey into one of the most important emerging technologies of 2025: MCP (Model Context Protocol) — an open standard for extending AI agents and chat interfaces with real-world tools, data, and execution environments. Whether you're building custom GitHub Copilot tools, powering internal developer agents, or creating AI-augmented applications, MCP provides the missing interoperability layer between LLMs and the systems they need to act on.

Across the series, we move from local prototyping, to cloud deployment, to enterprise-grade authentication and security, all powered by Python and the FastMCP SDK. Each session builds on the last, showing how MCP servers can evolve from simple localhost services to fully authenticated, production-ready services running in the cloud — and how agents built with frameworks like Langchain and Microsoft’s agent-framework can consume them at every stage.

🔗 Register for the entire series.

You can also scroll down to learn about each live stream and register for individual sessions.

In addition to the live streams, you can also join office hours after each session in Foundry Discord to ask any follow-up questions.

To get started with your MCP learnings before the series, check out the free MCP-for-beginners course on GitHub.

Building MCP servers with FastMCP

16 December, 2025 | 6:00 PM - 7:00 PM (UTC) Coordinated Universal Time

Register for the stream on Reactor

In the intro session of our Python + MCP series, we dive into the hottest technology of 2025: 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 and consume that server from chatbots like GitHub Copilot. Then we build our own MCP client to consume the server. Finally, we discover how easy it is to connect AI agent frameworks like Langchain and Microsoft agent-framework to MCP servers. 

Deploying MCP servers to the cloud

17 December, 2025 | 6:00 PM - 7:00 PM (UTC) Coordinated Universal Time

Register for the stream on Reactor

In our second session of the Python + MCP series, we're deploying MCP servers to the cloud! We'll walk through the process of containerizing a FastMCP server with Docker and deploying to Azure Container Apps, and also demonstrate a FastMCP server running directly on Azure Functions. Then we'll explore private networking options for MCP servers, using virtual networks that restrict external access to internal MCP tools and agents. 

Authentication for MCP servers

18 December, 2025 | 6:00 PM - 7:00 PM (UTC) Coordinated Universal Time

Register for the stream on Reactor

In our third session of the Python + MCP series, we're exploring the best ways to build authentication layers on top of your MCP servers. That could be as simple as an API key to gate access, but for the servers that provide user-specific data, we need to use an OAuth2-based authentication flow. MCP authentication is built on top of OAuth2 but with additional requirements like PRM and DCR/CIMD, which can make it difficult to implement fully. In this session, we'll demonstrate the full MCP auth flow, and provide examples that implement MCP Auth on top of Microsoft Entra. 

Tis the season! Customers always ask the most interesting questions about cloud capabilities. This one isn't documented well and you have to sort of piece it together by "reading the tea leaves" (my least favorite). A customer asked me a question that sounded simple enough: “Can we stand up Azure Migrate in our brownfield tenant, run dependency mapping there, and then use Azure Migrate to migrate workloads into our new greenfield tenant?” If you’ve ever led a large-scale migration, that...

This week, we discuss AWS re:Invent announcements, Agentic Development, and OpenAI's Code Red. Plus, a Digital ID field test and more on silverware sorting.

Watch the YouTube Live Recording of Episode 549

Runner-up Titles

• Did you order the Code Red?
• In the year 2000
• Jane go swiftly
• Another day in the coal mine
• Goal Driven Development
• I want to believe
• Prove me wrong
• AI’s going to dig this hole faster
• Tornado of Innovation
• Revenue times Story

Rundown

• SiteAngel - bonus press quote from Brandon
• AWS
  • Amazon announces $50B investment to expand AI and supercomputing capabilities for US government
  • Top announcements of AWS re:Invent 2025
  • All the biggest news from AWS’ big tech show re:Invent 2025
  • AWS announces preview of AWS Interconnect - multicloud
  • The Future of AWS CodeCommit | Amazon Web Services
  • Nova Act
• Code Red
  • OpenAI CEO declares “code red” as Gemini gains 20 0 million users in 3 months
  • Anthropic reportedly preparing for one of the largest IPOs ever in race with OpenAI: FT
  • Microsoft stock sinks on report AI product sales are missing growth goals
• AI & Cloud Trends for November 2025

Relevant to your Interests

• Under My Roof Home Inventory + App - App Store
• Thoma Bravo invests in Azul
• Streamline Development with the Google Workspace Extension
• As its voice dictation app takes off, Wispr secures $25M from Notable Capital | TechCrunch
• Valve makes almost $50 million per employee
• HelixGuard
• What to know about a recent Mixpanel security incident
• ServiceNow to Expand Security Portfolio With Acquisition of Veza’s Leading AI-native Identity Security Platform
• Vista-Backed LogicMonitor Buys Monitoring Startup Catchpoint
• Google releases Nano Banana Pro, its latest image generation model
• Years of JSONFormatter and CodeBeautify Leaks Expose Thousands of Passwords and API Keys
• Netflix kills casting from phones

Nonsense

• Victorian Name Generator

Conferences

• cfgmgmtcamp 2026, February 2nd to 4th, Ghent, BE.
  • Coté speaking and doing live SDI with John Willis.
• DevOpsDayLA at SCALE23x, March 6th, Pasadena, CA
  • Use code: DEVOP for 50% off. CFP open until Dec. 1st.
• Devnexus 2026, March 4th to 6th, Atlanta, GA.

SDT News & Community

• Join our Slack community
• Email the show: questions@softwaredefinedtalk.com
• Free stickers: Email your address to stickers@softwaredefinedtalk.com
• Follow us on social media: Twitter, Threads, Mastodon, LinkedIn, BlueSky
• Watch us on: Twitch, YouTube, Instagram, TikTok
• Book offer: Use code SDT for $20 off "Digital WTF" by Coté
• Sponsor the show: ads@softwaredefinedtalk.com

Recommendations

• Brandon: Dampf Good BBQ
• Matt: UmamiPapi chilli oil
• Coté: Anta, slightly more in English. Also XdgBaseDirs.

Photo Credits

• Header

Download audio: https://aphid.fireside.fm/d/1437767933/9b74150b-3553-49dc-8332-f89bbbba9f92/49d56b4a-4dc9-421c-9400-ab79f06d22e1.mp3

---

If you've been using EventCounters for instrumenting your .NET applications, it's time to consider migrating to the newer System.Diagnostics.Metrics API. Based on the OpenTelemetry specification, the Metrics API offers a more modern, flexible, and standardized approach to application instrumentation.

Why migrate?

The Metrics API provides several advantages over EventCounters:

• Industry Standard: Built on OpenTelemetry, ensuring compatibility with a wide ecosystem of monitoring tools
• Better Performance: More efficient with lower overhead
• Richer Functionality: Support for histograms, exemplars, and more sophisticated metric types
• Improved API Design: Cleaner, more intuitive interface for defining and recording metrics
• Better Tooling Support: Growing ecosystem support from APM vendors and monitoring solutions

Microsoft has indicated that EventCounters are in maintenance mode, with new development focused on the Metrics API.

So reasons enough to migrate our EventCounters to the new Metrics API. Let's go for it!

Our original EventCounters example

With EventCounters, you typically created an EventSource and used specialized counter types:

Migration guide

Step 1: Add the required package

While System.Diagnostics.Metrics is part of .NET 6+, you may want to add OpenTelemetry packages for collection:

dotnet add package OpenTelemetry.Exporter.Console
dotnet add package OpenTelemetry.Extensions.Hosting

Step 2: Create a meter

Replace your EventSource with a Meter. The meter name should follow reverse domain name notation:

Step 3: Map counter types

Here's how EventCounter types map to Metrics API instruments:

Event Counter type	Metrics API equivalent	Use case
Event Counter	Counter<T>	Monotonically increasing values (requests, errors)
PollingCounter	ObservableGauge<T>	Current value snapshots (queue length, active connections)
IncrementingEventCounter	Counter<T>	Cumulative totals
IncrementingPollingCounter	ObservableCounter<T>	Cumulative totals from callbacks

Step 4: Migrate counter definitions

Now we move the different event counter types over:

Step 5(optional): Add tags

One powerful feature of the Metrics API is built-in support for tags. This allows you to give extra context to a metric:

Remark: You can further improve the performance of tags by using the built-in source generators.

Step 6: Configure ServiceCollection

In your application startup inside  Program.cs for ASP.NET Core add the following configuration:

Final result

Here is how the complete class looks like after the migration:

More information

Source-generated metrics with strongly-typed tags - .NET | Microsoft Learn

Understanding different metric APIs - .NET | Microsoft Learn