You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow user to define credential_key for MCPToolset #5103
Recently, we have noticed that some ADK tools allow users to define a credential_key (for example, OpenAPIToolset). This means that if the client can provided OAuth information, it can be stored within the State using the defined credential_key. Currently, MCPToolset doesn't support it.
Is your feature request related to a specific problem?
Allow client provide OAuth token information if they are able to management it.
Describe the Solution You'd Like
We hope ADK can support two usecase.
Allow client provide OAuth token information if they are able to management it. (token manage by client side)
ADK handle the token management by asking adk_request_credential (token manage by server side)
Impact on your work
This feature can allow us support difference use case for OAuth strategy
Willingness to contribute
Are you interested in implementing this feature yourself or submitting a PR?
Would like to trigger a discussion first.
🟡 Recommended Information
Describe Alternatives You've Considered
A clear and concise description of any alternative solutions or workarounds
you've considered and why they didn't work for you.
Proposed API / Implementation
If you have ideas on how this should look in code, please share a
pseudo-code example.
Additional Context
Add any other context or screenshots about the feature request here.
@abehsu-mu Thank you for submitting . This issue is currently under review by our team, and I’ll keep you posted on any updates. We appreciate your input!
Hi, I've opened #3675 which may address this use case. It adds a header_provider / state_header_mapping to McpToolset so auth tokens from session state can be propagated as HTTP headers to MCP servers, along with request_state for ephemeral (non-persisted) credentials.
Would you mind taking a look to see if it covers your scenario?
Hi @abehsu-mu, good point! the MCP spec prescribes Authorization: Bearer for HTTP transports, so credential_key works for the standard case; will add it to #3675 alongside state_header_mapping which covers custom scenarios
Hey @abehsu-mu, tracked this down — the gap is that McpToolset.init never threads credential_key through to AuthConfig the way OpenAPIToolset does.
As a workaround, try monkey-patching init and get_tools to inject credential_key into _auth_config — that should cover both your client-managed and ADK-managed token use cases.
Could you give that a try and confirm it unblocks you?
Also worth noting that PR #3675 already has commits targeting exactly this (feat(mcp): add credential_key shorthand for Bearer token propagation), so once you've verified the workaround holds up, it'd be great to validate against that PR before it merges!
Activity
klateefa commentedon Apr 2, 2026
@abehsu-mu Thank you for submitting . This issue is currently under review by our team, and I’ll keep you posted on any updates. We appreciate your input!
timof1308 commentedon Apr 5, 2026
Hi, I've opened #3675 which may address this use case. It adds a
header_provider/state_header_mappingtoMcpToolsetso auth tokens from session state can be propagated as HTTP headers to MCP servers, along withrequest_statefor ephemeral (non-persisted) credentials.Would you mind taking a look to see if it covers your scenario?
abehsu-mu commentedon Apr 6, 2026
Hi @timof1308 :
Any reason you choose to create the other params instead of using credential_key to align with other tools?
timof1308 commentedon Apr 7, 2026
Hi @abehsu-mu, good point! the MCP spec prescribes
Authorization: Bearerfor HTTP transports, socredential_keyworks for the standard case; will add it to #3675 alongsidestate_header_mappingwhich covers custom scenariosfeat(mcp): add credential_key shorthand for Bearer token propagation
feat(mcp): add credential_key shorthand for Bearer token propagation
surajksharma07 commentedon Apr 8, 2026
Hey @abehsu-mu, tracked this down — the gap is that McpToolset.init never threads credential_key through to AuthConfig the way OpenAPIToolset does.
As a workaround, try monkey-patching init and get_tools to inject credential_key into _auth_config — that should cover both your client-managed and ADK-managed token use cases.
Could you give that a try and confirm it unblocks you?
Also worth noting that PR #3675 already has commits targeting exactly this (feat(mcp): add credential_key shorthand for Bearer token propagation), so once you've verified the workaround holds up, it'd be great to validate against that PR before it merges!
surajksharma07 commentedon Apr 8, 2026
@xuanyang15 @wukath Please have a look into it once.
feat(mcp): add credential_key shorthand for Bearer token propagation
abehsu-mu commentedon Apr 14, 2026
@surajksharma07 Thank you. I probably will try it out tomorrow.
feat(mcp): add credential_key shorthand for Bearer token propagation
abehsu-mu commentedon Apr 21, 2026
@surajksharma07 , I won't have time to test it until after Next. I wish I can test it on next week
feat(mcp): add credential_key shorthand for Bearer token propagation
feat: Allow user to define credential_key for McpToolset
feat: Allow user to define credential_key for McpToolset