跳至主要內容

MCP 總覽

LiteLLM Proxy 提供一個 MCP 閘道，讓您能為所有 MCP 工具使用固定端點，並依 API 金鑰、團隊來控管 MCP 存取。

LiteLLM MCP 架構：搭配所有 LiteLLM 支援的模型使用 MCP 工具

總覽​

功能說明
MCP Operations• 列出工具
• 呼叫工具
• 提示詞
• 資源
Direct REST API/mcp-rest/tools/list 與 /mcp-rest/tools/call — 不需 LLM 即可用 curl 呼叫工具
Supported MCP Transports• Streamable HTTP
• SSE
• 標準輸入/輸出 (stdio)
LiteLLM Permission Management• 依 API 金鑰
• 依團隊
• 依組織
MCP 協定更新

閘道會在 initialize 期間協商協定版本。請參閱已測試的版本與功能限制。
LiteLLM 會透過在每個工具名稱前加上其 MCP 伺服器名稱來為多個 MCP 伺服器命名空間，因此新建立的伺服器現在必須使用符合 SEP-986 的名稱；不符合規範的名稱 აღარ可再新增。現有仍違反 SEP-986 的伺服器目前只會發出警告，但未來 MCP 端的推出可能會完全阻擋這些名稱，因此我們建議您在 MCP 強制執行前主動更新任何舊版伺服器名稱，以免它們無法使用。

如需涵蓋應使用哪個端點、傳輸方式與驗證模式的單一決策參考，請參閱MCP 設定參考

新增您的 MCP​

前置需求​

若要將 MCP 伺服器儲存在資料庫中，您需要啟用資料庫儲存：

環境變數：

export STORE_MODEL_IN_DB=True

或在 config.yaml 中：

general_settings:
  store_model_in_db: true

細粒度資料庫儲存控制​

預設情況下，當 store_model_in_db 為 true 時，所有物件類型（models、MCP、guardrails、vector stores 等）都會儲存在資料庫中。如果您只想儲存特定物件類型，請使用 supported_db_objects 設定。

範例：只將 MCP 伺服器儲存在資料庫中

config.yaml
general_settings:
  store_model_in_db: true
  supported_db_objects: ["mcp"]  # Only store MCP servers in DB

model_list:
  - model_name: gpt-5.6-terra
    litellm_params:
      model: openai/gpt-5.6-terra
      api_key: sk-xxxxxxx

查看所有可用的物件類型： Config Settings - supported_db_objects

如果未設定 supported_db_objects，所有物件類型都會從資料庫載入（預設行為）。

如需在設定後診斷連線問題，請先參閱 MCP 疑難排解指南中的五分鐘分流與症狀矩陣。

在 LiteLLM UI 中，前往「MCP Servers」，然後點選「Add New MCP Server」。

在此表單中，您應輸入 MCP Server URL 與要使用的傳輸方式。

LiteLLM 支援下列 MCP 傳輸：

  • Streamable HTTP
  • SSE (Server-Sent Events)
  • 標準輸入/輸出 (stdio)
Add New MCP Server form with a Streamable HTTP serverAdd New MCP Server form with a Streamable HTTP server

新增 HTTP MCP Server​

此影片示範如何在 LiteLLM UI 中新增與使用 HTTP MCP server，並在 Cursor IDE 中使用它。



新增 SSE MCP Server​

此影片示範如何在 LiteLLM UI 中新增與使用 SSE MCP server，並在 Cursor IDE 中使用它。



新增 STDIO MCP Server​

stdio 預設為關閉

除非以 LITELLM_ENABLE_MCP_STDIO=true 啟動 proxy，否則 stdio MCP 伺服器會被停用。當它關閉時，UI 中的 stdio 傳輸會呈灰色不可選，建立或更新 stdio 伺服器會回傳錯誤，而現有的 stdio 伺服器仍會列出但永遠不會啟動：其工具會從工具清單中排除，直接工具請求會回傳 403，而其健康檢查會顯示為不健康

此旗標只會從 proxy 的程序環境讀取。將它設定在 config.yaml 的 environment_variables 下方或資料庫中都不會生效

正在使用現有 stdio 伺服器升級？ 請將 LITELLM_ENABLE_MCP_STDIO=true 加入 proxy 的環境並重新啟動。在您這麼做之前，proxy 會記錄一則警告，指出它將不會啟動的每個 stdio 伺服器名稱

對於 stdio MCP 伺服器，請將「Standard Input/Output (stdio)」選為傳輸類型，並以 JSON 格式提供 stdio 設定：

Stdio configuration for an MCP serverStdio configuration for an MCP server

OAuth 設定與覆寫​

LiteLLM 預設會嘗試 OAuth 2.0 Authorization Server Discovery。當您在 UI 中建立 MCP 伺服器並設定 Authentication: OAuth 時，LiteLLM 會定位提供者中繼資料、動態註冊用戶端，並以 PKCE 為基礎執行授權，而您無需提供任何額外細節。

需要時可自訂 OAuth 流程：

OAuth authentication settings for an MCP serverOAuth authentication settings for an MCP server
  • 提供明確的用戶端憑證 – 如果 MCP 提供者不支援動態用戶端註冊，或您希望自行管理用戶端，請填入 client_id、client_secret，以及所需的 scopes。
  • 覆寫探索 URL – 在某些環境中，LiteLLM 可能無法連線到提供者的中繼資料端點。請使用可選的 authorization_url、token_url 與 registration_url 欄位，將 LiteLLM 直接指向正確的端點。

AWS SigV4 驗證​

對於託管於 AWS Bedrock AgentCore 的 MCP 伺服器，請將驗證類型選為 AWS SigV4。LiteLLM 會使用您的 AWS 憑證，並透過 Signature Version 4 為每個外送的 MCP 請求簽章。

AWS SigV4 authentication settings for an MCP serverAWS SigV4 authentication settings for an MCP server

填入您的 AWS 區域、服務名稱（預設為 bedrock-agentcore），並可選擇填入您的 AWS access key 與 secret。若省略憑證，LiteLLM 會回退到 boto3 憑證鏈（IAM roles、環境變數等）。

查看完整 SigV4 設定指南


靜態標頭​

有時您的 MCP 伺服器需要每個請求都帶有特定標頭。可能是 API key，也可能是伺服器所預期的自訂標頭。與其設定驗證，不如直接設定它們。

Static headers in the MCP server permission settingsStatic headers in the MCP server permission settings

這些標頭會隨每個請求送到伺服器。就是這樣。

何時使用此功能：

  • 您的伺服器需要不符合標準驗證模式的自訂標頭
  • 您希望完全掌控實際送出的標頭內容
  • 您正在除錯，且需要在不變更驗證設定的情況下快速新增標頭

伺服器變數​

將憑證儲存在伺服器上，並透過 ${VAR_NAME} 在靜態標頭或驗證中引用它們（例如 ${DB_PROTOCOL}://${CORP_USERNAME}:${CORP_PASSWORD}@${DB_HOSTNAME}）。將每個變數的範圍設為 Instance（共享）或 Per-user（每位使用者各自提供自己的值）。

何時使用此功能：

  • 每位使用者都需要使用自己的靜態憑證連線
  • 您希望在不同使用者之間重複使用某些共享資訊（例如 DB url）

將 OpenAPI 規格轉換為 MCP 伺服器​

LiteLLM 可以將 OpenAPI 規格轉換為 MCP 伺服器，將任何 REST API 以 MCP 工具形式暴露，而無需撰寫自訂伺服器程式碼。

請參閱 從 OpenAPI 規格產生 MCP 的指南 以取得完整設定、使用範例，以及如何覆寫工具名稱與描述。

MCP OAuth​

LiteLLM 支援 MCP 伺服器的 OAuth 2.0——同時支援面向使用者用戶端的互動式（PKCE）流程，以及供後端服務使用的機器對機器（M2M）client_credentials。

請參閱 MCP OAuth 指南 以取得設定說明、序列圖與測試伺服器。

詳細 OAuth 參考資料（按一下展開）

LiteLLM v 1.77.6 新增了對 MCP 伺服器 OAuth 2.0 Client Credentials 的支援。

