LiteLLM MCP server: a gateway, not a server

Why LiteLLM appears in MCP registries without publishing a server of its own data, and what the entry bearing its name actually points at.

Last verified 26 August 2026 · from LiteLLM's MCP Gateway documentation, the MCP registry, PyPI and GitHub

This page is one of 90 in a directory of monitoring and developer tools. Each page checks what an AI coding agent can get out of the tool through its MCP server, the connector that lets the agent query the tool directly.

What is the LiteLLM MCP server, and is it usable?

LiteLLM is a proxy in front of language-model providers, giving one API across many models with keys, budgets and rate limits attached. Its MCP role follows from that position: it stands between agents and tools the way it already stands between applications and models.

In gateway mode the proxy registers MCP servers, and agents connect to the proxy rather than to each server. Access control, budgets and logging then apply to tool calls as well as model calls.

What it does not do is expose LiteLLM's own state, such as spend per key or request logs, as MCP tools. That is what a LiteLLM connector would mean, and it does not exist.

Every one of the 90 vendors in this directory gets the same four checks. LiteLLM passes 0 of them.

LiteLLM operates in AI cost management, and registers no tool an agent could use to ask what a key has spent.

LiteLLM's MCP support points outward, not inward. An agent cannot ask LiteLLM what a key has spent, because no tool exposes that. What LiteLLM offers instead is a controlled path to other people's tools. That is worth having, for a different reason than a connector would be.

What can an AI agent do with LiteLLM?

One thing goes wrong here, and a registry entry is the cause.

How to configure LiteLLM MCP for agents

1. 1

   Turn on database storage first

   LiteLLM documents STORE_MODEL_IN_DB=True, or store_model_in_db: true under general_settings, as the prerequisite for holding MCP servers. supported_db_objects: ["mcp"] narrows that to MCP alone.

2. 2

   Pick the transport per server

   The documented default is sse. http selects Streamable HTTP and stdio runs a local process, which then needs command and may take args and env.

3. 3

   Choose the alias carefully, because it becomes a prefix

   LiteLLM prefixes every tool name with its server name. SEP-986 is the MCP proposal that sets the format for tool names. From v1.80.18 new server names must comply with SEP-986, and non-compliant names can no longer be added.

4. 4

   Decide who reaches each server

   Permissions apply by key, by team and by organization. Setting allow_all_keys: true overrides that and exposes the server to every LiteLLM key.

5. 5

   Decide where each credential lives

   A server can carry its own through auth_type and auth_value, or the caller can forward one per request as x-mcp-{server_alias}-{header_name}.

Paste this into your agent’s instructions

The gateway filters the tool list by the calling key's permissions and renames every tool with its server prefix. An agent therefore sees a subset of the tools, under altered names. A tool that is missing may be unregistered, or not permitted for this key. It is not necessarily absent.

When you answer through the LiteLLM gateway, state:
- Which server prefix the tool you called came from.
- That the tool list is filtered by the key in use, so a
  tool may exist and not be visible to this key.
Never state that data does not exist. State which servers
this key can see, and that others may be hidden.
Write your answer in ASD-STE100 Simplified Technical
English. Use short sentences with one idea in each.

Do you need the MCP server at all?

No, LiteLLM publishes no server of its own data. For governing tool access, the proxy is the product and it works. Register your MCP servers with it, point agents at the proxy, and key-level permissions and budgets apply to tool calls.

For reading LiteLLM's own spend data, there is no connector. The proxy exposes a REST API with spend and key endpoints, and an agent can call that directly with the same key.

If per-call LLM cost in an agent conversation is the goal, Helicone publishes a real server for exactly that, at two tools.

Use LiteLLM as the gateway it is. For querying spend from an agent, call its API, or connect a vendor that publishes a cost server.

LiteLLM MCP server setup

Nothing here installs a LiteLLM server, because there is none. This is how other servers are registered with the gateway, and how an agent then reaches them through one endpoint.

One prerequisite comes first. LiteLLM documents that storing MCP servers needs database storage enabled, through STORE_MODEL_IN_DB=True or store_model_in_db: true under general_settings.

Credentials never appear in the routing configuration. Each registered server carries its own through auth_type and auth_value, or receives one forwarded per request in a header.

litellm_settings:
  mcp_aliases:
    "deepwiki": "deepwiki_mcp_server"

