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.

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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: 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.

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 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.

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 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 null (an object means a task was claimed, null means there was nothing to claim), the same as 'vibeflow tasks --next --json' reporting task:null with exit 0. A valid filter that matches no task is the same situation and gives the same null.

add_commentB

Add a comment to a task. The body is comment — the same name as the CLI's --comment flag and update_task's field.

attach_fileA

Attach a file to a task (content as base64). 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.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.6/5.0

Scored across 12 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityActive
ResponsivenessNo issues