Merge branch 'main' into groups

Author: cliffhall

blog/content/posts/2025-11-25-first-mcp-anniversary.md

@@ -161,9 +161,9 @@ Tasks are launching as an **experimental capability**, meaning that it's part of
 
 One of the top painpoints from the community when it comes to authorization has been [Dynamic Client Registration](https://www.rfc-editor.org/rfc/rfc7591), or DCR. This capability is needed because in the MCP world there is an unbounded number of clients and servers, so doing standard client pre-registration is not always feasible. You wouldn't expect every MCP client in the world to also have a client registration with every Authorization Server (AS) out there, so DCR was used as a solution to this problem. You can learn more about the current approach in our [authorization guide](https://modelcontextprotocol.io/docs/tutorials/security/authorization).
 
-To use DCR, however, a MCP server developer would need to rely on an AS that allows clients to register themselves via a public API. If the AS doesn't support this capability, developers would now need to build an OAuth proxy that would be manually registered with the AS, and support Dynamic Client Registration itself, mapping its own issued tokens to tokens issued from the downstream AS. This is a complex, time-consuming, and error-prone task, and doesn't actually solve the fundamental problems with Dynamic Client Registration.
+To use DCR, however, an MCP server developer would need to rely on an AS that allows clients to register themselves via a public API. If the AS doesn't support this capability, developers would now need to build an OAuth proxy that would be manually registered with the AS, and support Dynamic Client Registration itself, mapping its own issued tokens to tokens issued from the downstream AS. This is a complex, time-consuming, and error-prone task, and doesn't actually solve the fundamental problems with Dynamic Client Registration.
 
-The alternative would be for every customer or end user to provide _their own_ client registration, but that's just trading one complex task for another. In that model, when a user connects to a MCP server, they need to go through their IT team to create a registration, assign it the right permissions, and then configure the MCP client to use it.
+The alternative would be for every customer or end user to provide _their own_ client registration, but that's just trading one complex task for another. In that model, when a user connects to an MCP server, they need to go through their IT team to create a registration, assign it the right permissions, and then configure the MCP client to use it.
 
 **[SEP-991](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1296)** introduced a much more elegant solution to the problem - URL-based client registration using [OAuth Client ID Metadata Documents](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00) (you might've already seen our [blog post on this change from earlier this year](https://blog.modelcontextprotocol.io/posts/client_registration/)). Clients can now provide their own client ID that is a URL pointing to a JSON document the client manages that describes properties of the client.