list_repo_labels does not list organization level labels #125

New issue

Closed

opened 2026-05-09 12:32:46 +00:00 by enbyted · 2 comments

enbyted commented

2026-05-09 12:32:46 +00:00

(Migrated from codeberg.org)

The MCP does not expose organization-level labels at all. Though I believe they should be exposed by the list_repo_labels tool as there is no reason for the model to make 2 separate requests.

The MCP does not expose organization-level labels at all. Though I believe they should be exposed by the `list_repo_labels` tool as there is no reason for the model to make 2 separate requests.

goern commented

2026-05-09 20:38:45 +00:00

(Migrated from codeberg.org)

Assessed. Confirmed gap.

Root cause: list_repo_labels in operation/issue/issue.go calls Client().ListRepoLabels(...) → only /repos/{owner}/{repo}/labels. Forgejo API also exposes /orgs/{org}/labels, but forgejo-sdk/forgejo/v3@v3.0.0 has no binding for it. So org-owned repos can carry org labels on issues, but MCP cannot list them — the model has no way to discover the IDs.

Implementation path (no SDK upgrade required):

New tool list_org_labels(org, page, limit) — direct mapping to /orgs/{org}/labels.
Augment list_repo_labels with include_org_labels (bool, default true). When the repo owner is an org, merge org labels into the result and tag each label with scope: "repo" | "org" so callers can disambiguate IDs.
Use the existing pkg/forgejo.DoJSONList raw-HTTP helper (already used for attachments). 404 from the org endpoint maps to empty list — no error. Same auth/UA/logging as the rest of the client.
Tests via httptest.Server matching pkg/forgejo/*_test.go patterns: repo-only, org-only, merged, 404 → empty, include_org_labels=false suppresses merge.

Tradeoffs: one extra HTTP call when merge is enabled. Worth it — eliminates the round-trip the model would otherwise need to do explicitly. Standalone list_org_labels keeps single-responsibility for callers that already know the org.

Tracked internally as forgejo-mcp-7ch, with forgejo-mcp-xv0 as the OpenSpec change preceding implementation.

Followups for you, if convenient: any specific repo/org pair you'd like used as the integration test fixture?

Assessed. Confirmed gap. **Root cause**: `list_repo_labels` in `operation/issue/issue.go` calls `Client().ListRepoLabels(...)` → only `/repos/{owner}/{repo}/labels`. Forgejo API also exposes `/orgs/{org}/labels`, but `forgejo-sdk/forgejo/v3@v3.0.0` has no binding for it. So org-owned repos can carry org labels on issues, but MCP cannot list them — the model has no way to discover the IDs. **Implementation path** (no SDK upgrade required): 1. New tool `list_org_labels(org, page, limit)` — direct mapping to `/orgs/{org}/labels`. 2. Augment `list_repo_labels` with `include_org_labels` (bool, default `true`). When the repo owner is an org, merge org labels into the result and tag each label with `scope: "repo" | "org"` so callers can disambiguate IDs. 3. Use the existing `pkg/forgejo.DoJSONList` raw-HTTP helper (already used for attachments). 404 from the org endpoint maps to empty list — no error. Same auth/UA/logging as the rest of the client. 4. Tests via `httptest.Server` matching `pkg/forgejo/*_test.go` patterns: repo-only, org-only, merged, 404 → empty, `include_org_labels=false` suppresses merge. **Tradeoffs**: one extra HTTP call when merge is enabled. Worth it — eliminates the round-trip the model would otherwise need to do explicitly. Standalone `list_org_labels` keeps single-responsibility for callers that already know the org. Tracked internally as `forgejo-mcp-7ch`, with `forgejo-mcp-xv0` as the OpenSpec change preceding implementation. Followups for you, if convenient: any specific repo/org pair you'd like used as the integration test fixture?

goern commented

2026-05-09 20:47:47 +00:00

(Migrated from codeberg.org)

@enbyted — would you mind reviewing the OpenSpec change for this issue before I start implementation?

It's on branch issues/125:

Browse: https://codeberg.org/goern/forgejo-mcp/src/branch/issues/125/openspec/changes/add-org-label-support
proposal.md — why, what changes, capabilities, impact
design.md — decisions, trade-offs (key calls: D2 two tools, D3 merge defaults on, D4 scope field, D5 unconditional GET)
specs/list_org_labels/spec.md — new tool requirements + scenarios
specs/list-milestones-labels/spec.md — modified list_repo_labels requirements with merge + scope tagging
tasks.md — implementation breakdown

Particular things I'd value your eye on:

Default for include_org_labels — true (you suggested merged behavior; want to confirm default-on matches your expectation).
Pagination — currently shared page/limit across both scopes. Acceptable or would you prefer split parameters?
scope field naming/values ("repo" | "org") — happy with these, or prefer repository/organization long form?
Any scenario you'd want covered that's missing.

No rush — happy to wait a couple days for feedback before I land code.

@enbyted — would you mind reviewing the OpenSpec change for this issue before I start implementation? It's on branch `issues/125`: - **Browse**: https://codeberg.org/goern/forgejo-mcp/src/branch/issues/125/openspec/changes/add-org-label-support - **proposal.md** — why, what changes, capabilities, impact - **design.md** — decisions, trade-offs (key calls: D2 two tools, D3 merge defaults on, D4 `scope` field, D5 unconditional GET) - **specs/list_org_labels/spec.md** — new tool requirements + scenarios - **specs/list-milestones-labels/spec.md** — modified `list_repo_labels` requirements with merge + `scope` tagging - **tasks.md** — implementation breakdown Particular things I'd value your eye on: 1. Default for `include_org_labels` — `true` (you suggested merged behavior; want to confirm default-on matches your expectation). 2. Pagination — currently shared `page`/`limit` across both scopes. Acceptable or would you prefer split parameters? 3. `scope` field naming/values (`"repo"` | `"org"`) — happy with these, or prefer `repository`/`organization` long form? 4. Any scenario you'd want covered that's missing. No rush — happy to wait a couple days for feedback before I land code.