6 views
-/https://github.com/berriai/litellm/issues/32229
GitHub · issue

#32229 [Bug]: MCP Gateway mcp-rest/tools/list silently caps at 100 tools and fails to follow pagination

  • State: open
  • Author: @augustync
  • Labels: bug, proxy

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

### Description:

When LiteLLM connects to an upstream Model Context Protocol (MCP) server that exposes more than 100 tools, the /mcp-rest/tools/list endpoint fails to handle pagination properly.The upstream MCP server responds with the first page of 100 tools and provides a nextCursor value for the remaining items. However, LiteLLM does not follow this cursor, nor does it expose it to the client. It returns only the first 100 tools and completely drops the pagination data. The top-level keys returned in the client response are strictly limited to ['tools', 'error', 'message'].

### Impact:

Any client application or AI agent utilizing this proxy endpoint is permanently blind to any tool that sorts past position 100 in the upstream server's list. Testing with a query parameter like limit shows that it is ignored by LiteLLM.Furthermore, attempting to bypass this via LiteLLM's native /mcp JSON-RPC endpoint as an alternative path fails with an HTTP 500 error: {"error":"MCP request failed","details":""}.

### Steps to Reproduce

1. Connect LiteLLM …

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (7 events)
#0 of 0 · 31d19h12m21s ago — entered · #import:https:::github.com:berriai:litellm post #1669
MCP integration requires protocol-aware pagination, cursor propagation, and investigation of a separate failing request path, increasing cross-component risk; the team response issue is comparatively localized to persistence-to-schema mapping and endpoint serialization.
The right issue is harder because it spans proxy endpoint behavior, upstream pagination semantics, response compatibility, and likely multiple MCP code paths and integration tests. The left issue appears more localized to budget-state calculation or metric initialization, with narrower validation and lower regression risk.
The left issue spans a multi-provider compatibility framework, CI integration, test infrastructure, and broad end-to-end validation, creating substantially greater coordination and regression risk. The right issue is a more localized MCP proxy pagination defect, likely requiring targeted forwarding logic and focused tests.
The right-side change has greater engineering scope: it requires protocol-aware pagination behavior, preserving or translating continuation state, endpoint compatibility decisions, and integration coverage across proxy paths. The left-side change is comparatively localized to container dependency packaging and validation.
Model omitted braces; inferred difficulty from issue scope and surface area.
The MCP gateway work spans pagination state, proxy response compatibility, alternate endpoint behavior, and broader integration testing, while the Ollama issue is comparatively localized to response translation and output normalization.
#0 of 0 · 31d17h42m54s ago — current · #import:https:::github.com:berriai:litellm post #3159
The right issue is harder because it likely requires coordinated changes across MCP client pagination, cursor propagation, request-parameter handling, endpoint behavior, and integration tests. The left issue is comparatively localized to response normalization with focused regression coverage.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search