Vibeflow
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PROJECT | Yes | Path to the project root. Required (`--project`). The project root is resolved once at startup and every tool call uses that root. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Project root: /app (name: vibeflow, branch: none, mode: local)
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_tasksA | List tasks with optional filters — the same listing as |
| get_taskA | Get a single task by ID with full details including comments and files. Pass |
| get_projectA | Return the resolved project this server is attached to: name, absolute root, git branch and mode. Read-only; takes no input and changes nothing. Call it when you need board location or branch context before operating on tasks. |
| create_taskA | Create a new task with title, description, and metadata. Pass |
| update_taskA | Update an existing task. Supports status changes, title/description updates, adding comments, and changing the task's links (parent/relates/blocks). Pass LINKS — everything merges, and |
| claim_next_taskA | Claim the highest-priority todo task and set it to in-progress: the returned object IS the claimed task. Roots first: a todo ROOT is claimed before any child — the root is the unit of work, so work through its children after claiming it. When no todo root is claimable, falls back to the highest-priority matching todo child of live work (parent chain todo/in-progress/review) and says so explicitly (a CHILD_CLAIM notice naming the parent); children of backlog/done parents are refused, never sliced off. Optional type/user/tag filters narrow the pool (tags every-match); pass dryRun to preview the claim without moving the task. An empty board — or a valid filter matching nothing — is a SUCCESS with a |
| add_commentA | Add a comment to a task without changing any of its fields. The body is |
| attach_fileA | Attach a file to a task (content as base64) without changing any of its fields. Re-attaching an existing filename overwrites its bytes in place — the file list gains no duplicate. Pass dryRun to validate without writing. A filename ending in |
| get_fileA | Download a file attached to a task, returned as base64 with its filename, content type and size. Give the task |
| pullA | Pull the online board into the local task store: the inverse of a push. ADDITIVE and never destructive — tasks and files the board holds are added or merged field-by-field into |
| verify_taskA | Run visual verification on a task with the Playwright engine: it loads the task's annotated page (url + selector) and compares the live element against the baseline captured at annotation time. MUTATES: every run appends a system comment with the outcome — pass dryRun to resolve the id and preview without launching a browser or writing anything. Pass |
| start_kanbanA | Start the local kanban board server and return the instruction block the CLI prints: the kanban URL, the localhost URL when bound to 0.0.0.0, the agent prompt, and the overlay integration guide. IDEMPOTENT — one server per process; a second call returns the running instance (alreadyRunning:true) instead of fighting for the port. Pass dryRun to report the URLs without binding anything. Call it once before get_integration_guide so the guide carries real URLs; skip it entirely for remote or Docker setups where a localhost server is unreachable. |
| get_integration_guideA | Get the overlay/bookmarklet integration instructions — the text of the /inject page: the script tag to paste, the browser-console snippet, the bookmarklet, and the /inject URL. Works whether or not the server is running; when it is not, the guide is built against the default port and the result says serverRunning:false, so call start_kanban first for real URLs. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools target clearly distinct operations (create/get/list/update task, attach/get file, claim, pull, start server), and the descriptions explicitly cross-reference each other to route the agent. The only real overlaps are update_task's `comment` field vs add_comment, and update_task's setVerify verdict vs verify_task running verification — both are called out in the text, so confusion is limited but possible.
The set is overwhelmingly consistent verb_noun snake_case (get_project, list_tasks, create_task, claim_next_task, add_comment, attach_file, verify_task, start_kanban). The lone deviation is `pull`, a bare verb, and get_integration_guide is longer than the rest, but the pattern is easy to read and predict.
13 tools is squarely in the well-scoped range and each one maps to a distinct lifecycle action (read, create, edit, comment, attach, claim, verify, sync, serve). Nothing feels padded or missing purely on count grounds.
The task surface has create/read/list/update, comments, attachments, claiming and verification, but there is no delete/archive task operation and no push tool even though `pull` is explicitly described as the inverse of a push. Agents can work around deletes via other means, but these are notable lifecycle gaps for a board server.