mcp_servers:
  deepwiki_mcp:
    url: "https://mcp.deepwiki.com/mcp"
  circleci_mcp:
    transport: "stdio"
    command: "npx"
    args: ["-y", "@circleci/mcp-server-circleci"]
    env:
      CIRCLECI_TOKEN: "your-circleci-token"

{"type":"mcp",
 "server_label":"litellm",
 "server_url":"litellm_proxy",
 "require_approval":"never"}

{"mcpServers":{"LiteLLM":{
  "url":"litellm_proxy",
  "headers":{
    "x-litellm-api-key":"Bearer $LITELLM_API_KEY",
    "x-mcp-github-authorization":"Bearer $GITHUB_TOKEN"}}}}

"x-mcp-servers": "Zapier_MCP,dev-group"

Every other client

Each block below is the configuration for one client, with the file path and the key that client expects.

api_key      ->  X-API-Key: <auth_value>
bearer_token ->  Authorization: Bearer <auth_value>
authorization->  Authorization: <auth_value>   (verbatim)

curl <proxy>/mcp-rest/tools/list \
  -H "x-litellm-api-key: Bearer $LITELLM_API_KEY"

${DB_PROTOCOL}://${CORP_USERNAME}:${CORP_PASSWORD}@${DB_HOSTNAME}

Read-only access, permissions and security

• allow_all_keys overrides the permission model

  Set on a server, it makes that server available to every LiteLLM key even when the key or team does not list it in its MCP permissions.

• x-mcp-auth is deprecated, and it goes to every server

  The legacy header is forwarded to every MCP server rather than one, which is why LiteLLM now recommends the server-specific x-mcp-{server_alias}-{header_name} form.

• One auth type sends two different headers

  LiteLLM notes that the OpenAPI-tool path emits Authorization: ApiKey <value> where the managed transport path emits X-API-Key, and the deprecated broadcast header uses the ApiKey form too.

• Permissions are graded by key, team and organization

  That is the boundary that decides which registered servers a caller can list at all.

• Server variables can be shared or personal

  Instance scope shares one stored credential across all users; Per-user scope requires each user to supply their own.

• The gateway is a chokepoint by design

  Every tool call passes through it, so its logs and its permission table are the audit surface for servers you do not own.

Troubleshooting

You cannot find a LiteLLM MCP server to install

There is not one exposing LiteLLM's own data. The proxy is a gateway that registers and governs other people's servers. To read spend or key data, call LiteLLM's REST API directly.

A registered server does not persist or does not appear

Database storage is required. Set STORE_MODEL_IN_DB=True, or store_model_in_db: true under general_settings. If supported_db_objects is set, it must include mcp.

The connection fails when you use the proxy's own URL

server_url must be the literal string litellm_proxy when the request already goes to the proxy. The documentation states that using the full proxy URL is incorrect, because the proxy needs the literal value to route.

A new server name is rejected

From v1.80.18 names must comply with SEP-986, because LiteLLM prefixes every tool with its server name. Non-compliant names can no longer be added; existing ones warn today and may be blocked later.

The downstream server rejects the credential

Check which header shape auth_type produces. api_key sends X-API-Key on the managed transport path, while the OpenAPI-tool path sends Authorization: ApiKey for the same setting.

A key can reach a server it should not

Look for allow_all_keys: true on that server. It makes the server available to every key regardless of the key or team MCP permissions.

The agent sees too many tools

Send x-mcp-servers with the server names or access groups that request needs. It narrows the tool list without changing the registration.

LiteLLM MCP server: Reference

What engineers report

LiteLLM is the most widely adopted product in this guide, at 57,743 stars. There is no first-party server to review, so this section records what the search returned.

Registry, PyPI and GitHub checked on 24 August 2026, and the adoption figures refetched on 1 September 2026. The 404 on the linked repository was confirmed directly against the GitHub API.

Should you connect an agent to LiteLLM?

There is nothing to connect: this is the agent side of MCP. Best for gateway use, with LiteLLM's REST API for anything you need to read back.

Strongest fit

Teams already proxying model calls through LiteLLM who want the same key-level control over tool calls.

Main advantage

Gateway mode puts access control, budgets and logging in front of MCP servers you do not own.

Main weakness

Nothing exposes LiteLLM's own data, so an agent cannot ask what a key spent.

Operational risk

A registry entry bearing LiteLLM's name points at a deleted repository, which is a supply-chain trap rather than a working option.

Frequently asked questions