Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

MCP Toolset headers are static — impossible to pass per-user JWT in multi-tenant scenarios

Open
  • Is something wrong?
#1,382 2 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@hemasekhar-p is already working on this.

Since Jul 30, 2026.

  • #1383 by @mekkiamiri — open

Assessment

This issue has not been assessed yet.

Description

needs review

** Please make sure you read the contribution guide and file the issues in the right place. **
Contribution guide.

🔴 Required Information

Please ensure all items in this section are completed to allow for efficient
triaging. Requests without complete information may be rejected / deprioritized.
If an item is not applicable to you - please mark it as N/A

Is your feature request related to a specific problem?

In a multi-user application (e.g. Spring Boot serving multiple authenticated users), each user has their own JWT token that must be forwarded to an MCP server requiring authentication.

Currently, SseServerParameters.headers() returns an ImmutableMap<String, Object> and StreamableHttpServerParameters.headers is a final Map<String, String>. Both are set at construction time and frozen for the lifetime of the toolset.

This means in a typical Spring Boot setup:

// At app startup — no user context available
SseServerParameters params = SseServerParameters.builder()
.url("https://mcp-server.example.com")
.headers(Map.of("Authorization", "Bearer ???")) // No token yet!
.build();
McpToolset toolset = new McpToolset(params);

When User A (with JWT-A) and User B (with JWT-B) both call the agent, the MCP server always receives the same frozen token (or none). There is no way to inject per-request authentication headers.

Describe the Solution You'd Like

  • Root cause

    In DefaultMcpTransportBuilder, the asyncHttpRequestCustomizer is called per-request but always reads from the same frozen parameters object:

    .asyncHttpRequestCustomizer(
    (requestBuilder, method, uri, body, context) -> {
    streamableParams.headers() // ← always the same frozen map
    .forEach((key, value) -> requestBuilder.header(key, value));
    return Mono.just(requestBuilder);
    });

    The context parameter is available but never used for dynamic header resolution.

  • Proposed solution

    Support a Supplier<Map<String, String>> (or similar functional interface) for headers, evaluated at each request:

    SseServerParameters params = SseServerParameters.builder()
    .url("https://mcp-server.example.com")
    .headersProvider(() -> {
    String jwt = SecurityContextHolder.getContext()
    .getAuthentication().getCredentials().toString();
    return Map.of("Authorization", "Bearer " + jwt);
    })
    .build();

    This would allow frameworks like Spring Security to inject the current user's token on every MCP call, without creating a new toolset per request.

Impact on your work

We are building a multi-tenant Spring Boot application where multiple authenticated users interact with ADK agents concurrently. Each user's request must be forwarded to MCP servers that enforce JWT-based authorization.

Currently, we have to create a new McpToolset instance per request to inject the user's token, which is inefficient (new connection per call) and defeats the purpose of connection pooling and session reuse. This is a blocker for any production multi-user deployment that relies on authenticated MCP servers.

Timeline: We are targeting a production release in Q4 2026. A fix or accepted workaround by then would be ideal.

Willingness to contribute

Are you interested in implementing this feature yourself or submitting a PR?
Yes — we are willing to submit a PR for this. We have already identified the affected files and a viable approach (see Proposed API below).

🟡 Recommended Information

Describe Alternatives You've Considered

Create a new McpToolset per request — Works but creates a new transport/connection for every call. No session reuse, poor performance under load

Proposed API / Implementation

Add a headersProvider option alongside the existing static headers:

// SseServerParameters / StreamableHttpServerParameters
@Nullable
public abstract Supplier<Map<String, String>> headersProvider();

// DefaultMcpTransportBuilder — evaluate per-request instead of once
.asyncHttpRequestCustomizer(
(requestBuilder, method, uri, body, context) -> {
Supplier<Map<String, String>> provider = params.headersProvider();
if (provider != null) {
provider.get().forEach(requestBuilder::header);
}
return Mono.just(requestBuilder);
});

Usage with Spring Security:
SseServerParameters params = SseServerParameters.builder()
.url("https://mcp-server.example.com")
.headersProvider(() -> {
Authentication auth = SecurityContextHolder.getContext().getAuthentication();
return Map.of("Authorization", "Bearer " + auth.getCredentials());
})
.build();

This is backward-compatible — existing headers(Map) usage continues to work unchanged.

Additional Context

The asyncHttpRequestCustomizer in DefaultMcpTransportBuilder already receives a context parameter per-request but currently ignores it — the infrastructure for dynamic behavior is partially in place.

Dominant language
Java
Stars
1.7k
Forks
431
Avg merge
3d 2h
Merged PRs (30d)
46

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from google/adk-java

All issues in google/adk-java

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.