There is a quiet standardization happening underneath the AI agent boom, and it has a name: the Model Context Protocol (MCP). If you build agents, wire tools into Copilot, or ship anything that lets a language model act on the real world, MCP is fast becoming the layer you cannot ignore. That is exactly why the community is gathering for MCP Connect  a full-day, vendor-neutral, community-run conference dedicated entirely to the protocol powering how AI agents connect with tools, data, and each other.

This post is written for AI engineers and developers. It explains what MCP is and why it matters now, previews what MCP Connect offers builders, walks through real, runnable server code, and points you at the best Microsoft resources  starting with MCP for Beginners so you arrive at the event ready to build, not just watch.

What is MCP Connect?

MCP Connect is described by its organizers as "Connecting Agents. Empowering Builders." It is a community-driven conference dedicated to the Model Context Protocol, the open standard that defines how AI agents talk to tools, data, and one another. The pitch is refreshingly direct: no vendor pitches, just builders talking to builders about making the protocol work in production.

Expect a day built around practical, engineering-first content:

• Hands-on workshops on building and securing MCP servers.
• Talks on client integration and agent interoperability.
• A community showcase of what people are actually shipping with the protocol today.
• Deep protocol discussion the kind of conversation you rarely get outside a focused, single-topic event.

The first two in-person dates on the calendar are:

• MCP Connect, San Francisco, Monday 14 September 2026 (event details), hosted by Global AI San Francisco.
• MCP Connect, Bengaluru, Saturday 26 September 2026 (event details), hosted by Global AI Bengaluru.

It is organized under the Global AI Community umbrella  built by and for the people shaping agent connectivity. You can subscribe for updates on the event page as new cities are announced.

Why MCP matters now

If you have built with large language models recently, you have hit the same wall everyone hits: the model reasons brilliantly but is blind to your world. It cannot read your database, call your internal API, search your documents, or trigger a deployment unless you hand-write glue code for every integration.

Think of MCP as a universal translator for AI applications. Just as USB-C lets any peripheral connect to any laptop without a custom cable per device, MCP lets an AI model connect to any tool or data source through one standardized protocol.

The economics are the real story. Before MCP, integrations were an M × N problem: every one of your M AI applications needed bespoke code to talk to each of your N tools. MCP turns that into an M + N problem. Build a tool once as an MCP server, and any MCP-compatible client  VS Code, GitHub Copilot, Claude Desktop, Cursor, and many others  can use it immediately.

The protocol is built on a clean client–server model with a small, learnable set of primitives:

• Tools  functions the model can call (query a database, send an email, run code).
• Resources data the server exposes for context (files, records, documents).
• Prompts reusable, parameterized prompt templates.
• Sampling a server asking the client's model to generate a completion, enabling collaborative workflows.
• Elicitation a server requesting structured input from the user mid-task.
• Roots boundaries that tell a server which directories or resources it is allowed to touch.

Communication runs over JSON-RPC, with transports for local processes (stdio) and remote servers (streamable HTTP). Write to the spec, and you interoperate with the entire ecosystem. The canonical reference lives at modelcontextprotocol.io.

Your first MCP server: see how little code it takes

The best way to prepare for a builder-focused event is to build something. Here is a minimal MCP server in Python using FastMCP. Notice how the protocol plumbing disappears — you just decorate functions and describe them.

# server.py — a minimal MCP server with two tools
from mcp.server.fastmcp import FastMCP

# Name your server; this identifies it to MCP clients
mcp = FastMCP("Calculator")

