Fronyboard
Project tracker for AI agents: roadmap, periods, tasks and a validation gate, in one SQLite file
- Transport
- Not stated
- Package
- —
- Registry id
- io.github.Cafelatte1/fronyboard
No install snippet on purpose. A working MCP config is a command, its arguments and an environment block — the last two are where API keys live, so this catalogue never stores them and cannot publish them. Follow the link above for the authors' own instructions.
An MCP server that gives AI agents (Claude Code and friends) a first-class project tracker.
Where Jira is an issue tracker for humans behind a web UI, FronyBoard replaces each part with something an agent can use natively:
| Jira | FronyBoard |
|---|---|
| Database | One SQLite file in a dedicated data directory |
| Records | JSON documents (roadmap, period) + Markdown |
| API | MCP tools |
| Workflow engine | Schema + rule validation, run as a gate before every write |
| State transition | An MCP tool call (transition_task) |
The schema and operating rules were extracted from a real product's management system (31 tasks shipped through it), then generalized.
Install
Requires uv. One line registers FronyBoard in Claude Code;
uvx fetches the package from PyPI on first use and caches it:
claude mcp add FronyBoard -- uvx fronyboard
Any MCP client that can launch a stdio command works the same way — the command is
uvx fronyboard. It is also listed in the
MCP Registry as io.github.Cafelatte1/fronyboard.
From a clone, point at the checkout instead (this needs git):
git clone https://github.com/Cafelatte1/fronyboard
claude mcp add FronyBoard -- uv run --directory <path-to-clone>\backend fronyboard
This is the local (stdio) mode: the client starts the server as a child process and
talks to it over a pipe. No HTTP, no network, no credentials — web.py and
fauth.py are never called. Data is written to %LOCALAPPDATA%\Frony\FronyBoard\data
(~/.Frony/FronyBoard/data where LOCALAPPDATA is unset); set AIRA_DATA_DIR to
relocate it. Logs (JSON Lines, one line per MCP tool call plus server events) go to
the sibling logs folder — FRONYBOARD_LOG_DIR overrides.
To share one FronyBoard between several machines, or to use it from the Claude and ChatGPT apps, run it as an HTTP server instead — see docs/self-hosting.md.
Project setup
Connecting the MCP server gives every session the tools and the general workflow
(delivered as server instructions). What it cannot know is which FronyBoard project
a codebase belongs to — declare that in the codebase itself by adding this section
to its CLAUDE.md (create the file if the project has none):
## FronyBoard
This project is tracked by FronyBoard (project key: DLY).
Manage tasks through the FronyBoard MCP tools, following the FronyBoard server instructions.
Replace DLY with the project's key (register one first with create_project).
The section is also the opt-in signal: a codebase without it is treated as not
FronyBoard-managed.
Model
fronyboard.db
├── projects one row per project (key e.g. DLY): the roadmap record —
│ yearly overview (goal / now / target / checklist) + quarterly milestones
└── periods one row per opened period (e.g. 2026Q3): tasks ({KEY}-001, ...)
+ `result` (retrospective, written when the period closes)
A project is two kinds of records — the roadmap, and one record per period. Both are
JSON documents; the schema and the rules that guard it are in
backend/src/fronyboard/validation.py.
From the project's README.