From 026a9dab7e5b4fbf49c01a929e43a81f731a5b15 Mon Sep 17 00:00:00 2001 From: Derek Tu Date: Mon, 11 May 2026 10:15:02 -0700 Subject: [PATCH 1/4] Add weekly update for 2026-05-11 Cover Redis topology support (standalone, cluster, Sentinel) for the embedded auth server's session storage, and Client ID Metadata Document (CIMD) support landing in the ToolHive CLI ahead of the embedded authorization server rollout. Co-Authored-By: Claude Opus 4.7 (1M context) --- blog/toolhive-updates/2026-05-11-updates.mdx | 66 ++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 blog/toolhive-updates/2026-05-11-updates.mdx diff --git a/blog/toolhive-updates/2026-05-11-updates.mdx b/blog/toolhive-updates/2026-05-11-updates.mdx new file mode 100644 index 00000000..7e04af02 --- /dev/null +++ b/blog/toolhive-updates/2026-05-11-updates.mdx @@ -0,0 +1,66 @@ +--- +title: + Run Redis the way your platform already runs it, and CIMD support in the CLI +sidebar_label: 'May 11: Redis flexibility and CIMD in the CLI' +description: + The embedded auth server now supports Redis standalone and Redis Cluster + alongside Sentinel, plus CIMD authentication in the ToolHive CLI. +--- + +This week, the embedded auth server's session storage works with whichever Redis +topology your platform already runs, and the ToolHive CLI gains Client ID +Metadata Document (CIMD) support for authenticating MCP clients to upstream +identity providers. + +{/* truncate */} + +## Run Redis the way your platform already runs it + +Session storage for the embedded authorization server previously required Redis +Sentinel. As of this release, the `MCPExternalAuthConfig` resource accepts three +Redis topologies: + +- **Standalone Redis** for simpler deployments where high availability isn't a + hard requirement. A single Redis instance with a password is enough. +- **Redis Cluster** for sharded deployments that scale horizontally across + multiple nodes. +- **Redis Sentinel** for HA with automatic failover (already supported, and + still the recommended default for production). + +Configure the `storage` block on your `MCPExternalAuthConfig` to match your +topology. See +[Redis session storage](/toolhive/guides-k8s/redis-session-storage#configure-mcpexternalauthconfig) +for the YAML and TLS examples. + +## CIMD support in the ToolHive CLI + +The ToolHive CLI (`thv`) now supports the +[Client ID Metadata Document](https://datatracker.ietf.org/doc/draft-parecki-oauth-client-id-metadata-document/) +(CIMD) approach for authenticating MCP clients to upstream identity providers. +Instead of going through dynamic client registration, which leaves stale client +entries in the IdP for clients that come and go, `thv` can present 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 client 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). From 772d2f22acea003b832034f9810dd3d33bfb9eb9 Mon Sep 17 00:00:00 2001 From: Derek Tu Date: Mon, 11 May 2026 10:19:45 -0700 Subject: [PATCH 2/4] Reframe weekly post around user outcomes Lead both sections with the user pain point and value: pluggable Redis topologies for platforms that don't run Sentinel, and dropping dynamic client registration churn via CIMD in the CLI. Reorder the title and description to match. Co-Authored-By: Claude Opus 4.7 (1M context) --- blog/toolhive-updates/2026-05-11-updates.mdx | 55 ++++++++++---------- 1 file changed, 27 insertions(+), 28 deletions(-) diff --git a/blog/toolhive-updates/2026-05-11-updates.mdx b/blog/toolhive-updates/2026-05-11-updates.mdx index 7e04af02..d979aed6 100644 --- a/blog/toolhive-updates/2026-05-11-updates.mdx +++ b/blog/toolhive-updates/2026-05-11-updates.mdx @@ -1,50 +1,49 @@ --- -title: - Run Redis the way your platform already runs it, and CIMD support in the CLI -sidebar_label: 'May 11: Redis flexibility and CIMD in the CLI' +title: Run on your existing Redis, and skip dynamic client registration +sidebar_label: 'May 11: Existing Redis topologies and CIMD' description: - The embedded auth server now supports Redis standalone and Redis Cluster - alongside Sentinel, plus CIMD authentication in the ToolHive CLI. + 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's session storage works with whichever Redis -topology your platform already runs, and the ToolHive CLI gains Client ID -Metadata Document (CIMD) support for authenticating MCP clients to upstream -identity providers. +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 */} -## Run Redis the way your platform already runs it +## Plug ToolHive into the Redis your platform already runs -Session storage for the embedded authorization server previously required Redis -Sentinel. As of this release, the `MCPExternalAuthConfig` resource accepts three -Redis topologies: +If your team standardizes on Redis Cluster for scale or a single standalone +Redis for simplicity, the embedded authorization server can now sit on top of +either, alongside the original Sentinel path: -- **Standalone Redis** for simpler deployments where high availability isn't a - hard requirement. A single Redis instance with a password is enough. -- **Redis Cluster** for sharded deployments that scale horizontally across - multiple nodes. -- **Redis Sentinel** for HA with automatic failover (already supported, and - still the recommended default for production). +- **Standalone Redis** for simpler operations when high availability isn't a + hard requirement. +- **Redis Cluster** for sharded scale-out across multiple nodes. +- **Redis Sentinel** for HA with automatic failover (still the recommended + default for production). -Configure the `storage` block on your `MCPExternalAuthConfig` to match your -topology. See +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. -## CIMD support in the ToolHive CLI +## Skip dynamic client registration with CIMD -The ToolHive CLI (`thv`) now supports the +If you've watched your IdP fill up with one-off client registrations for +short-lived MCP agents and developer environments, the ToolHive CLI (`thv`) now +lets you authenticate MCP clients without registering them first. It uses the [Client ID Metadata Document](https://datatracker.ietf.org/doc/draft-parecki-oauth-client-id-metadata-document/) -(CIMD) approach for authenticating MCP clients to upstream identity providers. -Instead of going through dynamic client registration, which leaves stale client -entries in the IdP for clients that come and go, `thv` can present a hosted -metadata document describing itself, and the IdP verifies it on the fly. +(CIMD) draft spec: `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 client registration to manage. + 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. From 7ea7436d0d2f78d17d38b68ca17a39b1966ed083 Mon Sep 17 00:00:00 2001 From: Derek Tu Date: Mon, 11 May 2026 10:44:51 -0700 Subject: [PATCH 3/4] Align titles across page and sections Update page title and section H2s to consistent product-focused wording: "Plug ToolHive into your existing Redis setup" and "ToolHive CLI now supports CIMD". Co-Authored-By: Claude Opus 4.7 (1M context) --- blog/toolhive-updates/2026-05-11-updates.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/blog/toolhive-updates/2026-05-11-updates.mdx b/blog/toolhive-updates/2026-05-11-updates.mdx index d979aed6..679ff3b4 100644 --- a/blog/toolhive-updates/2026-05-11-updates.mdx +++ b/blog/toolhive-updates/2026-05-11-updates.mdx @@ -1,6 +1,6 @@ --- -title: Run on your existing Redis, and skip dynamic client registration -sidebar_label: 'May 11: Existing Redis topologies and CIMD' +title: Plug ToolHive into your existing Redis setup, and CIMD in the CLI +sidebar_label: 'May 11: Existing Redis 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. @@ -12,7 +12,7 @@ authenticates MCP clients without dynamic client registration. {/* truncate */} -## Plug ToolHive into the Redis your platform already runs +## Plug ToolHive into your existing Redis setup If your team standardizes on Redis Cluster for scale or a single standalone Redis for simplicity, the embedded authorization server can now sit on top of @@ -31,7 +31,7 @@ match the topology you already run. See [Redis session storage](/toolhive/guides-k8s/redis-session-storage#configure-mcpexternalauthconfig) for the YAML and TLS examples. -## Skip dynamic client registration with CIMD +## ToolHive CLI now supports CIMD If you've watched your IdP fill up with one-off client registrations for short-lived MCP agents and developer environments, the ToolHive CLI (`thv`) now From f7f40d064a53c26c51c86921584381eb8c776525 Mon Sep 17 00:00:00 2001 From: Derek Tu Date: Tue, 12 May 2026 08:28:19 -0700 Subject: [PATCH 4/4] Address PR #864 review feedback - Update sidebar_label to "Redis flexibility" per @danbarr. - Soften the Redis section so Sentinel isn't positioned as the only production-ready topology; acknowledge managed Redis services that handle HA via standalone or cluster modes. - Lead the CIMD section with the upstream MCP spec shift from Dynamic Client Registration to CIMD. Co-Authored-By: Claude Opus 4.7 (1M context) --- blog/toolhive-updates/2026-05-11-updates.mdx | 34 ++++++++++++-------- 1 file changed, 20 insertions(+), 14 deletions(-) diff --git a/blog/toolhive-updates/2026-05-11-updates.mdx b/blog/toolhive-updates/2026-05-11-updates.mdx index 679ff3b4..bc22465c 100644 --- a/blog/toolhive-updates/2026-05-11-updates.mdx +++ b/blog/toolhive-updates/2026-05-11-updates.mdx @@ -1,6 +1,6 @@ --- title: Plug ToolHive into your existing Redis setup, and CIMD in the CLI -sidebar_label: 'May 11: Existing Redis 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. @@ -14,15 +14,16 @@ authenticates MCP clients without dynamic client registration. ## Plug ToolHive into your existing Redis setup -If your team standardizes on Redis Cluster for scale or a single standalone -Redis for simplicity, the embedded authorization server can now sit on top of -either, alongside the original Sentinel path: +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 operations when high availability isn't a - hard requirement. -- **Redis Cluster** for sharded scale-out across multiple nodes. -- **Redis Sentinel** for HA with automatic failover (still the recommended - default for production). +- **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 @@ -33,12 +34,17 @@ for the YAML and TLS examples. ## ToolHive CLI now supports CIMD -If you've watched your IdP fill up with one-off client registrations for -short-lived MCP agents and developer environments, the ToolHive CLI (`thv`) now -lets you authenticate MCP clients without registering them first. It uses the +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) draft spec: `thv` presents a hosted metadata document describing itself, -and the IdP verifies it on the fly. +(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: