# Progressor (npm · progressor-mcp)

Keeps an AI coding agent on its plan across context compression, with a live local dashboard.

- Trust score: 75/100 (medium)
- Change this week: −7
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- npm · `progressor-mcp`: 75/100 (this document), [markdown](https://verifymcp.io/servers/racstan-progressor-mcp/progressor-mcp.md), [page](https://verifymcp.io/servers/racstan-progressor-mcp/progressor-mcp)

## Channel facts

- Registry: `npm`
- Package: `progressor-mcp`
- Version: `1.2.2`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Supply Chain Security**: 63/100
  - No malware found by supply-chain analysis.
  - Known CVEs could not be checked: the version this server declares is not published in its registry.
  - No install/post-install scripts declared.
  - Dependency health could not be checked: the version this server declares is not published in its registry.
- **Provenance & Transparency**: 97/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to racstan/progressor-mcp).
  - Clear OSI-approved license (GPL-3.0-or-later).
  - Actively maintained (last published 0 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 77/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 7350 tokens (~204/item across 36 items; 36 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 46/100
  - Stability check failed: the tool surface changed between 0.4.1 and 1.2.2: 2 tool removals, 0 breaking changes, 19 additions.
- **Tool Coverage**: 99/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 96% of tool parameters carry a description.
- **Tool Safety**: 75/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 0 of 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "drop_goal" implies "drop" and declares no destructiveHint at all, which the MCP spec reads as destructive by default.
  - An AI judge read all 37 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the Progressor MCP server?

Progressor runs locally as an npm package, launched with npx -y progressor-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add racstan-progressor-mcp -- npx -y progressor-mcp
```

### Cursor

```json
{
  "mcpServers": {
    "racstan-progressor-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "progressor-mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "racstan-progressor-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "progressor-mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add racstan-progressor-mcp -- npx -y progressor-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "racstan-progressor-mcp": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "progressor-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add racstan-progressor-mcp --command npx --arg -y --arg progressor-mcp
```

### Hermes

```yaml
mcp_servers:
  racstan-progressor-mcp:
    command: "npx"
    args: ["-y", "progressor-mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "racstan-progressor-mcp": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "progressor-mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add racstan-progressor-mcp -t stdio -c npx -a -y progressor-mcp
```

### Other

```json
{
  "mcpServers": {
    "racstan-progressor-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "progressor-mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 75, −10)

- [security regression] Known CVEs: pass → unverified
- [functional regression] Dependency health: 0.85 → unverified
- [functional] Package version: 1.2.1 → 1.2.2

### 2026-11-03 (score 85, +26)

- [security improvement] Malware scan: unverified → pass
- [security improvement] Known CVEs: unverified → pass
- [functional improvement] Dependency health: unverified → 0.85

### 2026-11-02 (score 59, −14)

- [security regression] Malware scan: pass → unverified
- [security improvement] Known CVEs: unverified → pass
- [functional improvement] Dependency health: unverified → 0.85
- [functional] Package version: 1.2.0 → 1.2.1

### 2026-11-01 (score 73, +5)

- [security regression] Known CVEs: pass → unverified
- [security regression] Stability: fail → unverified
- [security regression] Tool safety: pass → unverified
- [security improvement] Malware scan: unverified → pass
- [functional regression] Dependency health: 0.85 → unverified
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional regression] Schema quality: 100 → unverified
- [functional] Package version: 1.1.0 → 1.2.0
- [functional] Package version: 1.1.0 → 1.1.1

### 2026-10-31 (score 68, −15)

- [security regression] Malware scan: pass → unverified
- [functional] Package version: 1.0.0 → 1.1.0

### 2026-10-30 (score 83, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 26.

### 2026-10-28 (score 82, +1)

- [security regression] Stability: fail → unverified
- [security regression] Tool safety: pass → unverified
- [functional regression] Schema quality: 5311 → 7003
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional regression] Schema quality: 100 → unverified
- [functional] Package version: 0.9.0 → 1.0.0

### 2026-10-27 (score 81, +26)

- [security improvement] Malware scan: unverified → pass
- [security improvement] Known CVEs: unverified → pass
- [functional improvement] Dependency health: unverified → 0.85

## MCP tools (36)

### `get_status` (~125 tokens)

Get status

Compact summary of every Goal this Session holds (current Task, open Detour, Tasks with a helper or waiting on the Developer, next Task, decisions and open notes) and the Developer's Standing Instructions. Call it at the start of every conversation and after context compression. With project, another project's Goals and Tasks instead, to change them from here.

Input parameters:

- `project` (string): Another project's plan to use instead of this one's: its name or ID on the dashboard, or its folder's full path. Changes there are marked as made from this project. Leave out for this project.

### `get_item` (~104 tokens)

Get item

Look up one Goal, Task, Detour, decision, note or Standing Instruction by its ref (progressor://<goal>/<item>, or progressor://roadmap/<instruction>), with its file and line. Use it when the Developer pastes a ref or you need one item's details; for where the work stands overall, use get_status.

Input parameters:

- `ref` (string, required): A ref such as progressor://login/t2 or progressor://roadmap/i1.

### `get_rules` (~47 tokens)

Get rules

The project's Standing Instructions as a block to paste into the brief of a helper agent you start, hard rules first. Helpers don't see the Standing Instructions, so include this block whenever you brief one.

### `add_goal` (~379 tokens)

Add Goal

Add a Goal to the end of the Roadmap, with an optional Task list and Outcome; with claim: true, also claim it to start work. A title another Goal already has is refused unless allow_duplicate is set. To record work already finished, set done on the Goal and on every Task. Plan each Goal with an Outcome (one sentence on what done looks like) and Tasks that each have a short title, the files they touch, a one-line summary and an estimate. Tell the Developer the plan in a few plain lines first. With claim: true the answer is the whole status.

Input parameters:

- `allow_duplicate` (boolean): Add the Goal even though another Goal has the same title.
- `claim` (boolean): Claim the new Goal straight away, to start working on it.
- `done` (boolean): Record a Goal that is already finished. Every Task must then have done: true.
- `estimate` (string): How long the whole Goal should take, such as '6h', when its Tasks are not estimated one by one yet. Without it, the Goal's estimate is the sum of its Tasks'.
- `id` (string): A short ID for the Goal's refs, such as 'web-ui': lowercase letters, digits and dashes. Made from the title when left out.
- `outcome` (string): What done looks like, in one sentence, such as 'Users can sign in with Google and stay signed in for 30 days'.
- `project` (string): Another project's plan to use instead of this one's: its name or ID on the dashboard, or its folder's full path. Changes there are marked as made from this project. Leave out for this project.
- `tasks` (array)
- `title` (string, required): A few words naming the Goal, such as 'Ship OAuth login'.

### `add_hotfix` (~215 tokens)

Add hotfix

Add a hotfix: a bug the Developer wants fixed before any other work, often from a customer report. Pass the report word for word. It goes at the top of the Roadmap with two Tasks (a test that shows the bug, then the fix), and every Session is told it is waiting until one claims it. With claim: true, claim it now; otherwise finish the step you are on first, then claim it.

Input parameters:

- `claim` (boolean): Claim the hotfix straight away, to start on it now.
- `project` (string): Another project's plan to use instead of this one's: its name or ID on the dashboard, or its folder's full path. Changes there are marked as made from this project. Leave out for this project.
- `report` (string, required): The bug report as the Developer or customer wrote it: what goes wrong, and how to make it happen if known.
- `title` (string): A few words naming the bug; the report's first line when left out.

### `update_goal` (~198 tokens)

Update Goal

Rename a Goal, set its Outcome or its estimate. Its ID, refs and Plan File stay the same, and it needs no Claim. To change a Goal's Tasks, claim it and use add_tasks, update_task or drop_task.

Input parameters:

- `estimate` (string): How long the whole Goal should take, such as '6h'; it covers the open Tasks that have no estimate of their own. An empty string removes it, so the Goal's estimate is the sum of its Tasks'.
- `goal` (string, required): The Goal ID, such as 'ship-oauth-login'.
- `outcome` (string): The new Outcome; an empty string removes it.
- `project` (string): Another project's plan to use instead of this one's: its name or ID on the dashboard, or its folder's full path. Changes there are marked as made from this project. Leave out for this project.
- `title` (string): The new title.

### `move_goal` (~175 tokens)

Move Goal

Move a Goal right before or after another Goal, so the Roadmap lists the work in the order it should happen. Give exactly one of before and after. The dashboard lists the Goals that need the Developer (things to try, steps to check, questions) in this order too, so put the one they should check first in front.

Input parameters:

- `after` (string): The ID of the Goal to move it behind.
- `before` (string): The ID of the Goal to move it in front of.
- `goal` (string, required): The Goal ID, such as 'ship-oauth-login'.
- `project` (string): Another project's plan to use instead of this one's: its name or ID on the dashboard, or its folder's full path. Changes there are marked as made from this project. Leave out for this project.

### `drop_goal` (~95 tokens)

Drop Goal

Drop a Goal that will not be done, with the reason; its Plan File stays as a record. Releases this Session's Claim on it. A Goal another running Session holds, or one already done, cannot be dropped. To drop a single Task, use drop_task.

Input parameters:

- `goal` (string, required): The Goal ID, such as 'ship-oauth-login'.
- `reason` (string, required): Why the Goal will not be done.

### `claim_goal` (~122 tokens)

Claim Goal

Claim a Goal for this Session, so only this Session works on it. The Session keeps any other Goals it holds; while it holds several, pass goal to the tools that change one. 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.

Input parameters:

- `goal` (string, required): The Goal ID, such as 'ship-oauth-login'.
- `takeover` (boolean): Take the Goal from another running Session. Only when the Developer asks for it.

### `claim_resource` (~319 tokens)

Claim resource

Claim a named shared resource that only one session or helper can use at a time (a dev window that allows a single instance, plasmashell, a port), before you or a helper start something that needs it. Refused, saying who holds it, since when and why, when someone else has it: then do not start it; do other work and try again later (nothing waits for you). Claiming your own resource again refreshes its time. It frees itself after `minutes` (30 unless given, at most 240) from the last claim, when its Session ends, or when you release it. A helper usually cannot call Progressor: claim on its behalf before you start it, with label such as 'helper: media run', and call release_resource when it hands back.

Input parameters:

- `label` (string): Who it is held for when that is not this Session itself, such as 'helper: media run'. Claim and release a helper's lock with the same label.
- `minutes` (number): How long to keep it before it frees itself, from now. 30 if omitted; claim again to extend.
- `reason` (string, required): Why you need it, in a few words, such as 'running the UI test'. Shown to whoever is refused.
- `resource` (string, required): The shared thing's name, such as 'dev-window' or 'plasmashell'. Case and spaces do not matter.
- `task` (string): The Task ID it is for, such as 't3'.

### `release_resource` (~166 tokens)

Release resource

Release a shared resource you claimed with claim_resource, as soon as the work that needed it ends (including a helper's: release it when the helper hands back). Pass the same label you claimed it with. Another holder's resource is refused, unless force is given, which is only for when the Developer says the holder is gone.

Input parameters:

- `force` (boolean): Release it even though someone else holds it. Only when the Developer asks.
- `label` (string): Who it is held for when that is not this Session itself, such as 'helper: media run'. Claim and release a helper's lock with the same label.
- `resource` (string, required): The shared thing's name, such as 'dev-window' or 'plasmashell'. Case and spaces do not matter.

### `list_resources` (~44 tokens)

List resources

Who holds which shared resource now, for how long, and why. get_status shows the same. Resources whose time is up or whose Session has ended are free and not listed.

### `release_goal` (~54 tokens)

Release Goal

Release this Session's Claim on a Goal, leaving it paused for a later Session.

Input parameters:

- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.

### `complete_goal` (~236 tokens)

Complete Goal

Mark the claimed Goal done and release it, once its Outcome is true and its Tasks are done, released or dropped (not with a helper, waiting on the Developer or only checked). While the Developer still has hand tests (add_hand_test) to mark, the Goal is released as built and waiting on their tests instead: it finishes by itself when they mark the last one, and a failure reopens it with a new Task. unmarked_hand_tests_ok finishes it now, only when the Developer says to finish anyway. If more work turns up later, claim_goal reopens it.

Input parameters:

- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `project` (string): Another project's plan to use instead of this one's: its name or ID on the dashboard, or its folder's full path. Changes there are marked as made from this project. Leave out for this project.
- `unmarked_hand_tests_ok` (boolean): Finish now even though some hand tests are still not marked by the Developer. Only when the Developer says to finish anyway.

### `add_tasks` (~159 tokens)

Add Tasks

Append Tasks to the claimed Goal's plan, each with an estimate of how long it takes. For work that is not part of the plan, declare a Detour instead. Set done on a Task that is already finished: a small change you have made is recorded in this one call, with hand_test for what the Developer should try.

Input parameters:

- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `project` (string): Another project's plan to use instead of this one's: its name or ID on the dashboard, or its folder's full path. Changes there are marked as made from this project. Leave out for this project.
- `tasks` (array, required)

### `start_task` (~110 tokens)

Start Task

Mark a Task in progress: you are working on it yourself; call it before you change code for the Task. Answers briefly, with where the work stands. Only one Task of a Goal can be in progress at a time; for Tasks in other hands, use set_task_state.

Input parameters:

- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `task` (string, required): The Task ID, such as 't3'.

### `set_task_state` (~531 tokens)

Set Task state

Set a Task's state. 'with a helper': handed to a helper agent that is working on it (several Tasks can be). 'waiting on you': you are waiting on the Developer, such as for them to test something by hand; the dashboard shows the Goal as waiting on them, so tell them what you need. 'checked': you checked a helper's work (tests, review) but it is not merged or released yet; give evidence, one short line on what you checked ("715 passed, live send OK"), which the Developer sees on the step. With 'with a helper', give helper_branch, helper_folder (the worktree path) and helper_label: they are recorded with the Task and shown in get_status and on the dashboard, and get_status warns when a finished Task's helper branch still has unmerged work. 'released': merged and out (shipped, installed or published); counts as done. 'pending', 'in progress' and 'done' work too (in progress follows start_task's one-at-a-time rule). Set a state as soon as it changes, such as 'checked' right after you check a helper's work, so the Developer's dashboard keeps moving. If the project has a helper limit (get_status shows it), keep at most that many Tasks with a helper: one more is still set, with a warning. To drop a Task, use drop_task.

Input parameters:

- `evidence` (string): With state 'checked': one short line on what you checked, such as '715 passed, live send OK'. Give it: the Developer sees it on the dashboard step.
- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `helper_branch` (string): With state 'with a helper': the git branch the helper works on, such as 'feat/export'. Recorded so a branch left behind can be found later.
- `helper_folder` (string): With state 'with a helper': the helper's worktree folder (its path).
- `helper_label` (string): With state 'with a helper': a label for the helper, such as the model it runs on ('Sonnet').
- `project` (string): Another project's plan to use instead of this one's: its name or ID on the dashboard, or its folder's full path. Changes there are marked as made from this project. Leave out for this project.
- `state` (string, required)
- `task` (string, required): The Task ID, such as 't3'.

### `update_tasks` (~234 tokens)

Update Tasks

Change several Tasks in one call, such as completing two and starting the next, or setting the estimates of several, instead of one call each. The operations are applied in order, so a start can follow the complete of the Task that was in progress; if any one fails, none is applied. A 'state' operation takes the same helper_branch, helper_folder, helper_label (with 'with a helper') and evidence (with 'checked') as set_task_state. Each operation can name its own claimed Goal with goal, else the call's goal (or the only Goal held) is used. The recommended way to change more than one Task. Answers with one line per call, not the whole status.

Input parameters:

- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `operations` (array, required)
- `project` (string): Another project's plan to use instead of this one's: its name or ID on the dashboard, or its folder's full path. Changes there are marked as made from this project. Leave out for this project.

### `move_task` (~221 tokens)

Move Task

Move a Task of a claimed Goal to another Goal when it belongs there. It keeps its title, summary, files and state, gets a new ID at the end of the other Goal's list (or right before or after the Task given in before or after) and a 'moved from' line. In the old Goal it stays as a dropped Task whose reason is where it went, so refs and history still work. The other Goal must not be dropped, done or held by another running Session; a Task in progress can move only if the other Goal has none in progress.

Input parameters:

- `after` (string): A Task ID in the other Goal to put it behind.
- `before` (string): A Task ID in the other Goal to put it in front of.
- `goal` (string): The claimed Goal the Task is in. Needed only when this Session holds several Goals.
- `task` (string, required): The Task ID, such as 't3'.
- `to_goal` (string, required): The ID of the Goal to move the Task to.

### `complete_task` (~267 tokens)

Complete Task

Mark a Task of the claimed Goal done, recording the files it touched. When what you built differs from the summary (a part left out, done another way, put somewhere else), pass the new summary so the plan matches the work. Works whether or not the Task was started; to finish several, use update_tasks. Answers briefly, with the time it took and where the work stands. For a Task that turned out unnecessary, use drop_task instead; to change a Task without finishing it, use update_task.

Input parameters:

- `code` (array): Files the Task touched, optionally with :line; added to the ones it has.
- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `project` (string): Another project's plan to use instead of this one's: its name or ID on the dashboard, or its folder's full path. Changes there are marked as made from this project. Leave out for this project.
- `summary` (string): One or two sentences on the fix or change the Task makes, such as 'Callback re-sets the session cookie on every hit; only set it after token exchange.'
- `task` (string, required): The Task ID, such as 't3'.

### `update_task` (~251 tokens)

Update Task

Change a Task's title, summary, files or estimate, for instance when the fix turns out different from the plan or you learn it takes longer. Leaves its status alone.

Input parameters:

- `code` (array): The Task's files, optionally with :line; replaces the ones it has.
- `estimate` (string): The Task's new estimate, such as '45m' or '2h'; an empty string removes it.
- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `project` (string): Another project's plan to use instead of this one's: its name or ID on the dashboard, or its folder's full path. Changes there are marked as made from this project. Leave out for this project.
- `summary` (string): One or two sentences on the fix or change the Task makes, such as 'Callback re-sets the session cookie on every hit; only set it after token exchange.'
- `task` (string, required): The Task ID, such as 't3'.
- `title` (string): A short title for the Task, a few words, such as 'Fix callback redirect loop'.

### `drop_task` (~123 tokens)

Drop Task

Drop one Task of the claimed Goal that is no longer needed, with the reason; it stays in the Plan File, struck through. To replace the whole remaining plan, end a Detour with 'recalibrate' instead; to drop the whole Goal, use drop_goal.

Input parameters:

- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `reason` (string, required): Why the Task is no longer needed.
- `task` (string, required): The Task ID, such as 't3'.

### `start_detour` (~107 tokens)

Start Detour

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.

Input parameters:

- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `reason` (string, required): Why the work has to split off from the plan now.
- `title` (string, required): What the Detour does, such as 'Fix flaky token refresh'.

### `end_detour` (~129 tokens)

End Detour

End the open Detour. 'merge back': it was small and is done; the plan is unchanged. 'return': go back to the plan, appending `tasks` for the Detour's intended work if any. 'recalibrate': drop every remaining Task and replace them with `tasks`.

Input parameters:

- `ending` (string, required)
- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `tasks` (array): Tasks to append (return) or the new Task list (recalibrate).

### `add_decision` (~151 tokens)

Add decision

Record a choice made for a claimed Goal along the way, such as 'old models get thinking on/off only', so it survives context compression; get_status shows it. Not for lasting project rules (add_standing_instruction) or project-wide background (update_context).

Input parameters:

- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `project` (string): Another project's plan to use instead of this one's: its name or ID on the dashboard, or its folder's full path. Changes there are marked as made from this project. Leave out for this project.
- `text` (string, required): The decision, in one line.

### `update_decision` (~101 tokens)

Update decision

Reword a decision of a claimed Goal, or remove it with an empty text. The IDs (c1, c2...) are in get_status.

Input parameters:

- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `id` (string, required): The decision ID, such as 'c2'.
- `text` (string, required): The new wording; empty to remove the decision.

### `add_note` (~144 tokens)

Add note

Note something you spotted that belongs to a Goal, such as a bug found during cleanup that belongs to the Voice Goal, instead of dealing with it now. Any Goal on the Roadmap that is not dropped, claimed or not. get_status shows the open notes of the Goals this Session holds.

Input parameters:

- `goal` (string, required): The ID of the Goal the note belongs to.
- `project` (string): Another project's plan to use instead of this one's: its name or ID on the dashboard, or its folder's full path. Changes there are marked as made from this project. Leave out for this project.
- `text` (string, required): What you spotted, in one line.

### `update_note` (~152 tokens)

Update note

Resolve a note once it is dealt with (resolved: true), reopen it (false), reword it, or remove it with an empty text.

Input parameters:

- `goal` (string, required): The ID of the Goal the note belongs to.
- `id` (string, required): The note ID, such as 'n2'.
- `project` (string): Another project's plan to use instead of this one's: its name or ID on the dashboard, or its folder's full path. Changes there are marked as made from this project. Leave out for this project.
- `resolved` (boolean): true once the note is dealt with; false to reopen it.
- `text` (string): The new wording; empty to remove the note.

### `ask_developer` (~254 tokens)

Ask the Developer

Ask the Developer a question on the dashboard, with 2 to 4 short choices they can click (they can also answer in their own words), instead of stopping in the chat. Use it for product and UX choices only they can make; carry on with other work meanwhile. Their answer reaches you at your next Progressor call, under 'New from the Developer', and is kept as a decision on the Goal. While a question is open the dashboard shows the Goal as waiting on them. To take back a question that no longer needs an answer, pass withdraw with its ID instead.

Input parameters:

- `choices` (array): 2 to 4 short answers to pick from, such as ['On by default', 'Follow the computer'].
- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `question` (string): The question, in one plain sentence a non-programmer understands.
- `task` (string): The ID of the Task it is about, such as 't3'.
- `withdraw` (string): The ID of an open question to withdraw (such as 'q2'), instead of asking a new one.

### `reply_to_developer` (~186 tokens)

Reply to the Developer

Answer a message the Developer sent you on the dashboard (shown under 'New from the Developer' with its ID, such as m2): say in a sentence or two, in plain words, what you did or will do about it. The reply shows under their message on the dashboard. Reply to every message, even if only to say you will do it later. A message to the whole project is answered with whole_project: true and needs no Goal.

Input parameters:

- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `message` (string, required): The message ID, such as 'm2'.
- `reply` (string, required): Your answer, in plain words for someone who doesn't code.
- `whole_project` (boolean): True for a message to the whole project rather than to a Goal.

### `add_hand_test` (~203 tokens)

Add hand test

Add something only the Developer can try by hand to a claimed Goal, such as 'OpenCode may ask permission to read an attached file: allow it and check the reply'. Put it here instead of in your chat summary: the Developer sees the Goal's hand-test list on the dashboard and marks each one there as works, doesn't work (with a note) or won't test. A failure adds a Task to the Goal by itself; get_status shows what is still open and the new marks. complete_goal with tests unmarked leaves the Goal waiting on them, and it finishes when the last is marked.

Input parameters:

- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `task` (string): The ID of the Task it is about, such as 't3'.
- `text` (string, required): What to try and what to look for, in one or two short plain sentences.

### `attach_picture` (~263 tokens)

Attach picture

Show the Developer a screenshot or a short screen recording on the dashboard instead of naming a file in chat. It is copied (not moved) next to the plan, stays on this computer and out of git, and appears on the Goal, on the step or on the hand test you name; the Developer clicks it to enlarge. Allowed: .png .jpg .jpeg .webp .gif and .webm .mp4, up to 10 MB, with a short caption. To take one back, pass remove with its ID (such as 'p2') instead.

Input parameters:

- `caption` (string): What it shows, in a few plain words (up to 200 characters).
- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `hand_test` (string): The ID of the hand test it is about, such as 'h2'.
- `path` (string): The file's path, absolute or from the project's folder.
- `remove` (string): The ID of a picture to remove (such as 'p2'), instead of attaching one.
- `task` (string): The ID of the Task it is about, such as 't3'.

### `update_hand_test` (~142 tokens)

Update hand test

Reword a hand test of the claimed Goal, change which Task it is about, or remove it with an empty text (for one that turned out not to need testing). Its mark from the Developer stays; only the Developer marks tests.

Input parameters:

- `goal` (string): The claimed Goal's ID, such as 'ship-oauth-login'. Needed only when this Session holds several Goals.
- `id` (string, required): The hand test ID, such as 'h2'.
- `task` (string): The ID of the Task it is about; an empty string removes the link.
- `text` (string): The new wording; empty to remove the hand test.

### `add_standing_instruction` (~182 tokens)

Add Standing Instruction

Save a lasting rule from the Developer about how you should work in this project, such as 'ask me before changing the plan'. get_status lists it from then on. Use it only for rules meant to last; a one-off request is just done.

Input parameters:

- `hard` (boolean): true for a rule that must never be broken (not just a preference); get_status, the session start and get_rules list those first as HARD RULE.
- `helpers_at_once` (integer): Makes this rule the project's helper limit: the most Tasks that may be 'with a helper' at once, such as 2 when the Developer says 'at most 2 helpers in parallel'. One rule holds the limit; setting it…
- `text` (string, required): The rule, in the Developer's words where possible.

### `update_standing_instruction` (~242 tokens)

Update Standing Instruction

Reword a Standing Instruction when the Developer changes a rule, make it a hard rule (hard: true) or an ordinary one again (hard: false), set or change the helper limit it holds (helpers_at_once), or remove it with an empty text when they drop it. Give any of text, hard and helpers_at_once; what you leave out stays. The IDs (s1, s2...) are in get_status.

Input parameters:

- `hard` (boolean): true for a rule that must never be broken (not just a preference); get_status, the session start and get_rules list those first as HARD RULE.
- `helpers_at_once` (integer): Makes this rule the project's helper limit: the most Tasks that may be 'with a helper' at once, such as 2 when the Developer says 'at most 2 helpers in parallel'. One rule holds the limit; setting it…
- `id` (string, required): The Standing Instruction ID, such as 's2'.
- `text` (string): The new wording; empty to remove the rule. Left out, the wording stays.

### `update_context` (~112 tokens)

Update Important context

Replace the project's Important context: lasting background you and the Developer need in every conversation, such as what the project is, key facts, where things live and choices that hold for the whole project. Not for rules (add_standing_instruction) or for one Goal's details. get_status shows the current text: send the whole new text, or an empty text to clear it. At most 4000 characters.

Input parameters:

- `text` (string, required): The whole Important context, in plain words; short paragraphs or a list.

## Diagnostics

Captured diagnostic sections: Provenance. The full working is on the page: https://verifymcp.io/servers/racstan-progressor-mcp/progressor-mcp#diagnostics

## Score history

- 2026-11-05: 75
- 2026-11-04: 85
- 2026-11-03: 85
- 2026-11-02: 59
- 2026-11-01: 73
- 2026-10-31: 68
- 2026-10-30: 83
- 2026-10-29: 82
- 2026-10-28: 82
- 2026-10-27: 81
- 2026-10-26: 55
- 2026-10-25: 81
- 2026-10-24: 81
- 2026-10-23: 81
- 2026-10-22: 70
- 2026-10-21: 55
- 2026-10-20: 55
- 2026-10-19: 80

## Common questions

### What is the Progressor MCP server?

Progressor is an MCP server listed in the public MCP registry as io.github.racstan/progressor-mcp. Keeps an AI coding agent on its plan across context compression, with a live local dashboard. This page covers its npm package (progressor-mcp).

### Is the Progressor MCP server safe to use?

Progressor scores 75 out of 100 on VerifyMCP. It declares no install or post-install scripts. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Progressor MCP server expose?

Progressor exposes 36 tools: get_status, get_item, get_rules, add_goal, add_hotfix, and 31 more. Their descriptions and schemas cost roughly 6,543 tokens of context every time the server is loaded.

### Is the Progressor MCP server still maintained?

Progressor is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Progressor MCP server under?

Progressor declares the GPL-3.0-or-later licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/progressor-mcp
- Socket report: https://socket.dev/npm/package/progressor-mcp
- Repository: https://github.com/racstan/progressor-mcp
- Changelog RSS feed: https://verifymcp.io/servers/racstan-progressor-mcp/progressor-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/racstan-progressor-mcp/progressor-mcp.json
- HTML version of this page: https://verifymcp.io/servers/racstan-progressor-mcp/progressor-mcp