Files
holocron/plugins/gitea/.apm/skills/gitea-issues/references/search.md
Defame1297 dd1981db80 fix(gitea-issues): list_issues does have type and milestones on v1.7.0
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
2026-08-30 20:51:02 +00:00

1.4 KiB

topic, source_keys
topic source_keys
search
gitea-mcp-repo
gitea-mcp-slim-go

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 parameter
  • state (string, enum "open" | "closed" | "all", optional)
  • type (string, enum "issues" | "pulls", optional) — the same filter, with the same values, that list_issues takes (see references/issues.md)
  • labels (string, optional) — comma-separated label names — a plain string, not the array form list_issues uses
  • owner (string, optional) — restrict results to one owner
  • page (number, optional, default 1)
  • per_page (number, optional, default 30)

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.