The art of simplicity

This is a follow-up on an earlier post where I demonstrated how to build your own MCP server in C# and expose one or more MCP resources. Today we dive a little bit deeper and look at some more advanced features you can add to your MCP server implementation. Working with complex return types Resources can return various types. Here are some advanced examples: Return values from resource methods can be strings (for simple text), ReadResourceResult (for full control), or other types that the SDK automatically marshals into the appropriate format. Dependency injection Resources can use dependency injection to access services: We changed our implementation to use instance methods (not static). Now we need to register the class in Program.cs: Progress reporting For long-running operations, you can report progress: IProgress parameters accepting ProgressNotificationValue values enable progress reporting from resources to clients, with progress notifications propaga...

NET 10 introduces a new feature for developers: one-shot tool execution. If you've ever needed to quickly run a .NET tool for a CI/CD pipeline, a one-off script, or just to try something out without cluttering your system with globally installed tools, this feature is for you. What is one-shot tool execution? One-shot tool execution allows you to run .NET tools directly without installing them globally or locally on your machine. Instead of the traditional two-step process of installing and then running a tool, you can now execute it in a single command. Some use case where I think you could use this feature : CI/CD pipelines where you want clean, reproducible builds Ephemeral environments like containers or temporary build agents Quick experimentation with tools before committing to installation Scripts and automation that need specific tools without side effects The traditional way vs. one-shot execution Previously, to use a .NET tool, you'd ne...

After the introduction of Plan mode in Visual Studio , it now also found its way into VS Code. Planning mode, or as I like to call it 'Hannibal mode', extends GitHub Copilot's Agent Mode capabilities to handle larger, multi-step coding tasks with a structured approach. Instead of jumping straight into code generation, Planning mode creates a detailed execution plan. If you want more details, have a look at my previous post . Putting plan mode into action VS Code takes a different approach compared to Visual Studio when using plan mode. Instead of a configuration setting that you can activate but have limited control over, planning is available as a separate chat mode/agent: I like this approach better than how Visual Studio does it as you have explicit control when plan mode is activated. Instead of immediately diving into execution, the plan agent creates a plan and asks some follow up questions: You can further edit the plan by clicking on ‘Open in Editor’: ...

In our first post , we explored what MCP resources are and why they matter. In a second post , we learned how to use resources in VS Code. A third post followed where I showed the same in Visual Studio. Now it's time to build—let's create our own MCP resource server from scratch using C# and the official .NET SDK. By the end of this post, you'll have a working MCP server that exposes both static and dynamic resources, Setting up our project Let's start by creating a new console application and adding the necessary packages. Step 1: Create the Project Open your terminal and run: dotnet new console -n ProjectDocsServer cd ProjectDocsServer Step 2: Add Required Packages We need two NuGet packages: # Add the MCP SDK (currently in preview) dotnet add package ModelContextProtocol --prerelease # Add hosting support for dependency injection dotnet add package Microsoft.Extensions.Hosting The ModelContextProtocol package provides the core MCP server functio...

If you're using AI assistants in your development workflow, you've probably entered the same instructions dozens of times. What if I told you there's a better way? VS Code's custom prompt files let you create reusable, structured prompts with intellisense support—turning your ad-hoc AI interactions into a streamlined, professional workflow. What are Custom Prompt files? Custom prompt files are structured documents that define reusable prompts for AI assistants. Instead of manually typing out context, instructions, and tool configurations every time, you create a .prompt file that encapsulates everything in one place. Think of them as templates for your AI conversations—but with superpowers. Why superpowers? VS Code prompt files support a header section where you can define metadata and configuration, including: Tool specifications : Define which tools or capabilities the AI should have access to Context information : Set the stage with project-specif...

I want to start this blog post by stating that I have a new hero and his name is Stijn. Let me explain why… I recently upgraded an older .NET Full Framework application to the latest Application Insights NuGet package. This to make the switch from the obsolete instrumentationkey to the newer connectionstring approach. After upgrading our packages.config file (yes, this project is so old) looked like this: Looking good right? Unfortunately, the same could not be said about our telemetry itself as our Application Insights logs remained awfully empty. I doublechecked all the config files, reinstalled the nuget packages, tried to explicitly force to flush the telemetry data, everything I could think of I tried. But nothing worked. I handed the problem over to another team member (Stijn, my new hero) and he found the solution. After debugging the Application Insights code he arrived at a no-op method: This method should have all the logic to read the configuration information ...