Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

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
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
task_listC

List tasks (optional status filter).

task_nextB

Show the one task that may start now: the queue head, planned, with dependencies and the phase gate met.

task_claimA

Claim a planned task (-> in_progress, sets owner and started). Refused unless every earlier task is done/cancelled (order and phase gate) and its dependencies are done.

task_updateA

Advance a task's status and record evidence (transitions are enforced). Send verification_result and review_result in SEPARATE calls: the caller identity (by) is the verifier; a review must come from the reviewer identity of the task's profile (see task_show), a different one, after that profile's delay since the stored verification, and must list the commands it checked in checks=[...]; closing as done needs a fresh review_result in the same call, unless the task's profile sets require_review = false. A task with open subtasks cannot go to in_review, done or cancelled.

task_renderA

Render the Markdown view from tasks.json; check=true fails on drift instead of writing.

task_validateA

Validate tasks.json: schema, status transitions and evidence gates.

task_showA

One task with its effective closing policy (profile, whether a review is required and by whom, review delay, quality gates) and its subtasks. Read it before verifying or reviewing to know what that task needs.

task_profileA

Set or clear the review/verification profile of a draft/planned task (profiles are defined in taskgate.toml, e.g. a docs profile without review). Not allowed once the task has started. Planners only; pass name or clear=true.

task_addA

Add a draft/planned task or, with parent, a subtask (id . assigned when id is omitted; one level, phase and default profile come from the parent; the parent must be in_progress before a subtask can start, and cannot close while subtasks are open). profile picks a review/verification profile from taskgate.toml. Duplicate ids and closed phases are rejected. Only identities listed in 'planners' may add tasks; pass by explicitly.

task_sortA

Reset the execution order to phase, then id; discards any order set with task_move.

task_moveA

Change the execution order: place a draft/planned task directly before or after another. Never in front of a task that is in flight or done, and phases stay ascending. Planners only; pass exactly one of before/after.

task_dependsA

Change the dependencies of a draft/planned task: set (replace; [] clears), add and/or remove ids. Each dependency must exist and be placed before the task (use task_move first). Planners only.

quality_checkA

Run quality gates and return a compact JSON report. Gate names come from [quality] in taskgate.toml; the built-in gate 'tasks' validates the registry and checks the Markdown view. Without 'checks' every gate runs; with task= only the gates of that task's profile run (a docs task can skip the build and test gates).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 13 tools

Disambiguation4/5

Each tool targets a fairly distinct operation on the task registry, and descriptions carefully separate near-neighbors like task_claim (order-gated start) vs task_update (status+evidence) and task_move vs task_sort vs task_depends. The main friction is validation overlap: task_validate, task_render with check=true, and quality_check's built-in 'tasks' gate all validate the same registry, which could cause hesitant selection.

Naming Consistency4/5

Eleven of thirteen tools use a consistent task_<verb> snake_case pattern (task_add, task_show, task_update, task_move, task_claim, etc.). Only quality_check deviates by dropping the task_ prefix, a minor but noticeable inconsistency.

Tool Count5/5

13 tools is well within the sweet spot and each one earns its place: lifecycle (add/claim/update), querying (show/list/next), planning (move/sort/depends/profile), and verification (validate/render/quality_check). No filler tools are present.

Completeness4/5

The surface covers the full task lifecycle including dependency management, ordering, profiles, claiming, evidence-gated closure, and quality gates, plus subtasks. The notable gap is there is no delete/remove operation for tasks or dependencies beyond cancellation and clearing via task_depends, leaving a dead end for erroneous draft entries.

Maintenance

ActivityMaintained
ResponsivenessNo issues