Task Handoff Verifier
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ALLOWED_DIRS | No | Optional allowed directories that the tools are restricted to. The tools refuse any repository outside these folders. Leave empty to allow all. Passed as positional command-line arguments (e.g. `run_server.py ~/code ~/work`) or set as the extension's "Allowed directories" setting. |
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": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| start_taskA | Record a baseline before starting work: HEAD plus fingerprints of files that are already dirty, so later verification attributes only the task's own changes. Overwrites any previous baseline for the repository. Writes only inside the .git directory. |
| inspect_task_stateA | Read-only snapshot: files changed since the baseline (excluding pre-existing edits), impact categories, risk flags, and which checks would be selected. Runs nothing. |
| run_relevant_checksA | Select the cheapest meaningful checks for the changed files (syntax, lint, typecheck, targeted tests, build when deps/config changed, Playwright for UI changes if configured) and run them. Never installs anything. dry_run=true only lists the selection. |
| verify_taskA | Full pipeline: inspect changes, run relevant checks, cross-check the agent's claims, and return a compact evidence-labelled handoff with a verdict and a suggested next prompt. |
| summarize_handoffA | Return the last verification report without re-running checks. If the repository changed since then, the report is marked stale and a fresh inspection-only report is returned. |
| find_reposA | Find git repositories on this computer (inside the allowed directories, or the home folder), most recently active first. Use it when the user names a project ('my shop app') instead of giving a path. |
| check_setupA | Diagnose the local setup: git, Python, node/npm, go, poetry, conda and other tools the checks use, plus (given repo_path) which interpreter that repo's checks would use and whether its test deps are installed. Returns exact fixes for anything missing. |
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 7 tools
Most tools have clearly distinct purposes: start_task sets a baseline, inspect_task_state only reads, run_relevant_checks runs checks, and find_repos/check_setup are niche utilities. verify_task is a full pipeline that composes inspect and run, which creates a mild subset relationship, but its description makes the orchestration role explicit.
All tool names follow a consistent snake_case verb_noun pattern (start_task, verify_task, find_repos, check_setup) with occasional modifiers (inspect_task_state, run_relevant_checks). The convention is predictable throughout.
Seven tools is well-scoped for a task handoff verifier: it covers setup, discovery, baseline creation, inspection, check execution, verification, and summarization without redundancy or bloat.
The surface covers the core lifecycle from baseline to verification and handoff, including environment diagnostics and repo discovery. Minor gaps exist around baseline management (e.g., no explicit clear or list of baselines) and check customization, but these are workable via overwrite and rerun.