forgejo-mcp-rs

A Model Context Protocol server for Forgejo, Codeberg and Gitea. It lets an MCP client (Claude Code, Claude Desktop, …) read your forge — the authenticated user, repositories, issues, and pull requests — over the Forgejo/Gitea REST API.

Status: read-only by default, with opt-in guarded writes (since v0.2). Read tools across the forge — user, repos, issues, pull requests, search, orgs, notifications, comments, reviews, and Actions (CI) runs — plus guarded writes (create_repo, edit_repo, create_branch, create_issue, create_pull_request, comment_on_issue, delete_repo, migrate_repo, push-mirror management, and dispatch_workflow) gated behind a separate write token and a deliberate, time-boxed write mode. See SPECIFICATION.md for the full design.

It speaks the Forgejo REST API directly through a small, in-house client (src/forgejo/client.rs, over the src/mcp_core/ transport) — an independent implementation over the documented API, not a port of any other server. There is no third-party forge SDK in the trust path, so the tool surface holding your token is code you can read and audit end to end.

The server speaks MCP protocol version 2026-07-28 (since v0.16) and negotiates down to 2024-11-05, so older clients keep working unchanged. It runs over stdio and exposes tools only — no resources, prompts, sampling, or roots.

Build

cargo build --release   # target/release/forgejo-mcp-rs
cargo install --path .  # install to ~/.cargo/bin

Related MCP server: GitHub Read MCP Server

Woodpecker CI

A companion server for Woodpecker CI shipped in this crate as a second woodpecker-mcp binary from v0.13.0 through v0.17.0. It now lives in its own repository and crate: woodpecker-mcp.

Woodpecker is its own system — it drives Gitea, GitHub, GitLab, and Bitbucket as readily as Forgejo, and that server never called the Forgejo API at all — so bundling it here made it invisible to everyone not running Forgejo. Nothing about it changed in the move; if you were using the woodpecker-mcp binary from this crate, install it from the new crate instead and point your MCP client at the new path.

Configure

The server is configured by environment variables:

