MCP 2026-07-28 is not a minor release that merely renames fields. It moves the protocol core from “establish a bidirectional session, then exchange messages inside it” toward a model that better fits Web infrastructure: each request is self-describing, independently routable, and explicitly cacheable; interactions and long-running work have clear protocol contracts. This directly addresses common production problems: sticky routing, rolling deployments, gateways that cannot inspect bodies, retrying after disconnects, and OAuth trust boundaries.

This article draws on the official release announcement, changelog, specification, Go SDK v1.7.0, and nine executable examples in go-training/mcp-2026-07-28. Their roles differ: the specification defines wire semantics, the SDK defines the public Go API, and the examples and tests only demonstrate the behavior they cover. Tasks in particular are standardized in the specification, while v1.7.0 does not yet provide a complete typed API.

By the end, you should be able to answer four questions: how MCP becomes easier to scale horizontally, how to complete an interaction without a session, what a gateway can safely observe, and which layer server, client, and platform owners should migrate first.

For hands-on verification, refer to the training examples for 01 Stateless, 02 Subscriptions, 03 MRTR, 04 Cache, 05 HTTP headers, 06 Deprecations, 07 MCPGODEBUG, 08 Authorization, and 09 Extensions / Tasks.

MCP 2026-07-28 不是一次把欄位改名的小改版。它把協定核心從「先建立雙向 session，再在裡面交換訊息」改為更接近 Web 基礎設施擅長處理的模式：每個 request 自我描述、可獨立路由、可明確快取，互動與長工作則有明確的 protocol contract。這正好處理 production 最常見的麻煩：sticky routing、滾動部署、gateway 看不懂 body、斷線重試與 OAuth 信任邊界。

本文以官方 release announcement、changelog 與 specification、Go SDK v1.7.0，以及可執行的 go-training/mcp-2026-07-28 九組範例為依據。三者的角色不同：規格定義 wire semantics，SDK 定義公開 Go API，範例與測試只證明它實際覆蓋的行為；尤其 Tasks，規格已正式化，但 v1.7.0 尚未有完整 typed API。

讀完你應該能回答四件事：怎麼讓 MCP 更容易水平擴展、怎麼在無 session 下完成互動、gateway 能安全觀察什麼，以及 server、client、platform 各自該先遷移哪一層。

想邊讀邊驗證，可直接對照教材的 01 Stateless、02 Subscriptions、03 MRTR、04 Cache、05 HTTP headers、06 Deprecations、07 MCPGODEBUG、08 Authorization 與 09 Extensions / Tasks。

In the 2026-07-28 Authorization spec announcement, MCP shipped a batch of authorization-hardening changes in one go: RFC 9207 issuer validation is now mandatory, client credentials are bound to the issuer that minted them (no reuse across authorization servers), and — the headline item — Dynamic Client Registration (DCR) is formally deprecated in favor of CIMD (Client ID Metadata Documents). DCR stays functional for backward compatibility for at least 12 months, but the direction is set: a future version will remove it.

Half a year ago I wrote Introduction to OAuth Client ID Metadata Document (CIMD), covering the three pain points CIMD solves (pre-registration doesn’t scale, DCR’s unbounded client database and self-asserted trust problem, and MCP’s “no pre-existing relationship” scenario). That was the concept piece; now that the spec has put CIMD front and center, it’s time for the hands-on companion — running a complete CIMD authorization flow end to end, watching an HTTPS URL travel all the way into the client_id claim of an access token.

This post takes apart the 03-oauth-mcp/cimd sample from go-training/mcp-workshop: two runnable Go programs (cimd-client, cimd-server) with Signet as the authorization server — from minting a local certificate with mkcert, publishing the client metadata document, Authorization Code + PKCE, RFC 9207 iss validation, to finally calling the MCP who_am_i tool with a Bearer token. And as a bonus: swapping the OAuth client for Claude Code itself, logging in against the CIMD URL with claude mcp add.

MCP 官方在 2026-07-28 版的 Authorization 規範公告中，一口氣做了幾件授權強化（authorization hardening）的大事：RFC 9207 issuer 驗證成為必須、client 憑證綁定發行它的 issuer 不得跨 AS 重用，以及最重要的一項——Dynamic Client Registration（DCR）正式棄用（deprecated），由 CIMD（Client ID Metadata Documents）接手成為標準做法。DCR 還會為了向下相容保留至少 12 個月，但方向已經定了：未來版本會把它移除。

半年前我寫過一篇 《OAuth Client ID Metadata Document (CIMD) 簡介》，把 CIMD 要解決的三個痛點（預先註冊不可行、DCR 的無界資料庫與自我宣告信任問題、MCP「毫無前置關係」的場景）講完了。那是概念篇；現在官方直接把 CIMD 推上正桌，是時候補上實戰篇——親手把一條完整的 CIMD 授權流程跑起來，看著一個 HTTPS URL 一路變成 access token 裡的 client_id。

這篇拆解的是 go-training/mcp-workshop 的 03-oauth-mcp/cimd 範例：兩個能跑的 Go 程式（cimd-client、cimd-server）搭配 Signet 當授權伺服器，從 mkcert 簽本機憑證、發佈 client metadata document、Authorization Code + PKCE、RFC 9207 iss 驗證，到最後帶著 Bearer token 呼叫 MCP 的 who_am_i 工具。最後再加碼：把 OAuth client 換成 Claude Code 本人，用 claude mcp add 直接對著 CIMD URL 登入。

