Progressor
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PROGRESSOR_PORT | No | The port the dashboard listens on. Defaults to 4747. | |
| PROGRESSOR_ROOT | No | The folder Progressor keeps its files in. By default it uses the folder the MCP client starts it in; set PROGRESSOR_ROOT to use another folder. | |
| PROGRESSOR_EDITOR | No | Chooses which editor 'Open in file' uses for the project. One of: vscode (default), vscode-insiders, vscodium, cursor, windsurf, zed, idea (or jetbrains), webstorm, pycharm, phpstorm, goland, rider, rubymine, clion, rustrover, or a URL template such as myeditor://open?file={path}&line={line}. | |
| PROGRESSOR_REGISTRY | No | Path to the per-user list of project folders shared by every Progressor server. Defaults to ~/.progressor/projects.json. | |
| PROGRESSOR_DASHBOARD | No | Set PROGRESSOR_DASHBOARD=off to run without the dashboard. |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_statusA | Compact summary of this Session's Goal, current Task, open Detour, next Task and the Developer's Standing Instructions. Call it at the start of every conversation and after context compression. |
| get_itemB | Look up a Goal, Task, Detour, Idea or Standing Instruction by its ref, with its file and line. |
| add_goalA | Add a Goal to the end of the Roadmap, with an optional initial Task list. Does not claim it. |
| claim_goalA | Claim a Goal for this Session, so only this Session works on it. Releases (pauses) any Goal this Session held before. Fails if another running Session holds it. Claiming a done Goal reopens it: its finished Tasks stay done, and add_tasks adds the new work to the same list. |
| release_goalA | Release this Session's Claim, leaving the Goal paused for a later Session. |
| complete_goalA | Mark the claimed Goal done and release it. |
| add_tasksA | Append Tasks to the claimed Goal's plan. For work that is not part of the plan, declare a Detour instead. |
| start_taskA | Mark a Task in progress. Only one Task can be in progress at a time. |
| complete_taskB | Mark a Task done, recording the files it touched and, if it changed, the final summary of what it did. |
| update_taskA | Change a Task's title, summary or files, for instance when the fix turns out different from the plan. Leaves its status alone. |
| drop_taskB | Drop a Task that is no longer needed, with a reason. To replace the whole remaining plan, recalibrate instead. |
| start_detourA | Declare that the work is splitting off from the planned Tasks, before doing it. Branches from the current Task. Only one Detour can be open. |
| end_detourA | End the open Detour. 'merge back': it was small and is done; the plan is unchanged. 'return': go back to the plan, appending |
| record_ideaB | Park a feature or improvement that came up but is not needed now, instead of doing it. |
| promote_ideaA | Turn an Idea into a Task at the end of the claimed Goal, or into a new Goal on the Roadmap. |
| add_standing_instructionB | Save a lasting rule from the Developer about how you should work, such as 'ask me before recalibrating'. It is shown in every get_status. |
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 16 tools
The tools map cleanly to distinct entities and state transitions: goals, tasks, detours, ideas, standing instructions, and status reads. Pairs such as complete_goal vs release_goal and start_task vs update_task are differentiated by outcome, so an agent should not confuse them.
All 16 tools use consistent snake_case verb_noun names (get_status, add_goal, start_detour, promote_idea), with no mixed conventions. The pattern is predictable across entities.
16 tools is slightly above the typical 3-15 range but still reasonable for a stateful workflow manager covering goals, tasks, detours, ideas, and instructions. Each tool maps to a distinct operation, with little evident redundancy.
Core goal/task/detour lifecycle is covered, including claiming, starting, completing, and dropping work. However, there is no tool to list/read the full Roadmap or to update/delete goals, ideas, or standing instructions, which are notable gaps for discovery and maintenance.