Thanks for this project! Using it against a Forgejo instance I hit two related issues in the repository-listing tools. Both stem from a mismatch between the advertised tool schemas and what the underlying SDK (codeberg.org/mvdkleijn/forgejo-sdk/forgejo/v2) actually supports.
1. Phantom (advertised-but-ignored) parameters
tools/repo/list.go advertises filter/sort parameters in the input schemas that are never sent to Forgejo:
list_my_repositories declares affiliation, visibility, sort, direction — but Handler() builds forgejo.ListReposOptions{} and only sets Page / Limit. The other four are silently dropped.
list_org_repositories declares type, sort, direction — same thing; only Page / Limit are applied.
The reason is structural: in the SDK, both ListReposOptions and ListOrgReposOptions embed only ListOptions (i.e. Page + PageSize). The endpoints (GET /user/repos, GET /orgs/{org}/repos) don't accept those extra query params through this SDK, so they can't be honored.
Effect: a client (or LLM) calls list_my_repositories(affiliation="owner", sort="updated"), gets a success response, but the result is unfiltered and unsorted — a silent no-op that's easy to mistake for real filtering. The existing code comments (// Note: ListReposOptions is quite limited in the SDK) acknowledge the gap, but the schema still advertises the params.
Suggested fix: drop the non-functional params from both schemas (keep page/limit) so the tools don't claim capabilities they can't deliver. (Alternatively, implement them client-side, but server-side filtering isn't available via the SDK.)
2. Missing list_user_repositories tool
There's no tool to list the repositories of a specific user. list_org_repositories only works for orgs (it calls /orgs/{org}/repos and returns GetOrgByName when given a username), and list_my_repositories is limited to the authenticated user.
The SDK already exposes func (c *Client) ListUserRepos(user string, opt ListReposOptions) → GET /users/{user}/repos, so adding a list_user_repositories tool that takes a user param plus page/limit would be a small, self-contained addition that mirrors the existing list_org_repositories implementation.
Happy to send a PR for either/both if you're open to it — wanted to align on direction first.
Environment: ronmi/forgejo-mcp (HTTP mode), forgejo-sdk v2.2.0.
Thanks for this project! Using it against a Forgejo instance I hit two related issues in the repository-listing tools. Both stem from a mismatch between the advertised tool schemas and what the underlying SDK (
codeberg.org/mvdkleijn/forgejo-sdk/forgejo/v2) actually supports.1. Phantom (advertised-but-ignored) parameters
tools/repo/list.goadvertises filter/sort parameters in the input schemas that are never sent to Forgejo:list_my_repositoriesdeclaresaffiliation,visibility,sort,direction— butHandler()buildsforgejo.ListReposOptions{}and only setsPage/Limit. The other four are silently dropped.list_org_repositoriesdeclarestype,sort,direction— same thing; onlyPage/Limitare applied.The reason is structural: in the SDK, both
ListReposOptionsandListOrgReposOptionsembed onlyListOptions(i.e.Page+PageSize). The endpoints (GET /user/repos,GET /orgs/{org}/repos) don't accept those extra query params through this SDK, so they can't be honored.Effect: a client (or LLM) calls
list_my_repositories(affiliation="owner", sort="updated"), gets a success response, but the result is unfiltered and unsorted — a silent no-op that's easy to mistake for real filtering. The existing code comments (// Note: ListReposOptions is quite limited in the SDK) acknowledge the gap, but the schema still advertises the params.Suggested fix: drop the non-functional params from both schemas (keep
page/limit) so the tools don't claim capabilities they can't deliver. (Alternatively, implement them client-side, but server-side filtering isn't available via the SDK.)2. Missing
list_user_repositoriestoolThere's no tool to list the repositories of a specific user.
list_org_repositoriesonly works for orgs (it calls/orgs/{org}/reposand returnsGetOrgByNamewhen given a username), andlist_my_repositoriesis limited to the authenticated user.The SDK already exposes
func (c *Client) ListUserRepos(user string, opt ListReposOptions)→GET /users/{user}/repos, so adding alist_user_repositoriestool that takes auserparam pluspage/limitwould be a small, self-contained addition that mirrors the existinglist_org_repositoriesimplementation.Happy to send a PR for either/both if you're open to it — wanted to align on direction first.
Environment:
ronmi/forgejo-mcp(HTTP mode), forgejo-sdkv2.2.0.