The previous post, When an MCP Client Trusts Multiple Authorization Servers: Stopping Mix-Up Attacks with RFC 9207, laid out the theory thoroughly: how the authorization-server mix-up attack works, why neither state nor PKCE stops it, and why RFC 9207’s iss parameter is the missing piece. But understanding the concept is one thing. Watching a valid authorization code get stolen and minted into a real access token is another thing entirely.

This is the hands-on companion. I take the 03-oauth-mcp/issuer-identification sample from go-training/mcp-workshop apart piece by piece: a malicious authorization server (evil-as), an MCP client that hand-rolls its OAuth flow, and an honest MCP resource server — three real Go programs you can actually run. You’ll trigger the attack yourself and watch the attacker’s terminal print STOLEN ACCESS TOKEN; then add one -defense flag and watch the same attack get cut off — by an iss comparison — before it does any harm.

前一篇 《當 MCP Client 同時信任多個授權伺服器：用 RFC 9207 堵住 Mix-Up 攻擊》把「授權伺服器 Mix-Up 攻擊」的原理、為什麼 state 和 PKCE 都擋不住它、以及 RFC 9207 的 iss 參數為什麼是那塊缺角，講得很完整。但概念看懂是一回事，親眼看到一顆合法的 authorization code 被攻擊者攔走、換成一顆真的 access token，又是另一回事。

這篇是它的實戰版。我把 go-training/mcp-workshop 的 03-oauth-mcp/issuer-identification 範例整套拆開來講：一個惡意授權伺服器（evil-as）、一個手工實作 OAuth 流程的 MCP client、一個誠實的 MCP resource server，三個真的能跑起來的 Go 程式。你可以親手把攻擊跑一遍，看著攻擊者的終端機印出 STOLEN ACCESS TOKEN；再加一個 -defense 旗標，看著同一個攻擊在造成損害前被 iss 比對擋下來。

The MCP (Model Context Protocol) Authorization spec rides on standard OAuth 2.1: the MCP Server is the Resource Server, the MCP Client is the OAuth Client, and behind them sits one or more Authorization Servers (AS). The most elegant — and most easily overlooked — property of this design is that a single MCP Client can talk to multiple authorization servers at once. The spec says it in black and white: the authorization_servers field of the Protected Resource Metadata “can define multiple authorization servers,” and “the responsibility for selecting which authorization server to use lies with the MCP client.”

Once “one client, many ASes” becomes the norm, an attack that barely exists in the single-AS world surfaces: the authorization server mix-up attack. This post walks through how the attack works, why the IETF wrote a dedicated RFC — RFC 9207 — just for it, and how to implement it in an OAuth 2.0 authorization server (including an issuer-inconsistency bug the implementation surfaced).

MCP（Model Context Protocol） 的 Authorization 規範 走的是標準 OAuth 2.1 那一套：MCP Server 當 Resource Server、MCP Client 當 OAuth Client、背後再接一個或多個 Authorization Server（以下簡稱 AS）。這套設計最漂亮、也最容易被忽略的一個特性是——同一個 MCP Client 可以同時對接多個授權伺服器。MCP 規範裡白紙黑字寫著：Protected Resource Metadata 的 authorization_servers 欄位「可以定義多個授權伺服器，由 MCP Client 自己決定要用哪一個」。

一旦「一個 client、多個 AS」成為常態，一種在單一 AS 世界裡幾乎不存在的攻擊就浮上檯面了：授權伺服器 Mix-Up 攻擊（AS mix-up attack）。這篇文章要談的，就是這個攻擊怎麼運作、為什麼 IETF 要為它單獨立一份 RFC 9207，以及在一台 OAuth 2.0 授權伺服器上要怎麼把它實作起來（附上我實作時踩到的一個 issuer 不一致 bug）。

On July 1, 2026, I ran a 90-minute hands-on LAB workshop at iThome Cloud Summit Taiwan: “When AI Can Already Write Code — Building Your AI Workflow”. This article walks through the core content and hands-on exercises from that day, so friends who couldn’t make it can follow along and run through it themselves, and attendees have a set of notes to come back to.

On the same day I also gave a conference talk about our complete two-year journey of adopting AI Agentic Coding — the recap is here: From Watching on the Sidelines to Company-Wide Adoption: Two Years of AI Agentic Coding in Practice. That talk covered the “why and how to drive adoption”; this LAB was about rolling up our sleeves and actually doing it.

2026 年 7 月 1 日，我在 iThome 臺灣雲端大會（Cloud Summit Taiwan）帶了一場 90 分鐘的 LAB 實戰工作坊：「當 AI 已經能寫 code——打造你的 AI 工作流」。這篇文章整理當天的核心內容與動手練習，讓沒能到場的朋友也能照著跑一次，也給參加過的朋友一份可以回頭查的筆記。

同一天我還有一場議程演講，聊的是兩年 AI Agentic Coding 導入的完整歷程，回顧文在這裡：從觀望到全公司落地：兩年 AI Agentic Coding 導入實戰。那場講「為什麼與怎麼推」，這場 LAB 則是捲起袖子「實際動手做」。