Releases: rubicon/forgejo-mcp
Release list
0.17.0
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.
0.16.0
forgejo-mcp v0.16.0 (2026-09-02)
create_repo had been in the elevated tier since #106 and had never once worked. It posts to an endpoint Forgejo gates behind write:user, which is the same scope that adds SSH keys and changes the account's email addresses, so granting it was never the smaller risk. Removing the tool leaves the tier with the one property worth having, which is that everything in it destroys something and nothing in it is there for another reason. The less comfortable find was sitting next to it. Two of the three places that tell you what to allowlist had been describing a four-tool tier since #127 added a fifth.
⚠ Breaking changes
create_repois removed. The elevated tier goes from seven tools to six, and the full surface from 60 to 59. There is no replacement: create repositories in the Forgejo web UI or with a token you control directly.
Fixed
- elevated: remove
create_repoand correct every tier enumeration (#144) (9faf8c3), closes #142 and #143. Thanks to Dax Davis.
Why the tool went rather than the scope
POST /user/repos returns 403 token does not have at least one of required scope(s): [write:user] for every token this server is designed to hold. The same scope gates POST /user/emails, POST /user/keys and POST /user/gpg_keys, so an elevated token carrying it could plant an SSH key that outlives the token that planted it. That is the account administration this project puts permanently out of scope, and no narrower scope exists: the organisation-scoped path needs write:organization and does not apply to a user account.
Documentation
The README tier table, the README security warning and ARCHITECTURE.md all still listed the four-tool tier from before #127 and #129. Two of those are allowlisting guidance, so a reader working from either would have believed they had enumerated the elevated surface while three irreversible tools were missing from the list they checked. All five places that name the tier now agree with the registry, and that agreement is checked rather than eyeballed.
Upgrading
If your client allowlist names mcp__forgejo__create_repo, remove the entry. It now refers to a tool that does not exist.
0.15.0
forgejo-mcp v0.15.0 (2026-08-31)
Since the first release this server could attach a milestone without being able to tell you which milestones existed, post a comment without being able to correct a typo in it, and write a file it had no way to remove. Twenty tools later, all three are closed, and the surface stops asking callers for identifiers it refused to hand out. The more useful find was in the check rather than the code: swapping the elevated token for the everyday one passed the whole suite, on a tool that had shipped in that tier since #106. The stub now records which credential actually arrives, so the trust boundary is asserted rather than assumed. Deleting a label, a release or a tag is elevated, because none of the three can be undone from here.
Added
- tools: add edit_issue for issue and pull request content edits (#131) (be49344), closes #123
- tools: add milestone tools (#132) (d6223e3), closes #124
- tools: add edit_issue_comment and delete_issue_comment (#133) (9110b7c), closes #125
- tools: add create_commit_status and list_commit_statuses (#134) (3a0479b), closes #126
- tools: add delete_file (#135) (8054511), closes #128
- tools: add label definition tools, delete_label elevated (#136) (5429673), closes #127
- tools: add release reads, edit_release, and elevated release and tag deletion (#137) (631543c), closes #129
- tools: let merge_pull_request request head-branch deletion (#121) (3b8d856), closes #120
The default surface goes from 36 tools to 53.
Elevated tier
The opt-in tier goes from four tools to seven. delete_label, delete_release and delete_tag join merge_pull_request, delete_branch, create_repo and delete_repo. Each was placed there on the same test as the rest of the tier, which is whether the damage can be undone from this server: a deleted label is stripped from every issue that carried it, release notes and assets never existed in git, and a tag may be the only pointer to its commits.
The double gate is unchanged. Nothing in this tier registers unless FORGEJO_MCP_ELEVATED=1, FORGEJO_TOKEN is set, and FORGEJO_MCP_ELEVATED_TOKEN differs from it. If you allowlist tools for unattended use, allowlist named default tools rather than the server.
Verification
The smoke check now records the Authorization header on every stub request and asserts that elevated tools travel on the elevated token while default tools do not. Before this release that boundary was invisible to the check, so an elevated tool running under the everyday credential would have passed. It also drives 44 real tool calls against a stub Forgejo, up from 23.
Known limitations
The token-scope review that this project requires whenever the elevated tier widens has not been done for create_repo, delete_repo, delete_label, delete_release or delete_tag. Separately, create_repo fails against a live instance when the token lacks write:user.
Full changelog: v0.14.0...v0.15.0
v0.14.0
v0.13.0
0.13.0 (2026-08-22)
⚠ BREAKING CHANGES
- list_directory returns { total_count, count, page, items } and fails on a path that names a file. Read the entries from items; use get_file_content for files.
Added
0.12.0
forgejo-mcp v0.12.0 (2026-08-20)
Finding open issues that mention you, updated this week, meant fetching pages and filtering them yourself. Both listing tools now take the filters their endpoints have always accepted, including text search, milestones, authorship, and sort. The two endpoints disagree about almost everything. Milestones go by name on one and by id on the other, and the sort values overlap without matching, so the tools mirror the API rather than inventing a tidier contract that Forgejo would ignore. Label filtering on pull requests was also being sent comma-joined to an endpoint that wanted repeated parameters, so it had been silently doing nothing.
Added
Full changelog: v0.11.0...v0.12.0
0.11.0
forgejo-mcp v0.11.0 (2026-08-20)
Labels could go on and never come off, which is a fine arrangement for tattoos and a poor one for issue triage. Removing one takes a name or an id, so resolving through the label list first is optional. It sits in the safe tier rather than behind the elevated gate: labels are metadata, reattaching is one call, and the timeline records it. The same work turned up that delete_branch, which permanently deletes branches, had no test coverage at all.
Added
Full changelog: v0.10.0...v0.11.0
0.10.0
forgejo-mcp v0.10.0 (2026-08-20)
Reviews could comment on a specific line as of the last release, with no way to discover which lines existed. The only route was the entire unified diff as one blob, to be parsed by the caller. Pull requests now list their changed files with status and line counts, paginated like everything else. The whitespace and skip-to parameters stay unexposed, since one is a cursor into a diff this tool does not return.
Added
Full changelog: v0.9.0...v0.10.0
0.9.0
forgejo-mcp v0.9.0 (2026-08-20)
A review that cannot point at a line says only that something, somewhere, is wrong. Reviews now carry inline comments anchored to a file and line, and a commit SHA so they stay attached to the diff that was actually read. Comments missing a path or a body are refused here rather than sent, because Forgejo accepts them and files a degraded review with a success response. Positions have to be whole numbers, which was not true until review pointed out that the schema said so and nothing checked.
Added
Full changelog: v0.8.0...v0.9.0
0.8.0
forgejo-mcp v0.8.0 (2026-08-20)
The workflow this server exists to support ends with closing an issue, which it could not do. That is now fixed, along with the discovery that every enum in the tool surface was decoration: nothing validated arguments before a handler ran, so any value at all reached the API. The review event enum was the dangerous one, since an unrecognised value does not error in Forgejo. It falls through to a pending draft and reports success, which is the bug from 0.5.0 arriving by a different road.
Added
Fixed
Full changelog: v0.7.0...v0.8.0