Support dynamic per-session provider tokens for the local GitHub MCP server

[jvaldivia-te]

Summary

We would like the local GitHub MCP server to support dynamic GitHub credentials on a per-request or per-session basis, instead of only a static token configured at process startup.

This is not a request to replace OAuth. Interactive OAuth remains a good fit for user-driven MCP clients. The gap is that interactive consent does not cleanly solve non-interactive runtimes such as agents, scripts, background workflows, or scheduled jobs, especially when the same platform may need to integrate with many MCPs.

Today the documented local-server pattern is centered around a fixed GITHUB_PERSONAL_ACCESS_TOKEN in env/config. That works for single-user or shared-token deployments, but it is difficult to use in enterprise multi-agent platforms where:

1. platform access to the MCP is authenticated separately
2. GitHub authorization should still reflect the identity and permissions of the person or delegated principal that launched, owns, or scheduled the agent
3. the same MCP instance may need to serve different identities over time

Problem

In our deployment model, there are two distinct auth layers:

• Platform/MCP access auth
  • the caller is authenticated to the MCP platform using an enterprise IdP
• Provider auth
  • the MCP should call GitHub using credentials that represent the actual GitHub identity and permissions intended for that session

The current local GitHub MCP server appears optimized for a static token model:

• one token configured in env
• one effective GitHub identity for the server process

That creates friction for enterprise agent platforms where multiple autonomous agents or workflows may call the same MCP, but provider-side authorization should still reflect different GitHub identities.

In other words, even when an agent runs autonomously, it may still need to operate with the GitHub permissions of the person or delegated principal that created, launched, approved, or scheduled that agent.

Why this matters

1. Avoid consent fatigue across many MCPs

In enterprise environments, requiring a separate interactive OAuth flow per MCP can create heavy consent fatigue, especially when users interact with many MCP-backed capabilities.

This is also a mismatch for non-interactive runtimes such as:

• autonomous agents
• scheduled jobs
• scripts
• background workflows

OAuth consent is fundamentally designed for a human interactive approval step. That maps well to user-driven clients, but less well to agent-driven systems where no human is present at runtime.

A pattern where the platform authenticates access to the MCP, while a provider token is passed or bound dynamically for the MCP session, can reduce repeated consent friction and fit agent-oriented runtimes better.

2. Better fit for non-interactive and multi-agent workflows

Not all MCP usage is a live human-in-the-loop flow. Many deployments involve:

• scheduled agents
• background workflows
• self-directed agents
• platform-managed automation

In these cases, platform authentication and provider authorization are often distinct concerns, and a static single token for the whole server is limiting.

3. Preserve user/provider permissions without shared service tokens

A dynamic token model allows the MCP to act with the actual GitHub permissions intended for that session, rather than forcing:

• one shared long-lived PAT for everyone
• or a separate MCP instance per user

This is more aligned with least privilege and auditing expectations.

Requested capability

Support a mode where the local GitHub MCP server can accept GitHub credentials dynamically per MCP session or request, while remaining compatible with the existing static env-token model.

We are not arguing against static credentials. Those remain useful for deliberate shared-identity patterns, such as a team-scoped bot or GitHub App installation used by an MCP on behalf of a broader team workflow.

The gap is that the current model appears optimized for a single fixed provider identity, while some enterprise agent platforms also need delegated provider identity that can vary by MCP session.

For example, any of these patterns could work:

• a documented per-request auth header contract
• session-scoped credential binding at initialize
• a pluggable credential provider interface
• another supported mechanism that allows the server to resolve the GitHub token dynamically

The key need is:

• the server process should not be limited to one GitHub identity for its whole lifetime