gitea-releases was the weakest skill in the plugin: no allowed-tools, no owner/repo resolution, and a checkbox list where a dispatch table belongs, so an agent reaching it had to guess both its permissions and its inputs. The id-vs-tag_name trap — deleting by tag name where the API wants the numeric id — is restored as an explicit Gotcha because it destroys the wrong release silently. Elsewhere the `exclusive` flag was documented on the wrong side of the read/write split, and label data from one instance was presented as though it were universal, which invites an agent to assume a taxonomy that does not exist on the target repo. rename_branch was missing from the branch surface. Reference prose and fences are cleaned up in passing.
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.