caffeinate

This article was originally published on the Agentic AI Foundation blog.

You don't need to fully understand how MCP works to feel how useful it is: add an MCP server to a compatible client and presto! – your agent gets new capabilities.

The ability to "paste a URL and go" is more foundational than it may appear. MCP's big vision is that clients and servers that have never met can talk to each other. A client developer shouldn’t need to build a custom integration for every server, and a server operator shouldn’t need to pre-register every client. Clients and servers can be strangers. The protocol gives strangers a shared way to connect, even when access still requires signing in, consent, or approval.

I'll call these open-world integrations: connections where the client and server don't need a pre-existing relationship.

This vision is sometimes misunderstood, because not all MCP servers actually need to handle clients that are strangers! In this post, I'll explain why MCP works this way, when MCP builders do (and don't) need to care, and what it means for the core protocol.

Model Context Protocol has had an incredible run over the past two years. If you build software (or just use it), you've no doubt heard about MCP. You may have connected an agent like Cursor or Claude Code to an MCP server to give it new abilities.

Many videos and posts describe the what of MCP, and the reasons it's exciting. But developers I talk to are often confused about the why and how: Is MCP just a special kind of API? Why do we need a new API for agents, anyway? Can't agents just call regular APIs? Why does MCP drag OAuth and all its jargon into the picture?

In this post, I'll break down the why and how of MCP in plain English. You don't need to have a background in agents or models to follow along.

TL;DR — Because of how they work, AI models (LLMs) need an API to reach the outside world via your application code. MCP standardizes how your application code does this, so you can reuse integrations instead of writing each one yourself.

If you haven't heard, Model Context Protocol is getting a big update this month. The core protocol is changing, and servers will need to be updated to support it.

With a breaking protocol change arriving, it's more important than ever to test your servers against the official spec. And to make the test-and-fix loop even faster inside coding agents, MCP Debugger is now an MCP server itself. 🚀

My talk OAuth 2.0 and OpenID Connect in Plain English recently crossed two million views on YouTube. I never expected it to be watched by so many people!

When I first started working in security and identity, I remember feeling buried under jargon: resource server, authorization server, scopes, JWKS, PKCE, ID tokens, access tokens. It was hard to build a mental picture of what was actually happening and how the pieces related to each other.

I've spent the past year deep in the hardest parts of Model Context Protocol: authorization flows, security, and real client behavior. I keep seeing the same failure patterns over and over. Subtle bugs, runtime failures, and broken auth flows trip up even the best teams.

There's a huge gap today between a server that "implements MCP" and one that clients can actually use. If you've ever wired up an MCP server and wondered why your agent can't use it properly, you're not alone!

I got tired of debugging these problems by hand, so I built MCP Debugger to do it for me.

Last year, I published The Little ASP.NET Core Book, a friendly and free introduction to web programming. The book is published under a Creative Commons license, and the source is freely available on Github.

People from all over the world have read it to learn how to build modern web applications, or just to brush up on what's new in ASP.NET Core 2.0.

Today, I'm releasing an updated version that adds brand-new content and incorporates many suggestions from readers. Keep reading to learn more, or download a copy!

The OAuth 2.0 and OpenID Connect protocols are used all over the web. Big platforms like Google and Facebook use them extensively for both authorization and social login (the ubiquitous Facebook Login button). These protocols are powerful, but unfortunately they aren't always easy to use.

If you've ever struggled to set up OAuth or OpenID Connect, you're not alone! I got so tired of fighting with bad requests and cryptic responses that I decided to write a tool to make it easier.

It's been over two months since I released the Little ASP.NET Core Book, and I've been blown away by the response!

"This looks great. I've been learning ASP.NET Core with scattered resources around the web, and your book seems to explain everything in a simple way." - aesthetics1 on HackerNews

I've been excited to see people downloading and tweeting about the book, but I'm even more excited to see people forking the content, adding suggestions, and translating it to other languages.

Today I'm excited to release my side project for the last few months: the [Little ASP.NET Core Book](/book)!

This free book is a short introduction to the ASP.NET Core 2.0 web framework. If you've never built apps in C# or ASP.NET (or even if you have!), this book will teach you the basics of building modern, fast web applications using ASP.NET Core.

Get a free copy on the book page!

The console (terminal) on Windows has come a long way since command.com. PowerShell might seem weird at first if you're used to bash on *nix, but it's grown into a very powerful console and scripting tool.

Over the years, I've gathered a list of my favorite plugins and tweaks to make PowerShell and the console even better. In this post, I'll show you how to customize PowerShell on Windows 10 for an awesome console experience.

