The intended move is not manual task entry — it is handing an assistant a specification and letting it decompose the work into issues and tasks itself, which is where the two-level structure earns its keep. Because the store is one JSON file, the result is reviewable and version-controllable rather than locked in a service. The active-issue model is the thing to remember: task calls land on whichever issue is currently selected, so selecting is a real step, not a convenience.
A file-based issue and task tracker exposed over MCP. Issues stand for features or bugs; tasks are the specific work items under one issue. One issue is active at a time, and task operations apply to it. Everything persists to a JSON file, so the backlog can be backed up, diffed or committed like any other file in the repository.
- Issues created with a name, an optional description and an optional status — `create_issue`
- Every issue listed — `list_issues`
- One issue made the active one, which is what later task calls apply to — `select_issue`
- An issue created or reset to a known state — `initialize_issue`
- An issue's status changed — `update_issue_status`
- A task added to the active issue with a title and optional description — `add_task`
- The active issue's tasks listed, optionally filtered by status — `list_tasks`
- A task moved between `New`, `InWork` and `Done` by task id — `update_task_status`
No account and no key — storage is a local file. Python 3.12 or higher with uv or pip; `uv pip install -e .` then `uv run backlog-manager` starts it. Configuration is environment variables: `TRANSPORT` picks `sse` or `stdio` (default `sse`), `HOST` defaults to `0.0.0.0`, `PORT` to `8050`, and `TASKS_FILE` to `tasks.json`. Over SSE the client connects to `http://localhost:8050/sse`; over stdio the client starts the process itself. A Docker image builds with `--build-arg PORT=8050`. The pyproject name is `backlog-manager` (0.1.0).
Build from source — clone the repository and build it, then point your client at the binary