<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Middleware on</title><link>https://eunus.dev/tags/middleware/</link><description>Recent content in Middleware on</description><generator>Hugo -- gohugo.io</generator><lastBuildDate>Thu, 02 Jul 2026 00:00:00 +0600</lastBuildDate><atom:link href="https://eunus.dev/tags/middleware/index.xml" rel="self" type="application/rss+xml"/><item><title>Model Context Protocol Series 2B — The Bridge Middleware That Lets Claude Debug and Fix Its Own Tools</title><link>https://eunus.dev/blog/model-context-protocol-series-2b-the-bridge-middleware-that-lets-claude-debug-and-fix-its-own-tools/</link><pubDate>Thu, 02 Jul 2026 00:00:00 +0600</pubDate><guid>https://eunus.dev/blog/model-context-protocol-series-2b-the-bridge-middleware-that-lets-claude-debug-and-fix-its-own-tools/</guid><description>Series 2A wired up the full OAuth 2.1 stack: discovery endpoints, mock Dynamic Client Registration, JWT validation, bearer token forwarding. Every piece of it works — right up until Claude Code opens the browser to log in, and OpenIddict slams the door:
error: invalid_request error_description: The specified 'redirect_uri' is not valid for this client application. This post is about the one component that fixes it — a single bridge middleware — and why it earns its own post: it is the piece nobody else builds, because almost everyone tests their MCP OAuth against a client that never triggers the problem.</description></item></channel></rss>