您可以在 config.yaml 中設定，或直接從 LiteLLM UI（MCP Servers → Authentication → OAuth）進行設定。每個 auth_type: oauth2 伺服器都必須透過 oauth2_flow 宣告其流程：互動式瀏覽器登入使用 authorization_code（如下所示），而機器對機器權杖則使用 client_credentials。

mcp_servers:
  github_mcp:
    url: "https://api.githubcopilot.com/mcp"
    auth_type: oauth2
    oauth2_flow: authorization_code
    client_id: os.environ/GITHUB_OAUTH_CLIENT_ID
    client_secret: os.environ/GITHUB_OAUTH_CLIENT_SECRET

請參閱 Claude Code 教學

運作方式​

參與者

  • Client – 具備 MCP 能力的 AI 代理程式（例如 Claude Code、Cursor，或其他 IDE/代理程式），代表使用者啟動 OAuth 探索、授權與工具呼叫。
  • LiteLLM Proxy – 在保護已儲存憑證的同時，處理所有 OAuth 探索、註冊、權杖交換與 MCP 流量。
  • Authorization Server – 透過動態用戶端註冊、PKCE 授權與權杖端點發行 OAuth 2.0 權杖。
  • MCP Server (Resource Server) – 接收 LiteLLM 已驗證 JSON-RPC 請求的受保護 MCP 端點。
  • User-Agent (Browser) – 暫時參與，以便最終使用者在授權步驟中授予同意。

流程步驟

  1. 資源探索：用戶端從 LiteLLM 的 .well-known/oauth-protected-resource 端點擷取 MCP 資源中繼資料，以了解權限範圍與能力。
  2. 授權伺服器探索：用戶端透過 LiteLLM 的 .well-known/oauth-authorization-server 端點取得 OAuth 伺服器中繼資料（權杖端點、授權端點、支援的 PKCE 方法）。
  3. 動態用戶端註冊：用戶端透過 LiteLLM 註冊，LiteLLM 再將請求轉送至授權伺服器（RFC 7591）。如果提供者不支援動態註冊，您可以在 LiteLLM 中預先儲存 client_id/client_secret（例如 GitHub MCP），流程會以相同方式進行。
  4. 使用者授權：用戶端啟動瀏覽器工作階段（含 code challenge 與 resource 提示）。使用者核准存取後，授權伺服器會經由 LiteLLM 將 code 傳回給用戶端。
  5. 權杖交換：用戶端以授權碼、code verifier 與 resource 呼叫 LiteLLM。LiteLLM 與授權伺服器交換這些資訊，並回傳所發出的存取/重新整理權杖。
  6. MCP 呼叫：在持有有效權杖時，用戶端將 MCP JSON-RPC 請求（加上 LiteLLM API 金鑰）送至 LiteLLM，LiteLLM 再將其轉送至 MCP 伺服器並轉遞工具回應。

另請參閱官方 MCP 授權流程 以取得更多參考資料。

將自訂標頭轉送至 MCP 伺服器​

LiteLLM 支援使用 extra_headers 設定參數，將額外的自訂標頭從 MCP 用戶端轉送至後端 MCP 伺服器。這可讓您傳遞 MCP 伺服器所需的自訂驗證權杖、API 金鑰或其他標頭。

組態

在 MCP 伺服器組態中設定 extra_headers，以指定應轉送哪些標頭名稱：

config.yaml with extra_headers
mcp_servers:
  github_mcp:
    url: "https://api.githubcopilot.com/mcp"
    auth_type: "bearer_token"
    auth_value: "ghp_default_token"
    extra_headers: ["custom_key", "x-custom-header", "Authorization"]
    description: "GitHub MCP server with custom header forwarding"

用戶端使用​

從 MCP 用戶端連線時，請加入與 extra_headers 設定相符的自訂標頭：

FastMCP Client with Custom Headers
from fastmcp import Client
import asyncio

# MCP client configuration with custom headers
config = {
    "mcpServers": {
        "github": {
            "url": "http://localhost:4000/github_mcp/mcp",
            "headers": {
                "x-litellm-api-key": "Bearer sk-<your-litellm-api-key>",
                "Authorization": "Bearer gho_token", 
                "custom_key": "custom_value",
                "x-custom-header": "additional_data"
            }
        }
    }
}

# Create a client that connects to the server
client = Client(config)

