Skip to content

0.17.0

Latest

Choose a tag to compare

@rubicon-release-please rubicon-release-please released this 02 Sep 10:43
7472b81

forgejo-mcp v0.17.0 (2026-09-02)

This server could open a pull request and it could merge one, but it could not fix a typo in the title of one. The gap came from a rule this project retired back in #118, and nothing had been holding it since except nobody going back to check what the retirement freed up. edit_pull_request closes it, and it is the last tool the workflow was actually missing. The base branch stays out deliberately, because retargeting an open pull request changes what a merge would integrate, which is a different question from fixing a sentence.

Added

It edits title, body, state, assignees, labels, milestone, due date, and whether maintainers may push to the head branch. Only the fields you pass change. The default surface goes from 53 tools to 54, and the full surface from 59 to 60.

This is a distinct endpoint rather than an alias for edit_issue. PATCH /repos/{owner}/{repo}/pulls/{index} takes EditPullRequestOption, which carries allow_maintainer_edit with no equivalent on the issue schema, so widening edit_issue was never going to reach it.

What is deliberately absent

base is neither advertised in the schema nor forwarded if you pass it. Retargeting an open pull request changes what a merge would integrate, which is a larger blast radius than a prose edit, and it is deferred as demand driven like the rest of the long tail. Close the pull request and open a replacement with create_pull_request, which already requires base. What that costs is the review thread on the original, not the capability.

Known limitations

EditPullRequestOption has no concurrency guard. There is no sha equivalent to the one update_file carries, so an edit replaces the previous text outright and two agents editing the same pull request will overwrite each other without warning. The tool description says so at the point of use, which is the same answer this project gave for edit_issue.

Verification

Coverage is proved by mutation rather than assumed. Four separate mutations were applied to the new code, each anchored on a string confirmed unique beforehand, since the pull request path template is not unique in this client. Forwarding base, dropping the empty-edit guard, dropping enum enforcement on state, and changing PATCH to POST each produce a different failure, so no single assertion is doing all the work.