FronyBoard
Project tracker for AI agents: roadmap, periods, tasks and a validation gate, in one SQLite file
Connector by Cafelatte1 · GitHub account verified by the MCP Registry
Install
Works with Claude Code, Codex, VS Code, Cursor, Windsurf, Claude Desktop. Read the repository before you give any tool access to your data.
npx agentmarket install connector/cafelatte1-fronyboard
Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.
Get the weekly diff
The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.
About
Reviews
Write a reviewNo reviews yet. Installed it? Reviews come from verified installers only. How reviews work
Permissions
What this server can do and what it asks for, from its tool list, install config and code. Checked Oct 25, 2026.
- Tools
- 8 read · 9 write · 0 delete · 2 not yet classified
- Secrets
- None asked for
- Install scripts
- None found
- Runs as
- Python package
Tools by what they do 19
Read from the source code; the running server may list different tools.
Read 8 · Look things up without changing anything.
get_retrospectiveget_roadmapget_statusget_tasklist_projectslist_taskssearch_tasksvalidate
Write 9 · Create, change, send or run things.
close_periodcreate_projectcreate_taskset_checkset_overviewtransition_taskupdate_projectupdate_taskupsert_milestone
Not yet classified 2 · We could not tell from the name and description.
open_periodrecent_activity
Secrets and settings it asks for
Other settings (environment variables or headers).
AIRA_DATA_DIR
Network hosts it talks to 3
board.frony.app· found in codegithub.com· found in codeglama.ai· found in code
Files it touches
- Your home directory (~)
Tools (19)
Read from the source code; the running server may differ. Descriptions are the server’s own words; hidden characters are shown as [U+…].
close_periodClose a period (YYYYQn) and record its retrospective — call when its work is over. Refuses while any task is still todo or in_progress. Stores `result_markdown` as the period's `result` and marks its milestone, if it has one, done. The retrospective is written in the user's language, stays under ~30 lines and holds judgment and reasons only — summary vs goal, what landed and what did not, carried-over tasks (old id -> new id), lessons. Calling it again on a closed period rewrites the retrospective and changes nothing else.
create_projectRegister a new project — once per codebase, before any planning happens. `key` is the task-id prefix (2-5 uppercase letters, e.g. DLY); `description` is one line saying what the project is, in the user's language (shown on the dashboard cards); `repo` is where its code lives (owner/name or a URL). Status starts as active. A fresh project takes tasks at once: create_task opens the current quarter. The plan (set_overview, upsert_milestone) is optional and written with the user.
create_taskCreate a task — one issue/branch-sized unit of work — with status todo. The id is assigned from the project-global sequence and never reused. `period` is YYYYQn: the current quarter (in the server's time zone) opens by itself if it is not open yet, and the answer then carries `opened`; any other quarter must already be open (open_period). Nothing else — no overview, no milestone — has to exist first. `title` is a short English imperative ("Add multi-select status filter") — it is what every reader sees, so it has to say the whole thing. `content` is optional: one line, at most 300 character…
get_retrospectiveRead a closed period's (YYYYQn) retrospective — the `result` markdown close_period wrote. Errors while the period is still open; get_status says which ones are closed.
get_roadmapRead a project's plan as written: yearly overviews (goal, now, target, checklist), quarterly milestones, and the names of its periods. Goals only, no counts — get_status for progress and the current period, list_tasks for the tasks themselves. Timestamps (`meta`) are left out unless `include_meta` is set.
get_statusThe resume: everything an agent needs to pick a project up cold, in one call. The latest year's overview (goal / now / target / checklist); per period its milestone goal and status (a period without a milestone has no goal and reports active while open, done once closed), task counts by status, whether it is closed, and `open_tasks` — every todo / blocked / in_progress task with its title, tags, branch, one-line content and `waiting_on`; and `recent_done` — the ten most recently finished tasks across every period, newest first, each with its content, its `check` and when it completed. Closed p…
get_taskRead one task in full by id (DLY-042) — the project comes from the prefix, so no key is needed. Returns the record with its period. Use this instead of list_tasks whenever you already know the id; search_tasks when you only know a word from it. The record also carries `waiting_on` when it applies.
list_projectsList every project (key, name, description, repo, status, meta) — how to find out which keys exist. Archived ones are left out unless `include_archived` is set. Each entry carries a `summary`: its open periods, task counts by status and `last_activity` (the newest task update). No milestones or task detail: get_roadmap for the plan, get_status for per-period progress, list_tasks for the tasks.
list_tasksList one project's tasks, optionally narrowed by period, status, tags or recency. get_status already lists the open ones; use this for done or cancelled tasks, a closed period, or a tag cut. get_task when you know the id, search_tasks for text across projects. `period` is YYYYQn (all periods, closed ones included, when omitted), `status` is one of todo | in_progress | done | blocked | cancelled. `tags` narrows to the tasks carrying *all* of the given labels; pass one tag to match on it alone, and call again per tag when you want the union. `updated_since` keeps tasks touched after a duration …
open_periodOpen a quarter's period (YYYYQn, e.g. 2026Q3) other than the current one — create_task opens the current quarter by itself, so this is only for filing work under another quarter. No milestone is needed; if the quarter has a planned one, it flips to active.
recent_activityWhat changed recently and who did it: the tool calls recorded in tools.jsonl, newest first — `ts`, `tool`, `caller` (key:<name> / session:<user> / oauth:… / stdio / local), `project`, `task` and `args` (argument names; prose fields appear as `<name>_len`); `ok: false` marks a rejected call. This is the mutation history; task records themselves keep only timestamps. `since` is a duration ("24h" default, "7d", "90m") or an ISO timestamp; `key` narrows to one project; `limit` caps the rows (default 50) while `count` reports the total. Read-only calls are dropped unless `writes_only=False`.
search_tasksFind tasks by text across all projects, with the dashboard's rules: case-insensitive substring over project key, task id, title and content (not branch or tags); a matching project key returns all of its tasks. Closed periods are included; cancelled tasks only with `include_cancelled` (or `status='cancelled'`). Hits are compact, ordered by project, then in_progress -> blocked -> todo -> done -> cancelled, then id; `match` says which field hit; a task's one-line `content` is included when it has one. `key` narrows to one project, `limit` (default 20) caps the hits while `count` still reports t…
set_checkTick or untick one item of a year's overview checklist: `index` is its 0-based position in get_roadmap's `checklist`, `done` the new state. Returns the updated overview. To add, remove or reword items use set_overview.
set_overviewCreate or replace a year's overview: the one-line yearly `goal`, plus the three blocks the dashboard shows for the current year — `now` (what is being worked on), `target` (what that work is meant to reach) and `checklist` (the concrete steps to get there, ticked off as they land). A year needs an overview before upsert_milestone will add a quarter to it. `year` is YYYY. All prose here is in the user's language. `now` and `target` are one short line each. `checklist` items are strings (not done yet) or {text, done} maps, in display order. Calling it again replaces the whole overview — resend …
transition_taskMove a task to a new status: todo | in_progress | done | blocked | cancelled. The only tool that changes status — title, content and tags are update_task. `task_id` is the full id, e.g. DLY-042; the project is derived from that prefix, so `key` may be omitted (if given it must match). Call when work starts (in_progress, ideally with the branch name) and when it finishes (done); the server stamps started_at and completed_at itself. `done` requires `check`: one line, at most 300 characters, saying **what proves the work done** — the command you ran and what it printed ("uv run pytest -q: 96 pa…
Show 4 more tools
update_projectUpdate a project's own fields — pass at least one of name, description, repo, status. The key (and with it the task id prefix) never changes, and nothing here touches the roadmap, periods or tasks. `name` and `description` follow create_project's language rule. `status`: active | paused | archived. paused only changes the badge; archived hides the project from list_projects and refuses every other mutation until it is set back to active. Archived is as far as removal goes — there is no hard delete.
update_taskUpdate a task's fields — everything except status, which is transition_task. `branch` records the working branch name; `content` replaces the one-line note (same rule as create_task: one line, at most 300 characters). `check` corrects the proof recorded at completion and is only accepted on a task that is already done. `tags` replaces the whole label list — pass the tags the task should end up with, not just the new ones. `depends_on` likewise replaces the whole predecessor list. Omitted fields are left as they are. To remove an optional field pass an empty value: `content=""`, `branch=""`, …
upsert_milestoneCreate or update a quarterly milestone — a year's goal for one quarter. `year` is YYYY (its overview must exist), `quarter` is Q1-Q4, `goal` is one line in the user's language (a new milestone needs one), `status` is planned | active | done (opening the period flips planned to active, close_period sets done; a milestone added to a quarter already open starts active). Omitted fields keep their current value. A milestone is optional — tasks never need one.
validateCheck a project's stored data against the FronyBoard schema and rules, returning errors and warnings. Rarely needed on its own — every mutation runs this same gate and refuses to write when it fails. Use it after the store was edited outside these tools.
Signals
- Stars
- 0
- Forks
- 0
- Open issues
- 0
- Weekly downloads
- 219
- Last commit
- Oct 24, 2026 (5 days ago)
- Last release
- Oct 24, 2026 (5 days ago)
- Last package publish
- Oct 23, 2026 (6 days ago)
From GitHub (fetched Oct 24, 2026) and the package registry.
Details
- Registry name
io.github.Cafelatte1/fronyboard- Version
- 0.40.0
- Auth
- No auth
- Packages
- pypi fronyboard
- License
- MIT
- Repository
- github.com/Cafelatte1/FronyBoard
- First seen
- Oct 24, 2026
- Last checked
- Oct 25, 2026
Cite this page
FronyBoard MCP server. Agent Mart. https://agentmart.dev/connectors/cafelatte1-fronyboard (last updated 2026-10-25)