async def main():
    async with client:
        # List available tools
        tools = await client.list_tools()
        print(f"Available tools: {tools}")
        
        # Call a tool if available
        if tools:
            result = await client.call_tool(tools[0].name, {})
            print(f"Tool result: {result}")

# Run the client
asyncio.run(main())

運作方式​

  1. 設定：在您的 MCP server 設定中定義 extra_headers，並填入您要轉送的標頭名稱
  2. 用戶端標頭：在您的 MCP 用戶端請求中包含對應的標頭
  3. 標頭轉送：LiteLLM 會自動將符合的標頭轉送到後端 MCP server
  4. 驗證：後端 MCP server 會同時接收已設定的驗證標頭與自訂標頭

將請求標頭傳遞到 STDIO 環境變數​

如果您的 stdio MCP server 需要每次請求的憑證，您可以將用戶端請求中的 HTTP 標頭直接對應到啟動的 stdio 程序環境中。請使用 ${X-HEADER_NAME} 語法在 env 值中引用標頭名稱。LiteLLM 會從傳入請求中讀取該標頭，並在啟動命令前設定 env var。

Forward X-GITHUB_PERSONAL_ACCESS_TOKEN header to stdio env
{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${X-GITHUB_PERSONAL_ACCESS_TOKEN}"
      }
    }
  }
}

在此範例中，當用戶端以 X-GITHUB_PERSONAL_ACCESS_TOKEN 標頭發出請求時，proxy 會將該值以 GITHUB_PERSONAL_ACCESS_TOKEN 環境變數的形式轉送到 stdio 程序。

控制最終使用者的 MCP 存取​

控制您的 AI 應用程式最終使用者可以存取哪些 MCP server（例如，內部聊天 UI 的使用者）。將客戶 ID 傳入 x-litellm-end-user-id 標頭，以便：

  • 強制執行物件權限（限制可存取的 MCP server）
  • 套用客戶專屬預算
  • 追蹤每位客戶的支出

FastMCP 用戶端範例：

Track customer spend with x-litellm-end-user-id
from fastmcp import Client
import asyncio

# MCP client configuration with customer tracking
config = {
    "mcpServers": {
        "github": {
            "url": "http://localhost:4000/github_mcp/mcp",
            "headers": {
                "x-litellm-api-key": "Bearer sk-<your-litellm-api-key>",
                "x-litellm-end-user-id": "customer_123",  # 👈 CUSTOMER ID
                "Authorization": "Bearer gho_token"
            }
        }
    }
}

client = Client(config)

async def main():
    async with client:
        # All MCP calls will be tracked under customer_123
        tools = await client.list_tools()
        result = await client.call_tool(tools[0].name, {})
        print(f"Tool result: {result}")

asyncio.run(main())

Cursor IDE 範例：

Cursor config with customer tracking
{
  "mcpServers": {
    "GitHub": {
      "url": "http://localhost:4000/github_mcp/mcp",
      "headers": {
        "x-litellm-api-key": "Bearer sk-<your-litellm-api-key>",
        "x-litellm-end-user-id": "customer_123"
      }
    }
  }
}

會發生什麼：

  • 會強制執行客戶專屬的物件權限（只能存取允許的 MCP server）
  • 會套用客戶預算
  • 所有工具呼叫都會以 customer_123 進行追蹤

深入了解客戶管理 →

呼叫 Proxy 的 /v1/responses 端點​

當呼叫您 LiteLLM Proxy 的 /v1/responses 端點以使用 MCP 工具時，請對所有允許的伺服器使用 server_url: "litellm_proxy"，或在 tools 陣列中針對一個伺服器使用 litellm_proxy/mcp/<server_alias>。這會告訴 proxy 使用其已設定的 MCP 伺服器。

不要使用完整的 proxy URL

當請求已經要送到 proxy 時，使用 server_url: "https://your-proxy.com/mcp" 是錯誤的。請使用文件中說明的 sentinel 形式來路由到已設定的 MCP 伺服器。直接的 MCP 用戶端則使用網路 URL。

