Skip to main content
Glama
quochuy
by quochuy

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
COORDINATION_DIRNoAbsolute path to the shared coordination directory. Both clients must point to the same directory. If unset, defaults to the .ai/coordination directory relative to the current working directory.<cwd>/.ai/coordination

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
create_taskA

Create a new coordination task for an implementer (e.g. OpenCode) to pick up. Starts in status 'pending'.

list_tasksA

List coordination tasks, optionally filtered by status, assignee, creator, or tag. Returns a lightweight summary per task (no history[], plus a computed idleSeconds while claimed/in_progress) so repeated polling stays cheap — call get_task for the full record including history.

get_taskA

Fetch full details for a single task by id, including its status, version, and history.

search_tasksA

Full-text search over task titles, descriptions, and tags (case-insensitive substring match). Returns the same lightweight summary shape as list_tasks (no history[]) — call get_task for the full record.

claim_taskA

Claim a pending task as the implementer working on it. Fails if the task was pre-assigned to someone else. Returns the task summary (no history[] — call get_task for that).

claim_next_taskA

Atomically claim the first eligible pending task (optionally filtered by tag) instead of a separate list_tasks + claim_task round trip. Skips tasks pre-assigned to someone else. Returns null if no eligible pending task is available, otherwise a task summary (no history[] — call get_task for that).

complete_taskA

Mark a claimed/in-progress/revision-requested task as completed and ready for the creator to review. Returns the task summary (no history[] — call get_task for that).

cancel_taskA

Cancel a task that is not already completed/approved/cancelled. Returns the task summary (no history[] — call get_task for that).

reopen_taskA

Reopen a cancelled/completed/approved task back to pending, clearing its assignee and prior progress so it can be re-claimed. Returns the task summary (no history[] — call get_task for that).

approve_taskA

Approve a completed task (typically called by the creator/reviewer after checking the implementer's work). Returns the task summary (no history[] — call get_task for that).

request_revisionA

Send a completed task back to the implementer for changes. Posts the feedback as a message on the task's thread. Returns the task summary (no history[] — call get_task for that).

post_messageA

Post a message to a task's conversation thread (e.g. clarifications, review feedback, status notes).

get_messagesA

Fetch a task's conversation thread, optionally only messages after a given ISO timestamp.

update_progressA

Report progress (0-100, whole numbers) on a claimed/in-progress/revision-requested task. The first call in a claim or revision cycle automatically advances the task's status to 'in_progress'. Rejects tasks not currently open for work (pending, completed, approved, cancelled). Returns the current snapshot (no history[] — call get_progress for that).

get_progressA

Fetch the latest progress snapshot (and history) for a task. Returns null if no progress reported yet.

wait_for_taskA

Block (polling, lock-free) until a task's status changes, or until timeout_seconds elapses — use instead of repeatedly calling get_task in a loop. Without until_status, returns as soon as status differs from its value at call time; with until_status, waits specifically for that status. Timing out is a normal result (timed_out: true), not an error — re-call to keep waiting.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4/5.0

Scored across 16 tools

Disambiguation5/5

Each tool targets a distinct resource/action: task CRUD, claiming, lifecycle transitions (complete/cancel/reopen/approve/revision), messaging, progress, and waiting. Even similar tools like list_tasks/search_tasks and claim_task/claim_next_task are clearly differentiated by purpose and described behavior.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (create_task, get_task, claim_task, update_progress, wait_for_task). Verb choices are semantically aligned with actions (list/get/search for reads; claim/complete/cancel for state changes), making the set predictable and easy to navigate.

Tool Count4/5

At 16 tools, the set sits at the upper boundary of typical scope, but every tool serves a distinct purpose in the coordination workflow. The slightly elevated count is justified by the inclusion of specialized tools like claim_next_task and wait_for_task that optimize common operations.

Completeness4/5

The surface covers the full task lifecycle (create, read, claim, complete, cancel, reopen, approve, revision) plus messaging and progress tracking. Minor gaps exist: there's no tool to edit task metadata (e.g., title, description, assignee) after creation, but this can be worked around via cancel/recreate.

Maintenance

ActivitySlowing
ResponsivenessNo issues