Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PROJECTYesPath 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_tasksA

List tasks with optional filters — the same listing as vibeflow tasks (same filters, same scope, same order). Unfiltered: ROOT tasks only (a child belongs to its parent's card — set children:true to include them). Filtered (status/type/user/tag/search): an explicit search returning EVERY match, children included. search is a fuzzy relevance search over title, description, comments and tags (same shared matcher as vibeflow tasks --search and the v0 q param: every whitespace-separated token must match as an ordered subsequence of one field, case-insensitive and typo-tolerant, AND across tokens; spans every status with matching children always included; ranked by score asc then id asc, named in the order echo). Counts are labelled by scope: totalMatching (every match), totalRoots (matching roots), hiddenChildren (matches omitted by root-only scope), returned (rows in tasks), limit (echoed RESOLVED — 0 is not supported and falls back to the default of 20, named in limitNotice; there is no unbounded mode, page with nextCursor or CLI --all for everything), truncated + hint (present only when the limit cut rows). Position: offset (0-based index of the first returned row), remaining (rows in THIS query's scope NOT in this response — totalRoots-based when root-only, totalMatching-based otherwise, so offset + returned + remaining always equals the scope size; 0 means exhausted), nextCursor (opaque continuation, null exactly when exhausted), order (the effective sort applied, so a continuation is stable). Projected rows (fields) always carry commentCount/fileCount even when the arrays are omitted. Use it to browse or search the board; use get_task when you already hold an id, and claim_next_task when you want the next unit of work claimed rather than just listed.

get_taskA

Get a single task by ID with full details including comments and files. Pass fields (e.g. ["id","title","status"]) for a compact projection instead of the full record. Read-only; changes nothing. Use it when list_tasks gave you an id or you already hold one; use list_tasks to search the board, and claim_next_task to pull the next unit of work.

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 fields (e.g. ["id","title","status"]) for a compact answer instead of the full task object; pass dryRun to validate without writing anything. LINKS merge: links ADDS every listed taskId+type pair to the new task and parent (when given) is folded into the same union, so sending both merges once and a pair named twice is a no-op — the same MERGE semantic update_task has, where a link you do not name is simply absent (a new task has nothing to preserve). links: [] is REFUSED — omit the field for no links. Use it for a new unit of work; use update_task to change an existing task, and add_comment to discuss one without editing it.

update_taskA

Update an existing task. Supports status changes, title/description updates, adding comments, and changing the task's links (parent/relates/blocks). Pass fields (e.g. ["id","status"]) for a compact answer instead of the full task object; pass dryRun to preview the edit without writing anything, and branch to record the work branch (required on the review transition when the project sets createBranch). REVIEW GATE (same rules as vibeflow tasks --edit, same codes): status "review" REQUIRES comment (refused REVIEW_COMMENT_REQUIRED); an ANNOTATED task (url + selector) additionally REQUIRES a verdict (setVerify pass/fail/cannot — refused VERIFY_REQUIRED); commitMessage is REQUIRED when auto-commit is ON (refused COMMIT_MESSAGE_REQUIRED); a Research task must NOT carry a verdict (refused RESEARCH_VERIFY_NOT_ALLOWED — submit Research with its .md report, no verdict). 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 vibeflow verify never sets itself), "fail" records that it is NOT implemented correctly (verified=false, amber badge, the review gate rejects it), and "cannot" clears the verdict back to absent (no badge) for a task that cannot be assessed here — "cannot" REQUIRES verifyReason, which is recorded in the task's activity. Use it to change a task you already hold; use add_comment to discuss without changing fields, and verify_task to actually RUN visual verification (a verdict here records an assessment, it runs nothing).

LINKS — everything merges, and clearLinks is the only destructive path. links and addLinks both MERGE: a link you do not name is PRESERVED, and re-sending a link that is already there is a no-op, so neither of them can destroy a link by being incomplete. removeLinks removes exactly the taskId+type pairs you name and leaves every other link alone. clearLinks: true is the ONLY way to remove links wholesale — to drop a single link, name that taskId+type in removeLinks rather than editing links. Omitting all four fields leaves links untouched. The CLI's --set-parent/--relates/--blocks/--unrelates/--unblocks behave the same way (each is surgical and preserves every link it does not name), so the CLI and MCP surfaces now agree on link semantics.

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 null result, the same as 'vibeflow tasks --next --json' reporting task:null with exit 0. Use it to pull the next unit of work; use list_tasks to browse without claiming, and get_task to inspect a task you already hold.

add_commentA

Add a comment to a task without changing any of its fields. The body is comment — the same name as the CLI's --comment flag and update_task's field. author defaults to agent; pass dryRun to validate without writing. Use it to discuss or record progress; use update_task's comment when the note accompanies a status or field change (review REQUIRES the note on the same call).

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 .md is what satisfies the research-report gate: a type:"Research" task is refused review with RESEARCH_REPORT_REQUIRED until a .md is attached, so attaching the report is how to recover from that refusal. Use it for reports, screenshots and evidence; use add_comment for discussion text.

get_fileA

Download a file attached to a task, returned as base64 with its filename, content type and size. Give the task id plus the attached filename (either mode) or the online fileId (remote mode only). Read-only; changes nothing. Use it to read back an attachment the file list only names — the remote list carries no bytes, so this is how an agent actually sees the content.

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 .vibeflow/, local-only data is never dropped, and nothing is ever deleted. On a conflicting field the LOCAL value wins by default, except status, which follows the remote record (the board is truth for workflow state) unless preferLocal restores local-wins for it; pass preferRemote to let the remote value win on every conflicting field instead. A second pull of an unchanged board is a byte-no-op (unchanged tasks are not rewritten, identical files untouched). Pass dryRun to preview the pull without writing anything. Use it to bring a board's tasks and file bytes local after working in another checkout or on the web; use list_tasks to browse without writing, and push to send local work up.

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 url to check a different app URL for this run only, and timeoutMs (default 60000, refused VERIFY_TIMEOUT past it) for slow apps. A task with no baseline refuses with E_NO_BASELINE (re-annotate in vibeflow kanban to capture one); an unknown id with E_NOT_FOUND. Use it to check an annotated task before review; use update_task's setVerify to record the human verdict (this tool never sets it).

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 13 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness3/5

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.

Maintenance

ActivityActive
ResponsivenessSyncing