@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers and return the result."""
    return a + b

@mcp.tool()
def subtract(a: int, b: int) -> int:
    """Subtract b from a and return the result."""
    return a - b

if __name__ == "__main__":
    # Run over stdio so local hosts (VS Code, Claude Desktop) can connect
    mcp.run()

The same idea in TypeScript, using the official @modelcontextprotocol/sdk:

// server.ts — minimal MCP server in TypeScript
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "Calculator", version: "1.0.0" });

// Register a tool with a typed input schema
server.tool(
  "add",
  { a: z.number(), b: z.number() },
  async ({ a, b }) => ({
    content: [{ type: "text", text: String(a + b) }],
  })
);

// Connect over stdio and start listening
const transport = new StdioServerTransport();
await server.connect(transport);

That is a complete, runnable server. The docstrings and schemas are not decoration — MCP exposes them to the model so it knows when and how to call each tool. Clear descriptions are effectively prompt engineering for your tools. A common pitfall is leaving them vague, which leads the model to misuse or ignore the tool.

Connecting it in VS Code

Once your server runs, an MCP host connects to it. A typical VS Code configuration looks like this:

{
  "servers": {
    "calculator": {
      "command": "python",
      "args": ["server.py"]
    }
  }
}

VS Code has first-class MCP support for adding, managing, and debugging servers directly in the editor  see Add and manage MCP servers in VS Code.

From demo to production: what to focus on

A calculator is a great first server, but MCP Connect is about production. The gap between the two is where most engineering effort — and most of the event's value lives. Three areas deserve your attention.

1. Security is not optional

An MCP server is an API that an autonomous model can invoke. Treat it that way. The practices to internalize before you ship:

• Least privilege via roots constrain what a server can reach.
• Tool annotations mark tools readOnlyHint or destructiveHint so clients can warn users before destructive actions.
• Never pass untrusted input through a shell a classic command-injection vector when a tool wraps a subprocess.
• Dependency hygiene audit regularly and pin patched releases.
• Proper auth use OAuth2 and, in Microsoft environments, Microsoft Entra ID rather than long-lived secrets.

2. Interoperability is the whole point

The reason to write to the protocol instead of a single framework is that your server then works across the ecosystem. Test your server with the MCP Inspector before wiring it into any host — it is the single best debugging habit you can build early, letting you exercise tools, resources, and prompts in isolation.

3. Operations and observability

Remote MCP servers are real services. Plan for deployment (containers scale well), authentication, rate limiting, structured logging, and monitoring. If you run on Azure, Application Insights and Container Apps give you a straightforward path from a local stdio prototype to a monitored HTTP-streaming server.

Microsoft resources to prepare with

You do not need to walk into MCP Connect cold. Microsoft maintains a strong, free, and current set of MCP resources for exactly this journey.

• MCP for Beginners  the most complete hands-on curriculum, with code in C#, Java, JavaScript, Python, Rust, and TypeScript, from a 10-line server to a multi-lab production capstone. Start at https://aka.ms/mcp-for-beginners (the GitHub repository).
• Catalog of official Microsoft MCP servers reference implementations you can learn from and build on: github.com/microsoft/mcp.
• Azure MCP Server connect agents to Azure resources through MCP: Azure MCP Server documentation.
• MCP in VS Code add, configure, and debug servers in your editor: Add and manage MCP servers in VS Code.
• The official specification the source of truth for every primitive and transport: modelcontextprotocol.io.

A fast way to prepare: fork MCP for Beginners using a sparse checkout to skip translations, then build and debug your first server before the event.

git clone --filter=blob:none --sparse https://github.com/microsoft/mcp-for-beginners.git
cd mcp-for-beginners
git sparse-checkout set --no-cone "/*" "!translations" "!translated_images"

Why AI engineers and developers should attend

For AI engineers

MCP is becoming the default integration layer for agents. Instead of re-implementing tool calling for every framework, you write to one open protocol and your tools work everywhere. MCP Connect's deep-dive sessions on sampling, roots, elicitation, scaling, and multi-agent patterns are exactly the techniques that move agents from demo to production and hearing them from practitioners who have shipped is worth more than any slide deck.

For developers

MCP is already wired into the tools you use daily: VS Code, GitHub Copilot, Claude Desktop, and Cursor. Learning to build an MCP server means you can expose your systems — internal APIs, databases, CI/CD to AI assistants safely. A vendor-neutral event is the ideal place to compare integration approaches and pick up the security patterns that keep you out of trouble.

Responsible and secure by design

Because MCP hands an autonomous model the keys to real tools, responsible engineering is a first-class concern, not an afterthought. Carry these principles into whatever you build:

• Constrain scope grant the minimum access a server needs, and make destructive actions explicit and reviewable.
• Guard the boundary validate inputs, avoid shells for user-supplied data, and authenticate remote servers properly.
• Evaluate and monitor log tool calls, watch for anomalous behavior, and govern what agents can do in production.

Key takeaways

• MCP standardizes how AI connects to tools and data, turning a combinatorial integration problem into a simple, reusable one.
• MCP Connect is builder-first vendor-neutral, community-run, focused on making the protocol work in production.
• A working server takes minutes, but production requires deliberate attention to security, interoperability, and operations.
• Microsoft's MCP resources are the fastest on-ramp start with MCP for Beginners and the official spec.
• Show up ready to build, not just to watch, the value compounds when you can follow along hands-on.

Get involved

1. Explore the event: globalai.community/events/mcp-connect and subscribe for new city announcements.
2. Register for a date near you  San Francisco (14 Sep 2026) or Bengaluru (26 Sep 2026).
3. Learn the protocol with MCP for Beginners and the official spec.
4. Build your first server this week, debug it with the MCP Inspector, and connect it in VS Code.
5. Bring a project to the community showcase the best way to learn a protocol is to ship something with it.

MCP is quietly becoming the connective tissue of the AI ecosystem, and MCP Connect is where the builders shaping it are gathering. Learn the protocol, build a server, and come ready to connect your agents to the world.

Every company has a help desk, and every help desk answers the same twenty questions over and over: my VPN keeps dropping, I lost my MFA device, I need access to the Finance share. Sound familiar? That is exactly what makes it the perfect proving ground for an AI agent — not another chat demo that just talks, but a system that answers from real documentation, knows when it is not allowed to answer, and hands off to humans through a real channel.

So that is what we are building today: HelpDesk Copilot, a Contoso IT service desk where a Microsoft Foundry agent triages employee questions, answers them grounded on an IT knowledge base with citations, and — when policy demands a human — creates a ticket that flows asynchronously through Dapr and Azure Service Bus into Table Storage and an Adaptive Card in a Microsoft Teams channel.

The whole thing runs on Azure Container Apps, is provisioned entirely with Terraform, and — my favorite part — contains zero API keys. Every service-to-service call, from pulling container images to invoking the Foundry agent, uses Microsoft Entra ID and managed identities. The Foundry account has local key authentication disabled outright.

Here is what we will cover:

• The architecture: three ACA apps, one Foundry Prompt Agent, and an event-driven ticket pipeline
• Why I chose one agent instead of a multi-agent orchestra — and why that was the honest choice
• Grounded, streaming answers with Foundry File Search and citations
• The escalation path: Dapr pub/sub, a Service Bus topic, deterministic ticket IDs, and idempotency
• The identity model: five managed identities, zero connection strings
• Terraform notes: the Foundry provider landscape is not what you expect
• Observability with OpenTelemetry and Foundry's cloud evaluation API

Grab a coffee — let's build!

The Architecture

Three container apps live inside one ACA environment, and each one has a deliberately different network posture:

• Frontend — React 18 + Vite served by nginx, with external ingress. This is the only public URL: the chat UI and a live ticket panel.
• API — FastAPI with a Dapr sidecar, internal ingress only. It runs the agent conversation loop, streams Server-Sent Events, executes tools, and publishes ticket events.
• Ticket worker — FastAPI with a Dapr sidecar and no ingress at all. It exists only to consume Service Bus messages via Dapr, and KEDA wakes it from zero replicas based on subscription backlog.

The frontend's nginx proxies browser calls to the API over the ACA environment's internal DNS — the API is never exposed to the internet. Around the environment sit Microsoft Foundry (a Prompt Agent plus a File Search vector store), a Service Bus topic, Table Storage as the ticket read model, Key Vault holding exactly one secret, Azure Container Registry, and Application Insights on a Log Analytics workspace.

One Agent, Not an Orchestra

My original design called for an orchestrator agent routing to specialist agents. Reality intervened: the Connected Agents pattern I planned to use is deprecated, and the workflow orchestration alternatives are still in preview. I could have demoware'd my way around that — instead, I redesigned around one Foundry Prompt Agent with three capabilities:

• File Search over the Contoso IT knowledge base, for grounded answers with citations
• A local create_ticket function tool, for escalation
• A local get_ticket_status function tool, for lookup

Its instructions enforce the policy: search first, cite your source, and only create a ticket when no procedure covers the problem — or when the procedure explicitly requires human intervention (Finance-share access, a lost device, all MFA methods gone).

Here is the takeaway I want you to keep: a single well-instructed agent with sharp tools beats a fragile multi-agent mesh for this problem size. Multi-agent is a topology, not a virtue. When the platform's orchestration story stabilizes, this design has an obvious seam to split along — until then, one agent is simpler to reason about, cheaper to run, and easier to evaluate.

Similar honesty applies to retrieval: with ten markdown documents, Azure AI Search would be architectural cosplay. Foundry's built-in File Search vector store is the right-sized tool. When the corpus grows into thousands of documents needing hybrid or semantic ranking, that is the upgrade path.

The Knowledge Path: Streaming Grounded Answers

An employee asks: "My VPN keeps dropping every hour." The flow:

• The frontend POSTs to /chat with the message and an optional conversation_id
• The API creates (or continues) a Foundry conversation and requests a streamed response
• The agent runs File Search over the IT docs and gets relevant chunks back
• Text deltas and file citation annotations stream back through the API as Server-Sent Events
• The employee watches the answer type itself out, with the source document cited beneath it

Citations are not decoration. In an IT support context, "the answer came from the official VPN procedure" is the difference between a trustworthy assistant and a liability. The frontend de-duplicates cited filenames per answer and shows them inline.

The heart of the API is the tool-call loop. When the agent requests a local function, the API executes it and feeds the result back into the same Foundry conversation, so the agent composes the final employee-facing message. The agent stays the author of the conversation; the API stays the executor of side effects. Here is the loop, from agent_service.py:

The Escalation Path: Events, Not Awaits

Now the interesting request: "I need Finance-share access for an audit." The knowledge base says restricted Finance access always requires a ticket. The agent emits create_ticket, and this is where the architecture earns its keep:

• The API validates the tool input and computes a deterministic ticket ID
• It publishes a ticket.created event via its Dapr sidecar to the Service Bus topic ticket-events — and immediately streams the confirmation with the ticket ID back to the employee
• Dapr delivers the event to the worker through the ticket-worker subscription
• The worker upserts the ticket into Table Storage, reads the optional Teams webhook URL from Key Vault, and posts the payload to a Power Automate HTTP flow
• The IT team gets an Adaptive Card in their Teams channel. A human is now in the loop — a real one.

Chat acknowledgement never waits for persistence or Teams delivery. Three deliberate consequences follow.

Idempotency end-to-end. The ticket ID is derived, not generated:

If the model retries the tool call, or Service Bus redelivers the event (the subscription allows up to 10 deliveries), the worker upserts the same row instead of minting duplicate tickets. Idempotency is designed in at the ID level, not bolted on with dedup logic afterwards.

Eventual consistency, explained honestly. The ticket row may not exist for a few seconds while KEDA wakes the worker. Both the agent's status tool and the ticket endpoints treat "not visible yet" as a normal state and say so, and the UI polls every five seconds. Distributed systems do not hide their nature here — they narrate it.

A topic, not a queue. Today there is one subscription, so operationally it behaves like a work queue. But "a ticket was created" is an event, and tomorrow an ITSM connector, an audit log, or an analytics pipeline can each get their own subscription without the API changing a single line. Publishers describe facts; subscribers decide what facts mean.

This is the payload that travels unchanged from tool call, through Dapr and Service Bus, into the worker, Table Storage, and the Teams flow:

And the failure mode is designed too: if the Teams webhook is unset or down, the worker logs a warning and keeps the persisted ticket. Persistence happens first and returns success or retry to Dapr based only on the table write — so a Teams outage cannot cause repeated ticket writes.

Zero Keys: The Identity Model

This is the part I am proudest of. Every hop authenticates with Entra ID via DefaultAzureCredential — in ACA, AZURE_CLIENT_ID selects each app's user-assigned managed identity; locally, the same code rides on az login.

• API identity — AcrPull, Foundry agent access, Storage Table Data Reader, Key Vault Secrets User, Service Bus Sender. It invokes the agent, reads tickets, publishes events.
• Worker identity — AcrPull, Storage Table Data Contributor, Key Vault Secrets User, Service Bus Receiver. The sole writer of tickets.
• Frontend identity — AcrPull. It pulls its image, nothing more.
• Shared Dapr identity — Service Bus Data Owner, scoped to authenticating the Dapr component and the KEDA scaler.

Notice the reader/writer split: the API physically cannot modify a ticket, and the worker is the only writer. Least privilege is not a slide bullet here; it is enforced by RBAC per identity. The single unavoidable secret — the Power Automate webhook URL, which is bearer-style by nature — lives in Key Vault, and nowhere else.

Terraform Notes: The Provider Landscape Is Not What You Expect

Terraform is the source of truth for all Azure resources, split into four modules: platform, foundry, observability, and aca. Two lessons here were worth the price of admission.

1. The obvious-looking resources are the wrong ones.When I started, I assumed I would needazapi for the Foundry pieces. The real surprise was different: azurerm 4.x does ship azurerm_ai_foundry and azurerm_ai_foundry_project — but those provision the classic, hub-based Foundry model, not the GA project-based Foundry Agent Service. The current model is provisioned directly on a Cognitive Services account, fully covered by azurerm, no azapi required:

There was one genuine gotcha, though: the built-in Foundry Agent Consumer role grants enough to call the Responses API against an existing thread, but conversations.create() — which the API calls on every new chat — needs the agents/write data action too. I confirmed that live, with a 403 to show for it. The broader Foundry User role would work, but it also grants key-listing and the whole Cognitive Services surface. The fix is a small custom role definition granting exactly the three data actions the chat runtime exercises: interact, agents read, agents write. Least privilege, again.

2. Terraform provisions infrastructure — it does not configure agents. 

The vector store, document upload, and agent version are deliberately not Terraform resources. A seed_knowledge.py bootstrap runs after terraform apply, authenticated as a principal Terraform granted the Foundry Project Manager role. Agent instructions and knowledge content change on an application cadence, not an infrastructure cadence — mixing the two lifecycles is how you end up re-uploading your knowledge base because you resized a container app. Dapr's entity management is disabled for the same reason: Terraform explicitly owns the topic and subscription.

Observability and Evaluation

The API initializes Azure Monitor OpenTelemetry, and every Foundry invocation gets a custom agent.invoke span carrying the agent name, conversation ID, selected tools, and input/output token counts when the response exposes them. Platform logs and metrics from all three apps flow to the same Log Analytics workspace. Ask "what did that conversation cost and which tool did it pick?" and App Insights answers.

There is also an evaluation script that pushes ten fixed questions through Foundry's cloud evaluation API, scoring intent resolution, coherence, and task adherence. File-search questions evaluate end-to-end; locally executed function tools need a response-capture approach — a limitation worth knowing before you promise your boss automated agent QA.

If this section feels short, good — agent observability and governance in production deserves its own post, and it is getting one. Consider this the trailer.

What This Deliberately Is Not

Honesty section. HelpDesk Copilot is production-shaped, not production-finished:

• No browser authentication yet. Conversation IDs partition the ticket panel but are not an authorization boundary. A real rollout adds Entra ID sign-in and server-side authorization before exposing ticket data.
• Tickets stay New. The human handoff is the real Teams notification, not a simulated ITSM lifecycle. Wiring status updates back from an ITSM tool is exactly what the topic's future subscriptions are for.
• Global ticket lookup scans partitions. Fine at demo volume; a high-volume system adds an index.

I would rather ship a clear boundary than a hidden one.

Try It

The full source — Terraform modules, all three services, the knowledge base, seed and evaluation scripts — is on GitHub: passadis/foundry-ticketing

Quickstart: terraform apply, run seed_knowledge.py, build and push the three images, and ask the public URL why your VPN keeps dropping. With scale-to-zero on all three apps and a small model deployment, idle cost is close to nothing — the architecture only spends money when someone needs help.

Conclusion

The AI part of this solution is maybe twenty percent of the code. The rest is the unglamorous engineering that makes an agent deployable: identity, ingress boundaries, idempotent events, honest eventual consistency, IaC lifecycle boundaries, and telemetry. That ratio is the real lesson — and it is exactly why Azure Container Apps plus Microsoft Foundry is such a productive pairing: the platform absorbs the undifferentiated heavy lifting so the interesting decisions remain yours.

Next up in this series: taking the agent.invoke spans further — tracing, token economics, drift, and governance for agents in production with Foundry's control plane and Azure Monitor.

Until then — happy building! 🚀

From aerial displays to prototyping tools, Raspberry Pi–accredited hardware enables it all. Here are some highlights from the latest batch of third-party products to join the Powered by Raspberry Pi roster.

As summer continues here in Europe, our weekend skies are filled with birds, kites, and buzzing craft directed aloft by eager pilots. Where once drones were heavy, clunky, and chewed through batteries in minutes, modern UAVs (unmanned aerial vehicles) are elegant, agile, and capable of remaining airborne for extended periods. Now there are drones for everything from underwater research to aerial filming, as well as modern takes on the classic remote-control plane. Paired with a lightweight camera module, they can capture stunning photos and video footage. HighGreat, who we feature in this list of Powered by Raspberry Pi products, uses them in coordinated light shows — notably at the Beijing Winter Olympics in 2022. With a global audience admiring its engineering prowess, it’s no wonder the company also runs a successful education and engineering programme, alongside offering unmanned aerial craft that customers can build themselves.

Getting started in electronics is the very essence of specialist stores like Pimoroni, which continues to delight us with HATs, accessories, and bespoke boards at pocket-money prices. Once you’ve mastered the essentials of Raspberry Pi and Python/MicroPython, it’s immediately rewarding to experiment with sensors, connectors, lights, and LCDs to see what your newly acquired coding skills can achieve. Pimoroni’s Explorer board, based around the RP2350 chip, offers exactly this, functioning as an all-in-one electronics kit. 

While sky-spanning spectacles featuring hundreds of drones demonstrate the power of Raspberry Pi as a central controller, our microcontrollers also excel in even the tiniest of applications. Read on to find out about DigiCue and its role in helping amateur and professional snooker and billiards players achieve pinpoint accuracy. It’s every bit as wonderfully nerdy as it sounds. 

Freya Vivariums 

Belgium

We’ve featured a fair few pets and reptiles over the years, including a specially constructed hibernation chamber for a much-loved tortoise, but this reptile-focused setup improves on the very idea of creating the ideal conditions for reptiles to coexist with humans. Freya Vivariums offers a whole slew of open source equipment that can be purchased or 3D-printed, enabling you to design an environment in which temperature, light, and humidity are managed via Raspberry Pi’s lab-grade sensors. The Perspex enclosure allows curious owners of all ages to observe their reptile sunning itself, strutting around its domain, or hiding among the lush and tasty foliage.

HighGreat Hula

China

HighGreat specialises in impressive drone formation light shows and spectacular performances that wow and inspire audiences, including at the 2022 Beijing Winter Olympics. The educational arm of the company runs design competitions and AI coding courses, as well as offering its Fylo EDU and Hula drones (complete with their own apps). All this comes with full learning support and adheres to RoboAlliance standards, meaning Hula and Fylo are open source and can be controlled using Raspberry Pi. The educational programme for both vehicle types aims to promote a deep curricular understanding of artificial intelligence systems, equipping students with the skills they need to thrive in an intelligent society.

Pimoroni Explorer

UK

Pimoroni’s self-described ‘electronic adventure playground’ is a fantastic showcase for Raspberry Pi’s RP2350 chip. The kit features a mini breadboard on which to wire up components, two servos and servo headers to power the pair of 60mm wheels, analogue inputs and GPIO pins galore, leads, jumpers, and I2C breakouts. While these take care of connectivity and motors, there is also a healthy provision of buzzers and lights, plus a built-in speaker, a movement, light, and environment sensor, and a 2.8-inch LCD to show what’s going on. With all of this included in a £33 kit, it’s no wonder the Pimoroni Explorer routinely features in our must-have Raspberry Pi accessories guides.

BitMechanics Pixel Pump

Germany

There’s a lot to like about the Pixel Pump. As well as being based around RP2040 (so we thoroughly approve), it can be purchased either as a finished product or as a 3D-printable kit, potentially saving customers some money while giving them the option to print in any colour for which you can get filament. If you’re wondering what on earth it does, it’s a vacuum pump for rapid prototyping and small batch production, suctioning up tiny components with ease and avoiding issues with greasy or clumsy fingers. The enthusiastic owners of a Pixel Pump at Nottingham Hackspace use theirs as a manual pick-and-place aid, akin to a fancy pair of tweezers. The Pixel Pump has modes to lift and lower ‘on trigger’ via the buttons or the foot pedal, and can optionally be controlled at a distance via USB. 

DigiCue DigiCast TV Kit

USA

This Raspberry Pi–based TV kit is specially designed to work with DigiBall and DigiCue stroke trainers, displaying the performance of multiple players on a large screen at 1920×1080 pixels. Once connected via HDMI, the DigiCast software pre-installed on the SD card in the kit loads automatically. The DigiCue trainer fits over the butt of a snooker or billiards cue and is recognised by the Raspberry Pi module included in the TV Kit. Details are displayed on screen so that keen-to-improve players can see what they are doing well and which areas they need to work on. 

Angles and straightness are accurately plotted and represented, allowing ardent snooker and pool players to gain real insights into their cueing and improve their accuracy. It can even be used when playing carom billiards, and is able to recognise additional cue balls and provide insights into the stroke. The DigiCue system provides a visual display of the amount of spin and curve applied to the cue ball, simulating both its rotations per second and where the cue struck it. During play, the cue subtly vibrates to hint at a flaw in the player’s stroke. 

Presearch Node

Canada

Privacy and data storage have been hot topics for years, with cybersecurity experts warning users not just about tracking and hacking, but also where they store digital files. Private browsing modes and privacy-focused search engines such as DuckDuckGo can help avoid cookies sharing your every online move, but decentralised search offers another good option. Presearch promises unfiltered and untracked online searches via nodes that operate as community servers. The software runs on a 64-bit Raspberry Pi computer. You can buy a system already set up in a custom case from US-based Coinmonster. This 4×4-inch Presearch Node hardware is based on an 8GB Raspberry Pi 4 and comes with the Presearch Node software, as well as Raspberry Pi OS, pre-installed on a 32GB microSD card. 

Given that it’s got a Raspberry Pi 4 inside, it’s no surprise to learn that the Presearch Node sports a Broadcom BCM2711 SoC with Arm Cortex-A72 cores, alongside Gigabit Ethernet, 2.4GHZ and 5GHz wireless connectivity, and Bluetooth 5.0. It also has two USB 3.0 and USB 2.0 ports, plus two micro HDMI ports for a display. You will need a separate IP address for each Presearch Node you run.

The post Vivariums, drone shows, and TV kits, all powered by Raspberry Pi appeared first on Raspberry Pi.

This article shows how to implement a SAML federation from an ASP.NET Core Identity application using Sustainsys.Saml2.AspNetCore2. Entra ID is used to implement the SAML authentication and the users can authenticate from the tenant.

Code: https://github.com/damienbod/DuendeEntraSaml

Setup

Three components are used to implement this demo, a web application that authenticates using OpenID Connect, an ASP.NET Core OpenID Connect server using Duende, and a SAML application that authenticates using Entra ID and an Enterprise Application. The web client understands only OpenID Connect and uses the claims returned from the authentication process. Duende IdentityServer acts as a gateway for Entra ID identities. The application uses SAML.

SAML client

The Sustainsys.Saml2.AspNetCore2 Nuget package is used to implement the SAML client. Duende IdentityServer uses this to implement the external authentication federation. The settings are read from a configuration and the properties must match the settings form the Entra ID tenant Enterprise application. After a successful authentication, the claims principal is stored in a secure HTTP only cookie.

        var samlTenantId = builder.Configuration["Saml:TenantId"];
        var samlMetadataLocation = builder.Configuration["Saml:MetadataLocation"]
            ?? $"https://login.microsoftonline.com/{samlTenantId}/federationmetadata/2007-06/federationmetadata.xml";
        var samlIdpEntityId = builder.Configuration["Saml:IdpEntityId"] ?? $"https://sts.windows.net/{samlTenantId}/";
        var samlSpEntityId = builder.Configuration["Saml:SpEntityId"] ?? "https://localhost:5021/Saml2";
        var samlReturnUrl = builder.Configuration["Saml:ReturnUrl"] ?? "https://localhost:5021/";

        // Load this depending on your environment, change the code as required. For example, you can load it from Azure Key Vault or from a secure location.
        var samlToolkitCertificatePath = Path.Combine(builder.Environment.ContentRootPath, "MicrosoftEntraSAMLToolkit.cer");
        var samlIdentityProviderCertificate = LoadIdentityProviderCertificate(samlToolkitCertificatePath);

Client authentication setup using SAML:

// https://docs.duendesoftware.com/identityserver/ui/login/saml-provider/
// https://learn.microsoft.com/en-us/entra/identity/saas-apps/saml-toolkit-tutorial
// https://github.com/Sustainsys/Saml2
builder.Services.AddAuthentication()
     .AddCookie("samlcookie")
     .AddSaml2(Saml2Defaults.Scheme, "entra-saml-idp", options =>
     {
         options.SignInScheme = "samlcookie";
         options.SPOptions.ValidateCertificates = false;
         options.SPOptions.EntityId = new EntityId(samlSpEntityId);
         options.SPOptions.ReturnUrl = new Uri(samlReturnUrl);

         var idp = new Sustainsys.Saml2.IdentityProvider(
             new EntityId(samlIdpEntityId), options.SPOptions)
         {
             MetadataLocation = samlMetadataLocation,
             LoadMetadata = true,
             //AllowUnsolicitedAuthnResponse = true
         };

         if (samlIdentityProviderCertificate is not null)
         {
             idp.SigningKeys.AddConfiguredKey(samlIdentityProviderCertificate);
             Log.Information(
                 "Loaded SAML signing certificate from {CertificatePath}. Thumbprint: {Thumbprint}",
                 samlToolkitCertificatePath,
                 samlIdentityProviderCertificate.Thumbprint);
         }
         else
         {
             Log.Warning("SAML signing certificate file not found or invalid: {CertificatePath}", samlToolkitCertificatePath);
         }

         LoadIdentityProviderMetadata(idp, samlMetadataLocation);

         options.IdentityProviders.Add(idp);
     });

The SAML metadata is loaded using a helper method called LoadIdentityProviderMetadata. This loads the metadata as defined by the Entra ID Enterprise Application. The certificate is downloaded from the Entra ID Enterprise Application and loaded from a file. This should be improved if implemented in a production environment.

private static void LoadIdentityProviderMetadata(Sustainsys.Saml2.IdentityProvider idp, string metadataLocation)
{
    try
    {
        var metadata = MetadataLoader.LoadIdp(metadataLocation);
        idp.ReadMetadata(metadata);

        Log.Information(
            "Loaded SAML metadata from {MetadataLocation}. Signing key count: {SigningKeyCount}",
            metadataLocation,
            idp.SigningKeys.Count());
    }
    catch (Exception ex)
    {
        Log.Warning(ex, "Failed to load SAML IdP metadata from {MetadataLocation}", metadataLocation);
    }
}

private static X509Certificate2? LoadIdentityProviderCertificate(string certificatePath)
{
    try
    {
        if (!File.Exists(certificatePath))
        {
            return null;
        }

        return X509CertificateLoader.LoadCertificateFromFile(certificatePath);
    }
    catch (Exception ex)
    {
        Log.Warning(ex, "Failed to load SAML certificate from {CertificatePath}", certificatePath);
        return null;
    }
}

SAML client setup Entra ID

Note: If you are setting this up in an Entra ID tenant, always use OpenID Connect rather than SAML. SAML should only be used where OpenID Connect is not available.

The Microsoft Entra SAML Toolkit is used to set up the Entra Enterprise Application. The properties must be configured to match the ASP.NET Core Identity application. The Entra Enterprise Application is used for single sign-on.

Start the SAML authentication

The SAML authentication is started using a Challenge request for the correct scheme. The scheme is passed in the items and used in the external callback.

app.MapGet("/login/entra-saml", async (HttpContext context) =>
{
    await context.ChallengeAsync(Saml2Defaults.Scheme, new AuthenticationProperties
    {
        RedirectUri = "/ExternalLogin/Callback", // where to go after successful login
        Items = { ["scheme"] = Saml2Defaults.Scheme }
    });
});

The authentication can be started from the UI.

<a class="btn btn-primary" href="/login/entra-saml">
    Sign in with Entra ID (SAML)
</a>

External Callback claims mapping using ASP.NET Core Identity

When the SAML authentication is completed, the Callback method handles the result. This sets up the user account and creates a claims principal for the user and the result is returned back to the web application.

public async Task<IActionResult> OnGet()
{
    // read external identity from the temporary cookie
    var result = await HttpContext.AuthenticateAsync("entraidcookie");

    if (result.Succeeded != true)
    {
        result = await HttpContext.AuthenticateAsync("adminentraidcookie");
    }

    if (result.Succeeded != true)
    {
        result = await HttpContext.AuthenticateAsync("samlcookie");
    }

    if (result.Succeeded != true)
    {
        throw new InvalidOperationException($"External authentication error: {result.Failure}");
    }

    var externalUser = result.Principal ??
        throw new InvalidOperationException("External authentication produced a null Principal");

    if (_logger.IsEnabled(LogLevel.Debug))
    {
        var externalClaims = externalUser.Claims.Select(c => $"{c.Type}: {c.Value}");
        _logger.ExternalClaims(externalClaims);
    }

Notes

SAML can be used to implement external federation in any ASP.NET Core application. This works like the OpenID Connect setup, just a bit more complicated and less supported. I used Entra ID as an example. Entra ID Enterprise applications implemented using OpenID Connect is a better choice for this.

Links

https://docs.duendesoftware.com/identityserver/saml

https://github.com/DuendeSoftware/samples/tree/main/IdentityServer/v8/SAML

https://learn.microsoft.com/en-us/entra/external-id/direct-federation

https://github.com/Sustainsys/Saml2

https://learn.microsoft.com/en-us/entra/architecture/auth-saml

https://learn.microsoft.com/en-us/entra/identity/saas-apps/saml-toolkit-tutorial

https://docs.duendesoftware.com/identityserver/usermanagement/getting-started

https://docs.duendesoftware.com/identityserver/usermanagement/identityserver-integration

https://zitadel.com/docs/guides/integrate/identity-providers/azure-ad-saml

https://learn.microsoft.com/en-us/entra/external-id/direct-federation

https://github.com/jitbit/AspNetSaml

https://github.com/Sustainsys/Saml2

https://learn.microsoft.com/en-us/entra/architecture/auth-saml

In digital operations management, AI agents give organizations a competitive edge by reducing incident volume and accelerating recovery. The potential for transformation is real, but only when agents are deployed against a single targeted use case, rather than simply adding an “AI layer” to existing capabilities.

One practical area where enterprise AI agents can reshape traditional workflows is site reliability engineering (SRE), where the standard operating model is reactive and human-centric. This model carries a heavy cost, burdening engineers with repetitive toil that swallows their time and can lead to burnout. 

SRE AI agents offer a way to change how site reliability engineers work, turning them from “doers” manually managing operations to “managers” leading a team of agents that proactively drive operational improvements.

From runbooks to root cause analysis: where agents help most

There are five practical ways SRE AI agents can lighten the load on engineering teams:

1. Working autonomously

Traditional SRE work is guided by the runbooks that engineers write and update. After receiving an alert, engineers log in, run diagnostics, apply fixes, and, where possible, build automation to speed up remediations of similar incidents in the future. Even when automation is added, the incident management process relies on a human to manage it end-to-end. 

SRE AI agents change that. After ingesting an alert and understanding its context – for example, correlating a memory-spike alert with a recent update or deployment – they can execute actions to solve routine issues autonomously.

2. Building memory from operations data

SREs rely on considerable firsthand experience to piece together an incident and its contributing factors. But as digital systems grow more complex, that institutional knowledge becomes much harder to scale. If a subject matter expert is unavailable, the organization loses access to the necessary knowledge to resolve the incident quickly.

“Working at machine speed to process this data, AI agents can make appropriate recommendations and even repair issues themselves in the case of low-risk, routine problems.”

SRE AI agents trained on real, historical incident data can draw from prior incidents and the corresponding actions taken to quickly diagnose and remediate repeat issues. Working at machine speed to process this data, AI agents can make appropriate recommendations and even repair issues themselves in the case of low-risk, routine problems.

3. Eliminating toil

Engineers put a great deal of time and effort into automating manual, repetitive tasks to reduce toil, but automation isn’t the same as autonomy. These automated workflows still need an engineer to trigger the start and assess the outputs. 

SRE AI agents go a step further and eliminate entire classes of toil altogether, such as autonomously restarting a downed service without needing to be scripted or triggered by a human first.

4. Proactive approach

SRE teams spend much of their time in firefighting mode, reactively fixing issues rather than improving long-term systems health and reliability. With an SRE AI agent managing incidents, engineers gain time to focus on reinforcing system resilience, enhancing observability, and strengthening architecture for the future. 

“As agents take on more of the day-to-day work of incident management, the SRE role evolves from tactical fixer to strategic decision-maker.”

As agents take on more of the day-to-day work of incident management, the SRE role evolves from tactical fixer to strategic decision-maker.

5. Shifting humans to context engineering

Engineers bring deep technical knowledge of systems, scripting languages, and infrastructure tools. That expertise doesn’t disappear with agents; it moves up a level. Instead of running commands themselves, engineers use their knowledge to train AI agents about their environment: the tools they can use, the actions they can take safely, and their relevant service dependencies. Engineers’ roles shift from execution to setting the guardrails within which the AI agents operate.

The new role of the SRE

SREs face a constant uphill struggle against being overwhelmed. To fight this, some organizations have set strict toil limits for engineers. However, toil limits still force engineers to spend up to half of their working time manually resolving incidents. 

The underlying workload doesn’t disappear; it simply gets capped rather than solved. SRE AI agents shift engineers from technology practitioners manually remediating breakages to strategic operators overseeing a suite of AI agents.

“The underlying workload doesn’t disappear; it simply gets capped rather than solved. SRE AI agents shift engineers from technology practitioners, to strategic operators overseeing a suite of AI agents.”

The new shape of the roles changes how engineers experience their work day-to-day, with reduced stress and burnout risk, more mental space for innovation, system improvements, and other high-value work that brings real value to the organization, not just keeps it afloat.

The post 5 ways SRE AI agents are set to augment human capabilities appeared first on The New Stack.