Defame1297
d578d6b2f2
Description 709 -> 161 chars, body 683 -> 353 words, Gotchas 8 entries/56% of body -> 2/24.9%. Clears the description FAIL and both Vale CompositionNote errors. Fixes the three stale claims recorded on issue #99, all re-verified against the deployed gitea-mcp schema during review: - The description no longer advertises 'reviewers' as an update capability. editPullRequestFn never reads reviewers or team_reviewers; only add_reviewers/remove_reviewers do. - milestone is now marked honoured on "update" only, in the Gotcha, the body and the dispatch table's create row. On "create" the server discards it and omits the key from the response, so the drop is indistinguishable from never passing it -- and labels DOES apply on create, so labels landing is no evidence the milestone did. The old text told callers to resolve a milestone before any write, wasting the lookup on create. - The superseded un-draft workaround is gone. "update" with draft:false and no title makes the server strip the prefix itself, including [WIP], case-insensitively -- carried by references/pull-requests.md, corrected in PR #106. The 22-row tool/method table becomes a 5-row dispatch table; all 20 operations it named remain reachable, including update_branch and the reviewer methods. 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 | 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.