I’ve contributed to the Model Context Protocol (MCP) since the earliest days, starting with our proposal for User Interaction when we saw people in the community talking about the need to bridge text-based AI with actionable systems. That’s what we’d spent a year building in-house at Arcade.dev, and we were excited to contribute to the open standard and help securely accelerate the adoption of real production agents across systems, vendors, and applications.
At the same time, I kept an eye on the basic authentication and authorization stories, helping contribute to the large directions of various improvements, and authoring other small improvements of my own.
My biggest individual contribution was URL mode elicitation, which became the basis for secure tool authorization from a downstream MCP server. It lets MCP servers pause tool execution to interact directly with the user. In a secure, external browser, you can complete sensitive actions, preventing data like passwords, payment info, or OAuth tokens from passing through the client or LLM context. It was one piece of the larger MCP puzzle, but an important one, and I’m proud of it.
My contribution to this upcoming release is less flashy but will have a real impact on how agents work in production. It clarifies how MCP clients should handle refresh tokens.
What a refresh token actually does
When an MCP client like Claude Code or Cursor connects to an MCP server, it has to authenticate and get authorized. The client receives an access token, and that token stays short-lived by design. It might last 15 minutes, maybe an hour.
That’s a critical security practice, but you also don’t want a user signing in again every 15 minutes. That experience is miserable. So alongside the access token, the client receives a refresh token, which it uses to quietly get new access tokens without pulling the user back in.
Why clients were handling refresh tokens inconsistently
While building MCP capabilities at Arcade I kept watching clients handle refresh tokens differently. Some weren’t using refresh tokens at all. Some never requested a refresh token, which meant our runtime never issued them one. The result was inconsistent behavior across the ecosystem.
The standards MCP authentication builds on, mainly OAuth, already document this behavior well, but MCP itself stayed relatively quiet on what refresh token behavior should look like in its own environment. I suspected this silence was the cause of the inconsistent behavior. Without clear guidance in the spec for people or agents to read, clients drifted.
What changes about refresh tokens in this MCP release
My thinking was straightforward: carry the established refresh token guidance from OAuth and OpenID Connect into MCP and write it down plainly, so anyone reading the spec, whether a casual observer, an auth expert, or a coding agent generating an implementation, lands on the right behavior more often.
This matters because MCP is open, and interoperability is the entire point. When the behavior isn’t written down, consistency gets left to chance.
The gap only shows up in production
Refresh tokens are the kind of problem that hides during a demo. The first time you connect, everything works. You sign in, the tool call succeeds, you close the laptop. The refresh token doesn’t matter yet. Then you open the laptop the next morning, the client needs that refresh token, and it breaks. It worked yesterday and fails today.
That distance between the demo and the day after is exactly where we focus at Arcade. A new tool can break in the most mundane, frustrating ways. Roll it out, tell employees to use it, and the moment someone can’t log back in, you’ve lost them. The refresh token is one part of the security story, but an important one.
What interoperability means for the enterprise
For an enterprise, this clarification shows up as consistency. You can build an MCP server, maintain one, or buy one, then connect to it from any client your organization allows, and the authentication, the user experience, and the security behavior stay the same. Most companies run a mix: many clients and many servers, deployed across many teams. Interoperability keeps that mix coherent, which is one reason why MCP is so powerful as a standard.
On the governance side, that means one consistent security story across every touch point. On the experience side, it means nobody gets asked to type a password more than once and single sign-on works the way it should. Both depend on refresh tokens behaving correctly.
This release is about making MCP work in production
Plenty of people in the OAuth world were already doing this correctly. However, many people building on MCP haven’t come from OAuth or OpenID Connect, and a lot of the implementation runs through coding agents. Putting best practice directly in front of them is the point.
This wasn’t so much an oversight from the previous release as it was something people didn’t think about while MCP was mostly demos, when the question was “does this work today?” instead of “will this hold up in production?” That question has shifted. MCP is here to stay. That’s settled. We’re in production mode now, and the work has moved to making it hold up in the real world.
An unglamorous clarification about refresh tokens is part of that evolution, and I’m glad to see it land.
