Files
holocron/plugins/gitea/skills/gitea-issues/references/search.md
Defame1297 98980d3d1f feat(gitea): add gitea-issues skill
Covers list_issues, issue_read, issue_write, and search_issues, closing out
all four enrichments deferred from issue #6 comment #848: label inference
(delegated to gitea-labels-milestones), milestone assignment on create,
an assignee workaround for the blocked get_me/read:user scope, and the
"Depends on #N" dependency-linking convention validated by Gitea's
automatic cross-reference rendering.

Call signatures were re-verified live via ToolSearch against the deployed
gitea-mcp server rather than copied from api-reference.md, per ADR 0011 --
this caught that list_issues has no `type` or `milestones` parameter on the
live schema, despite the research doc documenting both (the exact drift
that caused issue #6 comment #849).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FNJWdVvdgvZCHi1hZGqgVQ
2026-07-05 11:02:46 +00:00

40 lines
1.4 KiB
Markdown

---
topic: search
source_keys:
- 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) — **this tool has a working type filter**,
unlike `list_issues` (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`.