SKILL.md's headline Gotcha said `list_issues` "has no `type` filter", and references/issues.md stated in bold that neither `type` nor `milestones` exists, "despite both appearing in api-reference.md". Both parameters are present on the deployed gitea-mcp v1.7.0 and both work: `type: "issues"` returns only issues, `type: "pulls"` only PRs, and `milestones` filters by name. Unfiltered, the same window returns them interleaved, so the mixing the Gotcha describes is real — only the stated remedy was wrong. This mattered most in gitea-workflow's no-args check-in, which lists open issues through this skill and so reported PRs under "Open Issues" while the skill forbade the one-parameter fix. The list flow now passes `type: "issues"`. references/sources.md recorded the absence as a live-verification win over stale research docs; it now records that the earlier check was superseded by v1.7.0, since drift runs in both directions. gitea-prs cited the same parameter as its canonical drift example and no longer does — no replacement example was substituted, because the obvious candidate was not verified in this pass. Also defaults label writes to `add_labels`: `replace_labels` clears every label not in the array, and per-label exclusivity makes blanket replacement destructive for a non-exclusive scope. Verified live against gitea-mcp v1.7.0, read-only calls. Refs #99
1.4 KiB
1.4 KiB
topic, source_keys
| topic | source_keys | ||
|---|---|---|---|
| search |
|
search_issues
Call signature verified live against the deployed gitea-mcp server via ToolSearch at authoring
time (see references/sources.md) — confirmed to match api-reference.md.
Parameters:
query(string, required) — the only hard-required parameterstate(string, enum"open"|"closed"|"all", optional)type(string, enum"issues"|"pulls", optional) — the same filter, with the same values, thatlist_issuestakes (seereferences/issues.md)labels(string, optional) — comma-separated label names — a plain string, not the array formlist_issuesusesowner(string, optional) — restrict results to one ownerpage(number, optional, default1)per_page(number, optional, default30)
Call:
search_issues query: <text>
Narrowing the search:
search_issues query: <text> owner: <owner> state: "open" type: "pulls" labels: "bug,urgent"
This is a cross-repository search (unlike list_issues, which is scoped to one owner/repo) —
useful when the caller doesn't know which repo an issue lives in, or wants results across an
organization. Pass owner to narrow scope if the caller does know it.
Paginate the same way as list_issues: iterate page until the returned count is less than
per_page.