AI

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。

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 則是捲起袖子「實際動手做」。

Date: 2026.07.01 Event: 2026 Cloud Summit Taiwan Speaker: appleboy

This time last year, the question we were asking was “how can AI help us improve our productivity?” This year, the question has flipped: “how can we help AI so that it accelerates our work?” Swapping the subject and the object sounds like wordplay, but it is exactly the most fundamental mindset shift we went through over these two years of rolling out AI Agentic Coding across the company.

This article documents a road we actually traveled: from a handful of people quietly trying out Claude Code, to everyone in the company using it daily; from AI producing 66% of our output, all the way up to 97%; from engineers’ three wait-and-see attitudes — “I don’t trust it, I’m afraid of being replaced, I’m worried about security” — to letting results speak for themselves and packaging individual tricks into standardized Agent Skills; from every team writing its own MCP Server and triggering a project explosion, to pulling the security governance of the whole ecosystem back together with a unified authentication gateway and a Marketplace review process.

Three parts, in the order we actually lived through them: the full picture and the results of this year → from the sidelines to everyone on board → workflow integration and security governance.

日期：2026.07.01 活動：2026 Cloud Summit 台灣雲端大會 講者：appleboy

去年這個時候，我們在想的是「AI 怎麼協助我們改善工作效率」；今年，問題反過來了——「我們該怎麼協助 AI，讓它加速我們的工作」。主詞和受詞對調，聽起來像文字遊戲，但這正是這兩年公司內部 AI Agentic Coding 導入路上，最核心的一次心態轉變。

這篇文章記錄的是一段真實走過的路：從少數人偷偷試用 Claude Code，到全公司日常使用；從 AI 產出佔比 66%，一路衝到 97%；從工程師「不信任、怕被取代、擔心資安」的三種觀望心態，到用成果說話、把個人技巧封裝成標準化的 Agent Skill；從每個團隊各自寫 MCP Server 導致的專案爆炸，到用統一認證閘道與 Marketplace 審查機制把整個生態圈的資安治理收攏起來。

三個部分，跟著我們真實走過的順序：這一年的全貌與成果 → 從觀望到全員 → 流程整合與安全治理。

Once MCP (Model Context Protocol) exploded inside the company, almost every team ended up running an MCP server or two of their own: one fronting Gitea, one for Sentry, one for the internal Wiki, one for a database. They’re genuinely useful — but there’s a question everyone collectively ignored: how do these MCP servers actually authenticate?

The answer is usually unsettling: each one collects its own PAT (Personal Access Token). Every MCP server defines its own token, stuffs it into an environment variable, and validates it itself. So the company quietly accumulates a pile of static tokens — “long-lived, sitting in a file, equivalent to someone’s account” — scattered across dev machines, CI, even pasted into Slack messages. This post is about using Kong together with Signet to put a single OAuth2 front door in front of every MCP server and clean up that PAT sprawl in one move.

The full example code lives in appleboy/kong-mcp-oauth2. This post walks through the motivation, the architecture, the security considerations, and the actual verification steps.

MCP（Model Context Protocol） 在公司內部爆量之後，幾乎每個團隊都自己跑了一兩個 MCP Server：接 Gitea 的、接 Sentry 的、接內部 Wiki 的、接資料庫的。它們很好用，但有一個被集體忽略的問題——這些 MCP Server 到底是怎麼認證的？

答案多半令人不安：各自收各自的 PAT（Personal Access Token）。每個 MCP Server 自己定義一套 token、自己塞進環境變數、自己驗。於是公司內部出現了一堆「長期有效、放在檔案裡、等同某個帳號權限」的靜態 token，散落在開發機、CI、甚至貼在 Slack 訊息裡。這篇文章要談的，就是怎麼用 Kong 搭配 Signet，在所有 MCP Server 前面架起單一的 OAuth2 入口，把這堆 PAT 一次收掉。

完整的範例程式碼在 appleboy/kong-mcp-oauth2，本文會帶你走過設計動機、架構、安全考量到實際驗證。

More and more developers let AI CLI tools like Claude Code run commands, look things up, and tidy up afterwards right on their own development machines. Wiring that AI workflow into Jira makes it even more powerful: the AI can look up issues, update statuses, leave comments, and map commit messages back to tickets. The star of this post, go-jira (https://github.com/appleboy/go-jira), is a Jira CLI built for exactly this scenario. But there’s a security question that keeps getting underrated — how does the CLI authenticate to Jira?

The most common answer historically is a PAT (Personal Access Token). It’s simple, but on an AI development machine it carries two very real risks:

1. The AI can read it by accident. A PAT usually lives in .env, a shell rc file, or some config file. The moment you let an AI agent “freely explore the filesystem” on that machine, this long-lived token — which carries your full account permissions — can get pulled into the context, or even written out into some piece of output.
2. A file that lives forever is an exposure surface that lives forever. A PAT doesn’t rotate. Once leaked, it stays valid until you manually revoke it. We’ve all heard the stories: synced to the cloud, swept into a backup, accidentally committed into a repo.

That’s why “switching CLI auth from a PAT to Jira OAuth” has been pulled back into the spotlight lately. This post documents how the new go-jira uses OAuth Login + refresh tokens to tuck tokens into the operating system’s Keyring, so developers can obtain a token conveniently and store it safely — and so AI CLIs like Claude Code can interact with Jira in a much safer way.

Note: go-jira’s OAuth only supports Jira Data Center, not Jira Cloud (the two use different OAuth flows).

越來越多開發者習慣在自己的開發機上，讓 Claude Code 這類 AI CLI 工具幫忙跑指令、查資料、收尾善後。把這條 AI 工作流接到 Jira 之後，威力更大：AI 可以幫你查 issue、更新狀態、補留言、把 commit 訊息對應到工單。本文的主角 go-jira（https://github.com/appleboy/go-jira）正是為了這個場景打造的 Jira CLI。但這裡有一個一直被低估的安全議題——CLI 要怎麼跟 Jira 認證？

過去最常見的做法是 PAT（Personal Access Token）。它確實簡單，但放在 AI 開發機上有兩個很實際的風險：

1. AI 可能不小心讀到它：PAT 通常被塞在 .env、shell rc、或某個設定檔裡。當你讓 AI agent 在這台機器上「自由探索檔案」時，這顆等同你帳號權限的長期 token 很可能就被讀進 context、甚至被寫進某段輸出裡。
2. 以檔案形式長期存在 = 長期暴露面：PAT 不會自動輪替，一旦外洩，在你手動撤銷之前它都是有效的。檔案被同步到雲端、被備份、被誤 commit 進 repo 的故事，大家都聽過。

所以「把 CLI 認證從 PAT 換成 Jira OAuth」這件事，最近被重新拉出來重視。這篇文章記錄 go-jira 新版本如何用 OAuth Login + Refresh Token 把 token 收進作業系統的 Keyring，讓開發者很方便地拿到、並且安全地保存 token，進而讓 Claude Code 等 AI CLI 能以更安全的方式跟 Jira 互動。

注意：go-jira 的 OAuth 只支援 Jira Data Center，不支援 Jira Cloud（兩者是不同的 OAuth 流程）。