The reach is unusual for a tracker binding: Backlog's Git repositories are in scope, so a pull request can be opened, updated and commented next to the issue it closes. count_issues is the tool that changes how the rest get used — ask for the number first, fetch bodies only when the number justifies it. It is not a read-only surface either: project, issue, version and watch deletions sit in the same set as the reads, and the way to bound that is the toolset flag, which is also how you keep the catalogue small enough for a client to handle.
A server over the Backlog API, covering projects, issues, comments, wikis, documents, Git repositories and pull requests, watches and notifications.
- count_issues taking the same filter set as get_issues — assignee, status, milestone, category, custom fields, and created, updated, start and due windows — so a distribution question is answered without fetching issue bodies
- Issue relations maintained in both directions through get_related_issues, add_related_issue and remove_related_issue
- Pull requests in the project's own repositories: listed, counted, opened, updated and commented on, addressed by repoName or repoId
- Two generations of documentation side by side — wiki pages with add_wiki and update_wiki, and the newer document tree through get_document_tree and addDocument
- Watches and notifications as objects rather than UI state: a watch carries a note, can be marked read, and the unread counter can be counted or reset
- Toolsets switched on individually — space, project, issue, wiki, git, notifications, document — so a client with a tight tool budget carries only what it uses
- Responses kept in bounds: a fields parameter on the list tools returns only the columns you name, and a token ceiling truncates anything past 50,000 tokens by default
- Several Backlog organizations reachable from one server, each call routed by an organization argument that defaults to the one you nominate
BACKLOG_DOMAIN naming the space and BACKLOG_API_KEY for a user inside it; every call runs as that user, which get_myself will confirm. It runs from npx or the published Docker image, and for multiple spaces the domain and key are supplied per organization instead. Exposed over HTTP it binds to 127.0.0.1 by default and validates Host and Origin — anything wider needs an allowed-hosts list, and the port must not reach an untrusted network, since it hands out full use of the API key. Remote deployments can use OAuth instead, so each person authenticates as themselves. MIT.
One command plus a key — docker pull ghcr.io/nulab/backlog-mcp-server:latest, then supply credentials