I'm a big fan of the async/await pattern introduced in C#. It's one of the best ways to reason about asynchronous code, and it's spreading to Python and JavaScript too.

Every once in a while, I need to run some async code in a .NET command-line application, but the Console Application template in Visual Studio makes it annoyingly difficult to do.

A web API that returns JSON responses should be expected to return errors or exceptions as JSON messages, too. You can use exception filters in ASP.NET Core MVC to trap and serialize exceptions that occur within MVC. However, if an exception is thrown before (or after) the MVC pipeline, it won't be handled by the filter and the client will get an ugly error message (or a 500 Internal Server Error).

A more universal solution that can trap and serialize any exception that happens during a request is an exception handling middleware component. The syntax is a little different than an exception filter, but the principle is the same.

In this post, I'll show you how to write error handling middleware and how to extend it with custom behavior.

JSON is by far the most popular response format for APIs today. It's not hard to see why: it's easy for both humans and machines to read. Virtually all platforms and devices can read and write JSON, making it nearly as ubiquitous as HTML. JSON is unstructured and "squishy", which makes it easy to model dynamic responses. (Maybe a little too easy.)

If you're building an API, especially one with more than a few endpoints, you'll likely want to adopt a schema or pattern for your responses. This could be as simple as one or two common response properties, or it could be a complex message envelope. Unlike XML, JSON doesn't have a built-in way of defining a document schema (the downside of being unstructured and squishy).

There are a few popular ways to add schemas to JSON, but they all have drawbacks. In this post, I'll examine some of those drawbacks, and show you how to use Ion to create intuitive, beautiful REST APIs.

HATEOAS, or Hypermedia as the Engine of Application State, is a complicated-sounding term for a simple idea:

A client interacts with a REST API entirely through the responses provided dynamically by the server.

Put even more simply:

You shouldn't need any documentation or out-of-band information to use a REST API.

This may sound odd, because the first stop for any developer working with a new API is the documentation. How could you interact with an unfamiliar API without any out-of-band information?

You typically need to read API docs to understand:

• What endpoints are available
• How requests are structured
• What responses to expect

One of the distinguishing features of the REST architecture is this idea that the responses themselves should tell you what you can do and how you can do it. This is HATEOAS in a nutshell, although it could also be referred to as "discoverability".

I use Atom and Notepad++ for most text editing tasks on Windows, but occasionally I'll drop down to good, trusty Notepad. It loads fast and handles bare-bones editing tasks without much fuss. However, I found it annoying that there was no shortcut to quit Notepad other than Alt-F4, which feels awkward on my keyboard. Why can't I use Ctrl-W?

Ctrl-W has a long history: it's always been the shortcut to close Windows Explorer (folder) windows. When tabbed browsing came onto the scene, it became the de facto shortcut for closing browser windows and tabs. It's downright muscle memory for me at this point.

I see Notepad when I do git commit, thanks to GitPad. My muscle memory tries to type a message and press Ctrl-W to close the window, so why fight it?

It turns out it's easy to add the missing keyboard shortcut. I created a simple AutoHotkey script:

The script works by listening for Ctrl-W in any active Notepad.exe window, and remapping it to Alt-F4.

I put a shortcut to the .ahk file in my Windows Start Menu Startup folder (yes, that still exists!), and now I can use my keyboard muscle memory without fail.

shoutcloud.io is a hilarious parody of software-as-a-service offerings that provides All Caps as a Service. If you aren't happy with the uppercasing function built into your language of choice, you can make an (absolutely spurious) HTTP request to API.SHOUTCLOUD.IO/V1/SHOUT and get back a shoutier version of any string.

Shoutcloud proudly states that they have libraries for "leading webscale platforms" like Node, Ruby, and Go. Sadly, they seem to have left out the .NET stack. What's a responsible .NET developer to do?

Have no fear: Shoutcloud.NET is here. If you aren't happy with string.ToUpper(), and want to do things over HTTP for no reason, this library is for you!

Install it via the Package Manager GUI, or the console:

PM> install-package Shoutcloud.NET

Then, make HTTP requests to get uppercased strings thousands of times slower than native code:

Of course, there's full compatibility with the TPL: UPCASE returns an awaitable Task, and takes an optional CancellationToken parameter. (You may be shouting, but you're not a barbarian!)

The library is compatible with these platforms:

• .NET framework 4.5.1 and higher
• DNX (full) 4.5.1 and higher
• DNX (CoreCLR, dotnet) 5.4 and higher

The source code is on Github. Happy shouting!