Mint a token at Codeberg → Settings → Applications (or your instance's equivalent). For the read tools, read scopes (read:repository, read:issue, read:user) suffice. The write token needs write:repository (including delete, and the repo-admin push-mirror endpoints).

A read token is mandatory: the server refuses to start on a write token alone, and the read token must be a different token from FORGEJO_TOKEN_WRITE — you can't shortcut by reusing the write token for reads.

Forgejo 15+ token scoping. Forgejo 15.0 tightened authorization on many repository APIs to match its fine-grained, repository-scoped access tokens. Classic broad tokens are unaffected, but if you mint a repository-scoped token it must actually carry the scopes above — in particular the repo-admin scope for the push-mirror tools, which otherwise return 403. Scope the token to every repo you intend to reach.

Forgejo and Gitea

Forgejo began as a Gitea fork, and the REST surface is still very nearly the same one. Of the ~25 endpoints this server calls, only the Actions (CI) ones differ. Issues, pull requests, diffs, PR files, branches, file contents, search, orgs, notifications, push mirrors, and migration are identical in path, method, and response shape on both, so they need no special handling and get none.

The flavor is detected once, lazily, from the instance's GET /version — and only the Actions tools ever ask. Set FORGEJO_FLAVOR to forgejo or gitea to pin it if the detection ever guesses wrong on your instance.

The detection reads oddly on purpose: Forgejo names Gitea in its own version string (Codeberg reports 16.0.0-dev-741-6f391573+gitea-1.22.0) to advertise API compatibility, while Gitea never names itself (1.27.0+dev-954-g1f3981a301). So a gitea- marker means Forgejo. Failing that marker, the major version decides: Gitea is still 1.x, Forgejo renumbered to 7 and beyond.

Where the two forges differ, and what the server does about it:

Translating rather than sending both spellings is deliberate: an unknown query parameter is ignored, not rejected, so sending Forgejo's ref to Gitea would silently return unfiltered runs — a filter that looks applied but isn't.

Gitea's path deserves its own warning, because the name lies: it is not a filesystem path. It is the workflow file, an @, and the fully-qualified ref — ci.yml@refs/heads/main, or test-pr.yml@refs/pull/1117/head. It is also the only reliable source of the ref, since head_branch is populated for branch runs and null for tags and pull requests.

Two more things regardless of flavor. Gitea requires a token for the Actions API even on public repositories. And get_workflow_run deliberately returns the instance's full, unmodified run object, so that one is shaped differently on each forge; use list_workflow_runs when you want the normalized view.

Write mode

The server is read-only by default. create_repo / edit_repo / delete_repo work only when (a) FORGEJO_TOKEN_WRITE is configured and (b) you've deliberately entered write mode via enable_write_mode — a time-boxed elevation (default 10 min, max 60) that slides forward on each write and auto-reverts. write_status reports the state; delete_repo also requires a confirm argument equal to "owner/repo".

enable_write_mode, disable_write_mode and write_status all report the instance they apply to, and the elevation note names it in prose, so the announcement reads "write mode is active on https://gitea.com/" rather than a bare "write mode is on". That matters once you run more than one of these servers at once — a Codeberg one and a Gitea one, say — where each has its own independent write mode and an unqualified warning tells you nothing about which forge is now writable. write_status deliberately never calls the instance, so its flavor is null until something else has detected it. See SPECIFICATION.md for the full design.

Migration source token (optional)

Only needed if you'll use migrate_repo against a private source. Public sources need no credential — skip this entirely.

Note the direction: every other variable here authenticates to your instance (FORGEJO_URL). FORGEJO_MIGRATE_TOKEN authenticates to a different instance — the one you're copying from.

1. Mint a token on the source instance (its Settings → Applications), not on your own.

2. Give it read scopes only — read:repository, plus read:issue if you're migrating issues and PRs. It never needs write: the migration only reads from the source.

3. Set it as FORGEJO_MIGRATE_TOKEN in the same env block as your other tokens.

4. Call migrate_repo with auth_username set (or authenticate: true for token-only forges like GitHub). Without one of those the token is not sent at all.

Understand where this token goes before you set it. Your read/write tokens travel as an Authorization header to FORGEJO_URL and nowhere else. This one is different: it goes in the request body, and your destination instance then presents it to the source host on your behalf. The destination sees it in cleartext. That's inherent to any server-side migration API, not a choice this server makes — but it means you're extending trust to the destination operator. Scope the token to the single repository if your source supports it, and revoke it once the migration lands.

With mirror: true the destination must retain the credential to keep re-fetching, so it will persist in that instance's database rather than being used once and discarded. Prefer a one-shot migration unless you actually want an ongoing pull mirror.

Wire it into Claude Code

claude mcp add --scope user forgejo /path/to/target/release/forgejo-mcp-rs \
  --env FORGEJO_URL=https://codeberg.org \
  --env FORGEJO_TOKEN_READ_ONLY=your_read_token_here
# add --env FORGEJO_TOKEN_WRITE=… only if you want the (gated) write tools
# add --env FORGEJO_MIGRATE_TOKEN=… only to migrate from a *private* source instance

Or Claude Desktop

{
  "mcpServers": {
    "forgejo": {
      "command": "/path/to/target/release/forgejo-mcp-rs",
      "env": { "FORGEJO_URL": "https://codeberg.org", "FORGEJO_TOKEN_READ_ONLY": "your_read_token_here" }
    }
  }
}

Point FORGEJO_URL at a Gitea instance and everything works the same way — the flavor is detected for you:

{
  "mcpServers": {
    "gitea": {
      "command": "/path/to/target/release/forgejo-mcp-rs",
      "env": { "FORGEJO_URL": "https://gitea.com", "FORGEJO_TOKEN_READ_ONLY": "your_read_token_here" }
    }
  }
}

Logs go to stderr (stdout is the MCP transport); control verbosity with RUST_LOG, e.g. RUST_LOG=forgejo_mcp_rs=debug.

Tools

Read list tools accept optional state (open/closed/all) and page/limit. Called with no paging, list_my_repos / list_issues / list_pull_requests auto-paginate the whole set and return a { returned, total, truncated, items } envelope; pass an explicit page or limit for a single page, which returns { page, limit, returned, total, items } instead (total is null for search_repos, which reports no count). Repository, notification, comment, and review results are slimmed to the fields that matter. The write tools require write mode (above); editing existing issues/PRs is future work — see the specification.

Moving a repo between instances

migrate_repo wraps Forgejo's POST /repos/migrate, which you call on the destination — clone_addr points at the source. Unlike a push mirror, which replicates git refs and nothing else, this can bring the issues, PRs, labels, milestones, releases and wiki with it. Three things to know:

• Set service. It defaults to git, a bare clone that copies refs only. Name the source forge (gitea for a Forgejo or Codeberg source — there is no forgejo value) to enable the API-based importer that the metadata flags depend on.

• The content flags default to off. issues, pull_requests, labels, milestones, releases, wiki and lfs are each opt-in, matching the API's own defaults.

• It's asynchronous, and it's a copy. The call returns a repo record immediately while the import runs in Forgejo's task queue, so poll get_repo to see it land. The source repository is never modified — retiring it is a separate, deliberate step.

Pass mirror: true to keep the result as a pull mirror that periodically re-fetches from the source, instead of taking a one-shot copy.

For a private source, set auth_username (or authenticate: true for token-only forges) and the server sends FORGEJO_MIGRATE_TOKEN as the credential. As with push mirrors, the token is never a tool argument, so it stays out of the conversation. See Migration source token for how to mint and scope it — and for where it ends up, which is not where the other tokens go.

Release assets

Notes that were written before the build finished are corrected with edit_release, not by recreating the release — deleting one takes its assets with it. It sends only the fields you pass, so changing the body leaves the title and draft state untouched.

Publishing a build is three calls: look the tag up with get_release, create_release if that 404s, then upload_release_asset per file. Re-running is safe as long as you delete a same-named asset first — Forgejo keeps both otherwise, rather than replacing.

upload_release_asset is the only tool that reads the local disk, and whatever it reads becomes a publicly downloadable file. So it is confined rather than trusted:

• Off unless configured. With FORGEJO_UPLOAD_ROOT unset, every upload is refused. There is deliberately no fallback to the working directory: an MCP server's cwd is whatever its client happened to launch it from, which is no basis for deciding what may be published.

• Confined to that root. The path is resolved through symlinks before the check, so neither a .. traversal nor a symlink pointing out of the tree escapes it.

• Bounded. Regular files only, at most FORGEJO_UPLOAD_MAX_MB (default 100).

• Plain names only. The published name defaults to the file's own and may not contain path separators, since Forgejo takes it verbatim.

Point the root at the tree you actually release from, not at $HOME:

"env": {
  "FORGEJO_UPLOAD_ROOT": "/Users/you/Developer",
  "FORGEJO_UPLOAD_MAX_MB": "100"
}

Forgejo vs Gitea

The server talks to both from one binary, detecting the flavor from GET /version. Of the ~25 endpoints it calls, the two forges agree on all but Actions — but where they disagree, they disagree completely, so this is the reference for what gets translated and what does not.

Everything below was checked against the two published specs, codeberg.org/swagger.v1.json and gitea.com/swagger.v1.json, compared definition by definition. The three points marked live could not have come from the specs at all: they type the fields in question as bare strings.

A workflow run is a different object on each forge

Gitea copied GitHub's vocabulary, Forgejo kept its own. The definitions are not even named alike — Forgejo's ActionRun against Gitea's ActionWorkflowRun — and of the fields worth reading, only id, event and html_url are spelled the same:

Three things are visible only from live data:

• live — path is not a path. Gitea reports ci.yml@refs/heads/main: workflow file, @, fully qualified ref. Reading it as a file path yields head as the "workflow", which is what this server's first live probe returned.

• live — head_branch is null for tag and pull-request runs, so the ref has to come out of path.

• live — unset means "", not null. A running Gitea run has conclusion: "" and completed_at: "". A consumer that decodes those as dates fails on the empty string, so a single queued run can fail a whole listing.

Gitea's status reports only queued / in_progress / completed, with the result arriving separately in conclusion once the run ends. This server promotes the conclusion into status, where Forgejo already puts the outcome, and keeps it verbatim alongside, so "did this pass?" is one question on both.

The output field names in the last column are this server's own, not either forge's. Do not read them as the wire format.

Requests differ too

An unknown query parameter is ignored rather than rejected, so the wrong spelling returns unfiltered results instead of an error:

Unfiltered, the listing path is identical on both. dispatch_workflow differs as well: return_run_info is a Forgejo extension and Gitea rejects unknown body fields on that endpoint, so it is sent only to Forgejo — which is why Gitea answers with an acknowledgement rather than the run.

Everything else

Issues, pull requests, diffs, PR files, branches, contents, search, orgs, notifications, push mirrors and migration are identical in path, method and response shape. Each forge does carry fields the other lacks, but they are extras rather than disagreements — Forgejo has pronouns on a user and archive_download_count on a release; Gitea has time_estimate on an issue and branch_count on a repository.

The one real exception outside Actions is the contents endpoint, where each forge has a last-commit field the other does not:

This server does not read those fields, but anything rendering a file listing needs both spellings or the date column comes out blank on one forge.

Security

The token is read from the environment only — never logged, never written to disk (the client holds it in a zeroized buffer and marks the Authorization header sensitive). Read-only by default, so the server cannot modify your account without a separate write token and write mode. Tool output is untrusted, repo-derived text — the server flags it as data, not instructions. See SPECIFICATION.md.

The two remote credentials — FORGEJO_MIRROR_TOKEN and FORGEJO_MIGRATE_TOKEN — get the same in-process handling (environment only, zeroized, never a tool argument, never returned), but they are not header credentials and so do not stay between you and your own instance: each is sent to your instance in a request body and relayed onward to a third-party host, which sees it in cleartext. That is how Forgejo's mirror and migration APIs work, not a choice this server makes. Scope both narrowly and treat them as disclosed to the remote operator.

Quality checks

cargo fmt --all
cargo clippy --all-targets -- -D warnings
cargo test
cargo deny check          # cargo install cargo-deny

CI runs the same on Codeberg Forgejo Actions; a tracked .githooks/pre-push hook mirrors it locally (git config core.hooksPath .githooks).

History

Per-release changes are in CHANGELOG.md; the design rationale behind each is in SPECIFICATION.md.

Releases through v0.5 were built on the forgejo-api crate by Cyborus. forgejo-mcp-rs now talks to the Forgejo REST API through its own small client and carries no third-party forge SDK.

The companion Woodpecker CI server that shipped here as a second binary from v0.13.0 to v0.17.0 moved to its own repository at v0.18.0 — woodpecker-mcp.

License

MIT — see LICENSE.md for details.

MCP registry

Ownership-verification token for the MCP registry (read from this crate's rendered README on crates.io):

Registry ownership token: mcp-name: io.github.brechanbech/forgejo-mcp-rs