The art of simplicity

With the ever growing list of MCP servers and supported tools, it is hard to spot the right tool. With the v1.0 release of the official MCP C# SDK, you can make it a little bit easier to discover your tools thanks to the introduction of icon support — tools, resources, and prompts can now carry icon metadata that clients can display in their UIs. Because a picture is worth a thousand words MCP servers expose tools, resources, and prompts through list endpoints ( tools/list , resources/list , prompts/list ). Up until now, those lists were purely textual — names and descriptions. With icons, client applications like MCP Inspector or AI agent UIs can render visual identifiers alongside each item, making large tool catalogs much easier to navigate at a glance. The simple case: a single icon via attribute The quickest way to add an icon to a tool is through the IconSource parameter on the [McpServerTool] attribute: The same IconSource parameter is available on [McpServerResour...

After giving a GitHub Copilot training last week where I introduced the concept of hooks, one of the attendants asked me what would be a good example for a hook. Great question! A first use case I could think of is that we use a hook to format the AI generated code to match the style preferences and static analysis recommendations specified in an .editorconfig file. Tip: If you are looking for some inspiration, check out the hooks section in Awesome Copilot: awesome-copilot/docs/README.hooks.md at main · github/awesome-copilot What event should we use? There are multiple hook events that you can use: sessionStart , sessionEnd , userPromptSubmitted , preToolUse , postToolUse , and errorOccurred . As the formatting should be done after every code change, postToolUse seems the logical choice. Why not at SessionEnd ? postToolUse formats the file immediately after each edit. This means the agent sees clean, correctly structured usings before it reads the file again for its ...

As part of our secure SDLC strategy, we generate an SBOM(Software Bill of Material) and store it inside Dependency Track . This gives us a good overview of all our applications, their dependencies and vulnerable components. However after upgrading to the latest CycloneDx-dotnet version, our SBOM pipeline turned out broken. The problem When uploading an XML-based Software Bill of Materials (SBOM) to Dependency-Track, we started to encounter a 400 – Bad Request response. The culprit is a version mismatch: a recent update to the dotnet-CycloneDX tool now generates SBOMs in CycloneDX 1.7 format by default — a version that Dependency-Track does not yet support. Dependency-Track validates incoming SBOMs against its supported schemas. When it receives a 1.7 document, schema validation fails and the upload is rejected entirely. The dotnet-CycloneDX package was updated our your build server, silently bumping the default output format from CycloneDX 1.6 to 1.7. No code change, just...

Verifying frontend changes always meant a mental context switch: write code, alt-tab to a browser, poke around in DevTools, switch back. Even with a decent dev server, the loop was still manual — and for AI agents, it was essentially broken. Agents could write unit tests for logic, but verifying whether a button actually renders, whether a dialog triggers, or whether a layout holds up? That required a human in the loop. I first tried to tackle this problem by using the Playwright or Chrome Dev-Tools MCP server, but with the February 2026 release of VS Code (1.110) , that changes. Agents can now open, interact with, and inspect your running application directly inside VS Code's integrated browser — closing the development loop without any manual hand-off. How it works When browser agent tools are enabled, Copilot gains access to a set of tools that let it read and interact with pages in the integrated browser. As the agent interacts with the page, it sees updates to page co...

If you've been following the GitHub Copilot ecosystem, you've probably heard of the Awesome GitHub Copilot repo . It launched back in July 2025 with a straightforward goal: give the community a central place to share custom instructions, prompts, and chat modes for tailoring Copilot's AI responses. A lot of people contributed. As a result, the repo now contains 175+ agents, 208+ skills, 176+ instructions, 48+ plugins, 7 agentic workflows, and 3 hooks. And now the maintainers took it one step further and created an Awesome GitHub Copilot website and Learning hub . A website that actually helps you find things The new site lives at awesome-copilot.github.com and wraps the repo in a browsable interface built on GitHub Pages. The headline feature is full-text search across every resource — agents, skills, instructions, hooks, workflows, and plugins — with category filters to narrow things down. Each resource has its own page with a modal preview, so you can see exac...

At our organisation running a large fleet of .NET services, a deceptively simple question can be surprisingly hard to answer: what versions of .NET are our apps actually running in production? You'd think this would be easy. It isn't. Services get deployed, teams move on, and before long nobody is quite sure whether that one legacy service is still on .NET 6 — or even .NET Core 3.1. Spreadsheets fall out of date. README files lie. The only source of truth is what's actually running. We solved this with three lines of OpenTelemetry configuration. The problem We run dozens of .NET services across multiple teams. We are the middle of a push to .NET 10, but we have no reliable, centralised way to see the current state. We wanted to answer questions like: Which services are still on end-of-life .NET versions? Which teams still have work to do? After a migration wave, how do we confirm everything moved? The solution We already had OpenTelemetry set up ac...