Correct: Using litellm_proxy
curl --location 'https://your-proxy.com/v1/responses' \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer $LITELLM_API_KEY" \
--data '{
    "model": "gpt-5.6-terra",
    "tools": [
        {
            "type": "mcp",
            "server_label": "litellm",
            "server_url": "litellm_proxy",
            "require_approval": "never"
        }
    ],
    "input": "Run available tools",
    "tool_choice": "required"
}'

將自訂標頭傳送到 MCP servers​

若要將自訂標頭（例如 API 金鑰、驗證 token）傳遞給特定的 MCP server，請使用以下任一方式：

選項 1：請求標頭 – 將 x-mcp-{server_alias}-{header_name} 加入您的請求標頭。proxy 會將這些標頭轉送到對應的 MCP server。

# Send Authorization header to the "weather2" MCP server
--header 'x-mcp-weather2-authorization: Bearer your-token'

# Send custom header to the "github" MCP server  
--header 'x-mcp-github-x-api-key: your-api-key'

選項 2：tool config 中的標頭 – 在工具定義中包含 headers 物件。這些會與請求標頭合併。

{
    "type": "mcp",
    "server_label": "litellm",
    "server_url": "litellm_proxy",
    "require_approval": "never",
    "headers": {
        "x-litellm-api-key": "Bearer YOUR_LITELLM_API_KEY",
        "x-mcp-servers": "Zapier_MCP,dev-group",
        "x-mcp-weather2-authorization": "Bearer your-weather-api-token"
    }
}

使用具備用戶端端憑證的 MCP​

如果您想將用戶端端的驗證 token 傳給 LiteLLM，再由 LiteLLM 傳給您的 MCP 進行驗證，就使用這個方式。

您可以使用格式為 x-mcp-{server_alias}-{header_name} 的特定伺服器標頭來指定 MCP 驗證 token。這可讓您對不同的 MCP server 使用不同的驗證方式。

優點：

  • 特定伺服器驗證：每個 MCP server 可使用不同的驗證方法
  • 更好的安全性：不需要在所有 server 之間共享相同的驗證 token
  • 彈性的標頭名稱：支援不同的驗證標頭類型（authorization、x-api-key 等）
  • 清楚的分離：每個 server 的驗證都能明確識別

群組層級驗證標頭​

當存取群組中的伺服器共用一組憑證時，請只傳遞一次 x-mcp-{access_group}-{header_name}，而不是為每台伺服器重複傳遞。LiteLLM 會將其作為預設值，套用到所有其 access_groups 包含該群組的伺服器。特定伺服器的 x-mcp-{server_alias}-{header_name} 標頭會覆寫該伺服器的設定；群組外的伺服器永遠不會收到它；而如果某台伺服器屬於多個攜帶不同憑證的群組，則不會轉送其中任何一個。伺服器別名與存取群組名稱共用 x-mcp- 標頭命名空間，因此別名等於群組名稱的伺服器，仍會將 x-mcp-{alias}-* 視為自己的憑證；請避免將伺服器命名為它不屬於的存取群組名稱。

cURL Example with Group-Level Auth
curl -X POST http://localhost:4000/mcp/dev_group \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "x-litellm-api-key: Bearer $LITELLM_API_KEY" \
  -H "x-mcp-dev_group-authorization: Bearer SHARED_TOKEN" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

用戶端驗證​

請以 x-mcp-{server_alias}-{header_name} 取代已棄用的廣播標頭。請參閱舊版相容性。以下用戶端範例使用範圍限定的憑證

透過 OpenAI Responses API 以特定伺服器驗證連線​

直接呼叫 OpenAI 時，請使用可公開存取的 LiteLLM MCP URL，並包含 gateway 金鑰與範圍限定的上游標頭：

cURL Example with Server-Specific Auth
curl --location 'https://api.openai.com/v1/responses' \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer $OPENAI_API_KEY" \
--data '{
    "model": "gpt-5.6-terra",
    "tools": [
        {
            "type": "mcp",
            "server_label": "litellm",
            "server_url": "https://your-litellm-proxy.example.com/mcp",
            "require_approval": "never",
            "headers": {
                "x-litellm-api-key": "Bearer YOUR_LITELLM_API_KEY",
                "x-mcp-github-authorization": "Bearer YOUR_GITHUB_TOKEN",
                "x-mcp-zapier-x-api-key": "YOUR_ZAPIER_API_KEY"
            }
        }
    ],
    "input": "Run available tools",
    "tool_choice": "required"
}'

