Defame1297
0079f3508c
The reference files were last verified against v1.3.0 -- references/sources.md still said so. PR #106 re-verified the write side only, so three defects had accumulated on the read/review side. All three reproduced against the deployed server before being fixed; get_gitea_mcp_server_version reports v1.7.0. - reviews.md forbade review_comments on the "get" response and directed callers to review_scomments, which does not exist. The upstream slim.go typo was corrected; a live pull_request_read on PR #106 returns "review_comments":1 and no review_scomments key. review_comments is an integer count, not comment objects -- distinct from the get_review_comments method. Also fixed in pull-requests.md's response-shape list. - pull_request_review_write grants seven methods; only four were documented. reply_comment, resolve_thread, unresolve_thread and the comment_id parameter had zero mentions anywhere in the skill. Documented from the schema, in a Comment threads section kept outside the numbered review state machine -- they are not lifecycle states. - review_id was documented as required for get_review_comments. It is optional; omitting it lists every inline comment on the PR. Confirmed behaviourally: get_review without it errors, get_review_comments without it returns []. sources.md now records v1.7.0 as the last-verified version, so the next reader knows what these files were checked against. Refs #99
3.0 KiB
name, description, compatibility, metadata, allowed-tools
| name | description | compatibility | metadata | allowed-tools | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| gitea-prs | Use when listing, reading, creating, updating, merging, or reviewing Gitea pull requests — even when the user does not say "Gitea". Not issues -> `gitea-issues`. | Requires Gitea MCP server configured with write:issue and write:repository token scopes. |
|
mcp__gitea__list_pull_requests mcp__gitea__pull_request_read mcp__gitea__pull_request_write mcp__gitea__pull_request_review_write |
Gotchas
- Issues and PRs share one number space.
#42may be an issue rather than a PR. When unsure, callpull_request_read method: "get"and read a 404 as "that number is an issue" — hand it togitea-issues. pull_request_write method: "create"discards most optional parameters in silence.milestone,assignee,assignees,reviewersandteam_reviewersare accepted, dropped, and left out of the response, so a drop is indistinguishable from never passing them.labelsdoes apply on"create", so labels landing is no evidence the milestone did.
Dispatch
Resolve owner and repo from context first, and confirm the number names a PR before writing to it.
| Task | Tool | Reference |
|---|---|---|
| List PRs; read a PR's details, diff, changed files or CI status | list_pull_requests, pull_request_read |
references/pull-requests.md |
| Create a PR — subject to the silent-drop Gotcha above | pull_request_write |
references/pull-requests.md |
| Update, close, reopen or retarget a PR, sync it with its base, or add/remove reviewers | pull_request_write |
references/pull-requests.md |
| Merge a PR, or judge whether it can merge | pull_request_write method: "merge" |
references/merging.md |
| Read, create, submit, dismiss or delete a code review, or reply to and resolve a review comment thread | pull_request_read, pull_request_review_write |
references/reviews.md |
Whatever "create" dropped takes a second call once the PR exists — "update" for milestone and assignees, "add_reviewers" for reviewers.
Read the reference for the row you land on before making the call. Each carries the parameter signatures, the per-method behaviour and the response-shape quirks the row cannot, and every write method has at least one parameter that behaves differently from its issue-side counterpart.
Resolving labels and milestones
labels and milestone take numeric IDs, never name or title strings. Before a pull_request_write call carrying either, resolve them through gitea-labels-milestones: label_read method: "list_repo_labels" for a label name, milestone_read method: "list" for a milestone title.
Resolve a milestone only when the call is an "update" — on "create" the lookup is wasted, per the Gotcha above. Recovering an existing PR's milestone ID needs the same lookup, because pull_request_read returns milestone as a bare title string and never an ID.