Save the date: proposal meeting 2025-09-02

[findleyr]

We just released v0.3.0 of the SDK, which contained several API changes that we deemed necessary to complete our support for the spec. These changes had associated Proposal issues, but most did not get much feedback.

I expect that if/when folks try out the latest version, they will have stronger opinions. We also may have missed something, of course. For this reason, we had to delay v1.0.0 of the release to September (see #328).

We will aggregate any feedback into proposal issues. Proactively, let's plan on having an open meeting to discuss this feedback.

Next week is Gophercon US, and then a US holiday (Labor Day). Therefore, I propose we meet on Tuesday, September 2nd. Usually 11am New York is the time that works best for the most timezones.

Details

• Time: 11am US Eastern Daylight (UTC-4)
• Date: Tuesday, September 2nd
• Details:
  • Tuesday, September 2 · 11:00am – 12:00pm
  • Time zone: America/New_York
  • Video call link: https://meet.google.com/xru-rfgo-sia
  • Or dial: ‪(US) +1 541-834-1709‬ PIN: ‪235 328 028‬#
  • More phone numbers: https://tel.meet/xru-rfgo-sia?pin=9794303634403

Agenda:

• Tool APIs (again!):
  • mcp.CallToolResult.IsError usage is unclear #385 and mcp.CallToolResult.StructuredContent: what is its usage? #386.
  • Proposal: Add AddToolForType for Runtime Type Support #371
  • Proposal: have CallToolRequest hold CallToolParamsRaw #377
  • Proposal: Session recovery / shared session storage for distributed MCP env #148
• Client-side oauth.

Notes

https://docs.google.com/document/d/1VdCNhtzAKHul2f4gGdChwWFx9SrDieKRZQDtoL4hKXI/edit?tab=t.0

[findleyr]

Please feel free to add agenda items: just comment here and I'll add to the agenda.

[wagnerjt]

Client oauth/fallback without dcr would be a great topic!

[rebaz94]

I'm not sure if it's currently possible, but it would be great to allow custom authentication by passing the http.Request to the TokenVerifier function

[jba]

Client oauth/fallback without dcr would be a great topic!

@wagnerjt The whole client-side story needs to be worked out. Regarding your specific question, that means the ability to pass in a client ID and secret, right?

[jba]

I'm not sure if it's currently possible, but it would be great to allow custom authentication by passing the http.Request to the TokenVerifier function.

@rebaz94:
auth.RequireBearerToken assumes that the token has everything you need to verify. I naively assume that that's how bearer tokens work: it seems suspicious that you'd need something else to authenticate/authorize. But I'm not that familiar with auth in the wild. Can you provide real-world examples where you need other headers?

In the worst case, you could provide your own middleware along the lines of auth.RequireBearerToken, right? We're not doing anything magic there, are we? I would say, if these custom auth schemes are rare, that would be the right way forward.

[rebaz94]

@jba
Sorry, I wasn’t very clear earlier. What you said is totally valid and yes, we could write our own middleware to handle it, but that would essentially duplicate what your implementation already does. What I’m looking for, though, is a way to extract the bearer token more flexibly.

Right now, it only pulls the token from the Authorization header, but I’ve seen MCP providers use different approaches. for example, embedding the token directly in a unique URL instead of using a header. It would be great if RequireBearerTokenOptions allowed defining a custom function that has access to the http.Request and returns the authorization value, with the default behavior based on the header.

[jba]

Right now, it only pulls the token from the Authorization header, but I’ve seen MCP providers use different approaches. for example, embedding the token directly in a unique URL instead of using a header.

The MCP spec seems to disallow this (section 2.6.1). More precisely, it says that the access token must be in the Authorization header, and must not be in the URL query string. I suppose it could redundantly be in the URL path...but we can ignore that since it's in the auth header.

[jba]

I suppose it could redundantly be in the URL path

... and guidance I've read elsewhere says having it anywhere in the URL is a bad idea, because it appears in browser history, logs and other easily visible places.

[wagnerjt]

@wagnerjt The whole client-side story needs to be worked out. Regarding your specific question, that means the ability to pass in a client ID and secret, right?

I guess the whole thing. There is the default flow of auth following PRM flow for oauth and storing the session using DCR that needs to be worked out. However, there are the fallbacks with leveraging Client ID / Client Secret (optional) if DCR does not exist. Additionally the newer spec's draft already is going to support the OIDC client credentials. We probably don't have to have all of these covered, but at least the hooks / interfaces in place for updating the session for each of these different flows.

[findleyr]

Thanks all for the meeting today. I've added Gemini's notes summary to the agenda.

Closing this as complete. We'll have another meeting if/when there are significant new proposals to discuss.

[jba]

@rebaz94: #404 does what you want, almost. We decided to add the request because it might be needed for validation. But it won't help if the access token isn't in the Authorization header, because the RequireBearerToken middleware checks that before calling the TokenVerifier.

[rebaz94]

@jba that's great. Thank you for adding that!