Add weekly update for 2026-05-11

blog/toolhive-updates/2026-05-11-updates.mdx

@@ -0,0 +1,71 @@
+---
+title: Plug ToolHive into your existing Redis setup, and CIMD in the CLI
+sidebar_label: 'May 11: Redis flexibility and CIMD in the CLI'
+description:
+  Run the embedded auth server on whichever Redis your platform already uses,
+  and authenticate MCP clients without per-client registration via CIMD.
+---
+
+This week, the embedded auth server runs on the Redis topology your platform
+already uses (standalone, cluster, or Sentinel), and the ToolHive CLI
+authenticates MCP clients without dynamic client registration.
+
+{/* truncate */}
+
+## Plug ToolHive into your existing Redis setup
+
+Whether your platform runs a managed Redis service (which typically handles HA
+transparently) or self-hosts Redis in one of several topologies, the embedded
+authorization server can now sit on top of it:
+
+- **Standalone Redis** for simpler deployments, including managed Redis services
+  that handle high availability for you.
+- **Redis Cluster** for sharded scale-out across multiple nodes, common in both
+  managed and self-hosted deployments.
+- **Redis Sentinel** for HA with automatic failover when you self-host Redis
+  directly.
+
+No more shoehorning a Sentinel topology into a cluster that doesn't otherwise
+need it, or skipping the embedded auth server because your standard Redis
+doesn't match. Configure the `storage` block on your `MCPExternalAuthConfig` to
+match the topology you already run. See
+[Redis session storage](/toolhive/guides-k8s/redis-session-storage#configure-mcpexternalauthconfig)
+for the YAML and TLS examples.
+
+## ToolHive CLI now supports CIMD
+
+The MCP authentication spec is shifting from Dynamic Client Registration (DCR)
+to the
+[Client ID Metadata Document](https://datatracker.ietf.org/doc/draft-parecki-oauth-client-id-metadata-document/)
+(CIMD) pattern as the preferred way for clients to identify themselves to
+upstream identity providers. The ToolHive CLI (`thv`) now supports CIMD, so your
+clients stay aligned with the upstream direction.
+
+If you've watched your IdP fill up with one-off client registrations for
+short-lived MCP agents and developer environments, this is a direct fix. Instead
+of registering each client with the IdP up front, `thv` presents a hosted
+metadata document describing itself, and the IdP verifies it on the fly.
+
+Use it when:
+
+- You're running a short-lived or stateless MCP client and don't want a
+  permanent registration to manage.
+- You want to identify a class of clients (for example, every developer on your
+  team) without registering each one individually.
+- Your IdP supports the draft CIMD spec.
+
+Support for CIMD in the embedded authorization server is still in development;
+this release lands it in the local CLI experience first.
+
+## Getting started
+
+For detailed release notes, check the project repositories:
+
+- [ToolHive Runtimes](https://github.com/stacklok/toolhive/releases) (CLI and
+  Kubernetes Operator)
+- [ToolHive Desktop UI](https://github.com/stacklok/toolhive-studio/releases)
+- [ToolHive Cloud UI](https://github.com/stacklok/toolhive-cloud-ui/releases)
+- [ToolHive Registry Server](https://github.com/stacklok/toolhive-registry-server/releases)
+
+You can find all ToolHive documentation on the
+[Stacklok documentation site](/toolhive).