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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
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. |
| open_dashboardB | Show all local git projects (allowed directories or home folder) with branch, uncommitted changes and the last verification verdict, as an interactive dashboard with Verify and Summary buttons. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| verify-work | Check the latest changes in a project and show the verification report. |
| handoff-summary | Show the last verification report for a project without re-running checks. |
| projects-dashboard | See all your projects with their last verification result. |
| start-task | Record a baseline before new work so only the new changes are checked later. |
| check-setup | Make sure git, Python and your project tools are ready. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Task Handoff | Interactive verification report and projects dashboard |
TDQS
Scored across 8 tools
Most tools target distinct phases (setup, discovery, baseline, inspection, verification reporting), but verify_task's full pipeline overlaps with the combined inspect_task_state + run_relevant_checks, and summarize_handoff vs inspect_task_state vs verify_task all touch reporting similarly. Descriptions do distinguish them, so an agent can usually choose correctly.
All eight tools use consistent snake_case with a leading verb (open_, check_, find_, inspect_, run_, start_, summarize_, verify_). No camelCase or style mixing, and the pattern is predictable.
Eight tools is well-scoped for a task-handoff verification workflow, with each tool earning its place across discovery, setup, baseline, inspection, checks, and reporting.
The surface covers the full lifecycle: discovery (find_repos), environment (check_setup), baseline (start_task), inspection (inspect_task_state), checks (run_relevant_checks), and verification/reporting (verify_task, summarize_handoff, open_dashboard). Minor gaps like explicit baseline reset or history beyond the last report are workable given start_task overwrites baselines.