自訂 MCP 驗證標頭名稱​

現有部署可以重新命名已棄用的廣播標頭。請參閱中央舊版標頭參考；新的設定應使用特定於伺服器的標頭

使用 MCP 工具搭配 /chat/completions​

適用於所有提供者

此流程是與提供者無關的：相同的 MCP 工具定義可適用於 LiteLLM 後方的_每一個_ LLM 後端（OpenAI、Azure OpenAI、Anthropic、Amazon Bedrock、Vertex、自架部署等）。

LiteLLM Proxy 也支援在傳統的 /v1/chat/completions 端點上使用感知 MCP 的工具。直接在 tools 陣列中提供 MCP 工具定義，LiteLLM 就會擷取並將 MCP 伺服器的工具轉換為與 OpenAI 相容的函式呼叫。當 require_approval 設為 "never" 時，proxy 會自動執行回傳的工具呼叫，並在回傳助理回應前將結果回饋給模型。

Chat Completions with MCP Tools
curl --location '<your-litellm-proxy-base-url>/v1/chat/completions' \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer $LITELLM_API_KEY" \
--data '{
  "model": "gpt-5.6-luna",
  "messages": [
    {"role": "user", "content": "Summarize the latest open PR."}
  ],
  "tools": [
    {
      "type": "mcp",
      "server_url": "litellm_proxy/mcp/github_mcp",
      "server_label": "github_mcp",
      "require_approval": "never"
    }
  ]
}'

如果您省略 require_approval，或將其設為任何非 "never" 的值，MCP 工具呼叫就會回傳給用戶端，讓您可以手動檢閱並執行它們，這與上游 OpenAI 行為一致。

LiteLLM Proxy - MCP Gateway 導覽​

LiteLLM 提供 MCP Gateway，讓管理員可將所有 MCP 伺服器加入 LiteLLM。搭配 MCP 使用 LiteLLM Proxy 的主要優點如下：

  1. 為所有 MCP 工具使用固定端點
  2. 依金鑰、團隊或使用者進行 MCP 權限管理

這段影片示範如何將 MCP 伺服器上線到 LiteLLM Proxy、使用它，以及設定存取控制。

LiteLLM Python SDK MCP 橋接​

LiteLLM Python SDK 可作為 MCP 橋接器，讓 MCP 工具可與所有 LiteLLM 支援的模型搭配使用。LiteLLM 提供以下用於 MCP 的功能

  • 列出 可用的 MCP 工具：OpenAI 用戶端可以檢視所有可用的 MCP 工具
    • litellm.experimental_mcp_client.load_mcp_tools 以列出所有可用的 MCP 工具
  • 呼叫 MCP 工具：OpenAI 用戶端可以呼叫 MCP 工具
    • litellm.experimental_mcp_client.call_openai_tool 以在 MCP 伺服器上呼叫 OpenAI 工具

1. 列出可用的 MCP 工具​

在此範例中，我們將使用 litellm.experimental_mcp_client.load_mcp_tools 來列出任何 MCP 伺服器上的所有可用 MCP 工具。這個方法可用兩種方式：

  • format="mcp" - （預設）回傳 MCP 工具
    • 回傳：mcp.types.Tool
  • format="openai" - 將 MCP 工具回傳為與 OpenAI API 相容的工具。可用於 OpenAI 端點。
    • 回傳：openai.types.chat.ChatCompletionToolParam
MCP Client List Tools
# Create server parameters for stdio connection
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
import os
import litellm
from litellm import experimental_mcp_client


server_params = StdioServerParameters(
    command="python3",
    # Make sure to update to the full absolute path to your mcp_server.py file
    args=["./mcp_server.py"],
)

async with stdio_client(server_params) as (read, write):
    async with ClientSession(read, write) as session:
        # Initialize the connection
        await session.initialize()

        # Get tools
        tools = await experimental_mcp_client.load_mcp_tools(session=session, format="openai")
        print("MCP TOOLS: ", tools)

        messages = [{"role": "user", "content": "what's (3 + 5)"}]
        llm_response = await litellm.acompletion(
            model="gpt-5.6-terra",
            api_key=os.getenv("OPENAI_API_KEY"),
            messages=messages,
            tools=tools,
        )
        print("LLM RESPONSE: ", json.dumps(llm_response, indent=4, default=str))

