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.
This server publishes no instructions, or was last inspected before Glama recorded them.
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. Returns task list with configurable fields. ROOT tasks only by default — a task with a parent belongs to that parent, so set children:true to include them. The response's hiddenChildren reports how many matched but were omitted. |
| get_taskB | Get a single task by ID with full details including comments and files. |
| get_projectA | Return the resolved project this server is attached to: name, absolute root, git branch and mode. Read-only; takes no input. |
| create_taskB | Create a new task with title, description, and metadata. LINKS merge: |
| update_taskA | Update an existing task. Supports status changes, title/description updates, adding comments, and changing the task's links (parent/relates/blocks). Pass setVerify to record your verification verdict: "pass" attests the task IS implemented correctly (verified=true, green badge — required for annotated tasks at the review transition, which LINKS — everything merges, and |
| claim_next_taskA | Claim the highest-priority ROOT task in todo and set it to in-progress. Never claims a child: a root is the unit of work, so work through its children after claiming it. Mirrors 'vibeflow tasks --next'. An empty board is a SUCCESS, not a failure: the result is then |
| add_commentB | Add a comment to a task. The body is |
| attach_fileA | Attach a file to a task (content as base64). A filename ending in |
| export_promptC | Export task(s) as formatted prompt for LLM consumption. |
| verify_taskC | Run visual verification on a task. Captures baseline and compares. |
| 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. Call it once before get_integration_guide so the guide carries real URLs. |
| 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 12 tools
Most tools target a distinct resource+action (task CRUD, comments, files, kanban server). However, add_comment duplicates update_task's documented comment-adding capability, and verify_task (visual verification) overlaps with update_task's setVerify verdict field, creating mild boundary confusion.
All 12 tools follow a consistent snake_case verb_noun pattern (list_tasks, get_project, create_task, update_task, claim_next_task, get_task, add_comment, attach_file, export_prompt, verify_task, start_kanban, get_integration_guide). No mixing of conventions or vague verbs.
12 tools is well within the healthy range and each earns its place: task lifecycle, comments/files, verification, and kanban/integration serving all map to distinct needs. No redundancy that bloats the surface.
Core lifecycle is covered (create, get, list, update, claim, plus comments/files/verification). The obvious gap is the absence of a delete_task tool, leaving no direct way to remove tasks, though status transitions can partially work around this.