fix(mcp): don't auto-detect M2M OAuth from field presence

[ishaan-jaff]

Relevant issues

Pre-Submission checklist

• I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible, it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

CI (LiteLLM team)

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Type

🐛 Bug Fix

Changes

The M2M OAuth feature (added in #20788) auto-detected client_credentials flow
whenever client_id, client_secret, and token_url were all set on an MCP
server. This broke existing interactive OAuth setups (e.g. GitHub Enterprise)
that configure those same three fields for authorization_code flow — LiteLLM
would silently drop the user's token and fetch its own M2M token instead.

Fix: has_client_credentials now returns False by default. M2M must be
opted into explicitly:

mcp_servers:
  my-m2m-server:
    auth_type: oauth2
    oauth2_flow: client_credentials   # new — required to enable M2M
    client_id: ...
    client_secret: ...
    token_url: ...

Existing interactive OAuth configs (GitHub Enterprise etc.) work again with no
changes needed. oauth2_flow defaults to None (interactive), so there's no
breaking change for those users.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Error		Mar 9, 2026 9:49pm

[greptile-apps]

Greptile Summary

This PR successfully fixes a breaking regression in the MCP server M2M OAuth feature. The original implementation auto-detected client_credentials flow from field presence alone (client_id + client_secret + token_url), which silently overrode interactive OAuth setups (e.g., GitHub Enterprise) that legitimately use those same fields for authorization_code flow.

The fix makes M2M opt-in explicit:

• Adds oauth2_flow: Optional[Literal["client_credentials", "authorization_code"]] field to MCPServer (defaults to None = interactive)
• has_client_credentials now returns True only when oauth2_flow == "client_credentials"
• Both config and DB paths correctly propagate the new field; getattr(..., None) defaults safely handle pre-existing DB rows

Testing is comprehensive:

• Regression tests cover the GitHub Enterprise scenario (credentials present without explicit opt-in)
• Edge cases covered: explicit M2M opt-in, explicit authorization_code, partial credentials, and needs_user_oauth_token behavior
• All tests are mock-only with no real network calls

The logic change is minimal, targeted, and correct. Existing interactive OAuth configs work without modification.

Confidence Score: 5/5

• Safe to merge—fix is correct, well-tested, and maintains backward compatibility for existing interactive OAuth configs.
• The PR successfully fixes the breaking regression by making M2M opt-in explicit. The implementation is minimal and targeted. Tests comprehensively cover the failure scenario (GitHub Enterprise regression) and all edge cases. The getattr fallback ensures DB compatibility. No breaking changes for existing users.
• No files require special attention

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[MCP Server Config] --> B{oauth2_flow value}
    B -- "client_credentials" --> C[has_client_credentials = True]
    B -- "authorization_code or None" --> D[has_client_credentials = False]
    C --> E[M2M machine-to-machine flow]
    D --> F{auth_type is oauth2?}
    F -- Yes --> G[needs_user_oauth_token = True]
    F -- No --> H[Static auth or no auth]

Loading

_{Last reviewed commit: bcfe197}