Title
list_repos tool exceeds token limit with large repository counts
Description
When working with organizations that have a large number of repositories, the list_repos MCP tool becomes unusable in Claude as it surpasses the maximum token count limit.
Current Behavior
The tool attempts to return all repositories in a single response, which causes Claude to fail when the result exceeds token limits.
Proposed Solutions
I see two potential approaches to resolve this:
Option 1: Server-Side Pagination
Add pagination to the /repos endpoint on the server, maintaining backward compatibility by making pagination parameters optional.
Example API:
GET /repos?page=1&page_size=50&query=mainframe
Option 2: MCP Server-Side Filtering
Implement pagination logic within the MCP server itself, since the endpoint is relatively fast. This would "fake" pagination from the client perspective while still calling the full endpoint.
Additional Enhancement
Alongside pagination, adding a search/filter query parameter would further reduce the number of calls agents need to make:
GET /repos?search=frontend&page=1&page_size=50&query=mainframe
Contribution
I'm happy to contribute a PR implementing either solution (or a combination). Would appreciate maintainer input on which approach aligns best with the project's architecture and goals.
Title
list_repostool exceeds token limit with large repository countsDescription
When working with organizations that have a large number of repositories, the
list_reposMCP tool becomes unusable in Claude as it surpasses the maximum token count limit.Current Behavior
The tool attempts to return all repositories in a single response, which causes Claude to fail when the result exceeds token limits.
Proposed Solutions
I see two potential approaches to resolve this:
Option 1: Server-Side Pagination
Add pagination to the
/reposendpoint on the server, maintaining backward compatibility by making pagination parameters optional.Example API:
Option 2: MCP Server-Side Filtering
Implement pagination logic within the MCP server itself, since the endpoint is relatively fast. This would "fake" pagination from the client perspective while still calling the full endpoint.
Additional Enhancement
Alongside pagination, adding a search/filter query parameter would further reduce the number of calls agents need to make:
Contribution
I'm happy to contribute a PR implementing either solution (or a combination). Would appreciate maintainer input on which approach aligns best with the project's architecture and goals.