2. 列出並呼叫 MCP 工具​

在此範例中，我們將使用

  • litellm.experimental_mcp_client.load_mcp_tools 來列出任何 MCP 伺服器上的所有可用 MCP 工具
  • litellm.experimental_mcp_client.call_openai_tool 來在 MCP 伺服器上呼叫 OpenAI 工具

第一個 llm 回應會回傳 OpenAI 工具清單。我們從 LLM 回應中取出第一個工具呼叫，並將其傳遞給 litellm.experimental_mcp_client.call_openai_tool，以在 MCP 伺服器上呼叫該工具。

litellm.experimental_mcp_client.call_openai_tool 的運作方式​

  • 接受來自 LLM 回應的 OpenAI 工具呼叫
  • 將 OpenAI 工具呼叫轉換為 MCP 工具
  • 在 MCP 伺服器上呼叫 MCP 工具
  • 回傳 MCP 工具呼叫的結果
MCP Client List and Call Tools
# Create server parameters for stdio connection
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
import os
import litellm
from litellm import experimental_mcp_client


server_params = StdioServerParameters(
    command="python3",
    # Make sure to update to the full absolute path to your mcp_server.py file
    args=["./mcp_server.py"],
)

async with stdio_client(server_params) as (read, write):
    async with ClientSession(read, write) as session:
        # Initialize the connection
        await session.initialize()

        # Get tools
        tools = await experimental_mcp_client.load_mcp_tools(session=session, format="openai")
        print("MCP TOOLS: ", tools)

        messages = [{"role": "user", "content": "what's (3 + 5)"}]
        llm_response = await litellm.acompletion(
            model="gpt-5.6-terra",
            api_key=os.getenv("OPENAI_API_KEY"),
            messages=messages,
            tools=tools,
        )
        print("LLM RESPONSE: ", json.dumps(llm_response, indent=4, default=str))

        openai_tool = llm_response["choices"][0]["message"]["tool_calls"][0]
        # Call the tool using MCP client
        call_result = await experimental_mcp_client.call_openai_tool(
            session=session,
            openai_tool=openai_tool,
        )
        print("MCP TOOL CALL RESULT: ", call_result)

        # send the tool result to the LLM
        messages.append(llm_response["choices"][0]["message"])
        messages.append(
            {
                "role": "tool",
                "content": str(call_result.content[0].text),
                "tool_call_id": openai_tool["id"],
            }
        )
        print("final messages with tool result: ", messages)
        llm_response = await litellm.acompletion(
            model="gpt-5.6-terra",
            api_key=os.getenv("OPENAI_API_KEY"),
            messages=messages,
            tools=tools,
        )
        print(
            "FINAL LLM RESPONSE: ", json.dumps(llm_response, indent=4, default=str)
        )

常見問題​

問：如何在 LiteLLM 後方的 MCP 伺服器上使用 OAuth2 client_credentials（機器對機器）？

LiteLLM 支援對 client_credentials 授權類型進行自動權杖管理。在您的 MCP 伺服器上設定 client_id、client_secret 和 token_url，LiteLLM 就會自動擷取、快取並更新權杖。設定說明請參閱 MCP OAuth M2M 指南。

問：我從 LiteLLM UI 擷取 OAuth 權杖時，它儲存在哪裡？

UI 只會在 sessionStorage 中保留暫時狀態，以便 OAuth 重新導向流程可以完成；權杖不會持久化儲存在伺服器或資料庫中。

問：我看到 MCP 連線錯誤。我該檢查什麼？

請先查看 MCP 疑難排解指南中的五分鐘分流：一個 curl 可隔離失敗的層級（Client → LiteLLM 與 LiteLLM → MCP），而症狀對照表會將每個狀態碼與症狀對應到其修正方式。若需要升級處理，請先收集支援套件。

LiteLLM Enterprise
為正式環境打造的 SSO/SAML、稽核記錄、支出追蹤、多團隊管理與防護欄。
深入瞭解 →