io.github.zseta/progi
PYPI · PROGI · SCANNED SEP 20
MCP-native workflow engine: teach agents your processes once, they execute them consistently.
Available components
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. How we score → Why this is hard to score →
Supply Chain Security50
- Malware scan not yet available for this package.Unverified
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs hatchling.build at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
- 1 of 36 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency45
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 95 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability72
- AI-judged instruction clarity (good).Pass
- Tool/resource definitions use about 764 tokens (~76/item across 10 items; 10 tools + 0 resources), lean.Pass
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management83
- Stability observed for 25 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage71
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety75
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "update_progress_notes" implies "overwrite" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
- An AI judge read all 10 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
How do I install the io.github.zseta/progi MCP server?
io.github.zseta/progi runs locally as a PyPI package, launched with uvx progi. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · progi
claude mcp add zseta-progi -- uvx progi
{
"mcpServers": {
"zseta-progi": {
"command": "uvx",
"args": [
"progi"
]
}
}
} {
"servers": {
"zseta-progi": {
"command": "uvx",
"args": [
"progi"
]
}
}
} codex mcp add zseta-progi -- uvx progi
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"zseta-progi": {
"type": "local",
"command": [
"uvx",
"progi"
],
"enabled": true
}
}
} openclaw mcp add zseta-progi --command uvx --arg progi
mcp_servers:
zseta-progi:
command: "uvx"
args: ["progi"] {
"McpServers": {
"zseta-progi": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"progi"
]
}
}
} assistant mcp add zseta-progi -t stdio -c uvx -a progi
{
"mcpServers": {
"zseta-progi": {
"command": "uvx",
"args": [
"progi"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 20 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.
- 19 Sept 26 −3
- Security disclosure: unverified → fail ▼ functional
- Stability: pass → 0.80 functional
- 18 Sept 26 0
- Stability: 0.97 → pass security
- Security disclosure: fail → unverified ▼ functional
- 17 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.
- 15 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.
- 13 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.
- 12 Sept 26 −3
- Security disclosure: unverified → fail ▼ functional
- Stability: pass → 0.80 functional
- 11 Sept 26 0
- Stability: 0.97 → pass security
- Security disclosure: fail → unverified ▼ functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 20 Sept 2026 · Analysed pypi/progi@0.3.2
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | pypi |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | hatchling.build |
Background: Why install scripts are a supply-chain risk →
Dependencies 36 packages
| Packages resolved | 36 |
|---|---|
| Stale | 1 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
create_task Create Task ~83
Create a new task under the given workflow. Creates the task (status 'todo') and returns the task plus a preview of its first step. Before calling this, confirm the workflow choice with the user AND ask them what they want to name the task.
| Name | Type | Req | Description |
|---|---|---|---|
| description | string | – | – |
| name | string | yes | – |
| workflow_id | integer | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
get_playbook_authoring_prompt Get Playbook Authoring Prompt ~65
Return the Pass 2 system prompt for authoring a step's playbook. Workflow context (the full process, this step's position, and its input/output specs) is injected at the top of the prompt template.
| Name | Type | Req | Description |
|---|---|---|---|
| step_id | integer | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_process_skeleton_prompt Get Process Skeleton Prompt ~59
Return the Pass 1 system prompt for authoring a new workflow's skeleton. The harness uses it to help the user convert a plain-language workflow description into a structured process skeleton (steps with input/output specs, no playbooks yet).
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
list_tasks List Tasks ~53
List tasks, optionally filtered by status and/or workflow_id. Empty string / 0 means no filter. "My todos" = status="todo".
| Name | Type | Req | Description |
|---|---|---|---|
| status | string | – | – |
| workflow_id | integer | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
list_workflows List Workflows ~17
Return all workflows with their ordered steps.
Input schema present but exposes no named parameters.
Structured output declared, but exposes no named fields.
No examples provided.
save_workflow Save Workflow ~69
Persist a new workflow, its steps, and playbooks. skeleton: the JSON object produced by Pass 1 (process skeleton prompt). playbooks_by_step: mapping of step name → playbook markdown string.
| Name | Type | Req | Description |
|---|---|---|---|
| playbooks_by_step | object | yes | – |
| skeleton | object | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
start_or_continue_task Start or Continue Task ~132
Main work-loop entry point. - done → returns a done message. - todo → starts the task (todo → in_progress) and returns step context. - in_progress → returns step context so the agent can resume. Context includes task info, the current step name + position, input_data, output_spec (the expected format/type of the deliverable), the playbook markdown, and progress_notes (if any). Before calling submit_output, verify that your output satisfies output_spec (correct type, meets constraints, includes any fields referenced by branching conditions).
| Name | Type | Req | Description |
|---|---|---|---|
| task_id | integer | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
submit_output Submit Output ~197
Mark the current step complete, store its output, and advance. Either returns the next step's info (name + playbook, so the agent can continue immediately) or {'status': 'done'} if it was the last step. Pass task_name to rename the task when you now have enough context to give it a meaningful name (e.g. after the first step reveals what the task is actually about). Leave it empty to keep the current name. IMPORTANT — approval gate: if start_or_continue_task returned current_step.requires_approval = true for this step, you MUST present the output to the user and ask for explicit approval BEFORE calling this tool. Only call submit_output once the user has confirmed they are happy with the output. If they request changes, make them first, then ask again.
| Name | Type | Req | Description |
|---|---|---|---|
| output | object | yes | – |
| task_id | integer | yes | – |
| task_name | string | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
update_playbook Update Playbook ~33
Replace the playbook content for a step.
| Name | Type | Req | Description |
|---|---|---|---|
| content | string | yes | – |
| step_id | integer | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
update_progress_notes Update Progress Notes ~56
Overwrite a task's progress_notes. Only call this when the user explicitly asks to save or update progress notes. Notes are cleared automatically when a step completes.
| Name | Type | Req | Description |
|---|---|---|---|
| notes | string | yes | – |
| task_id | integer | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
What is the io.github.zseta/progi MCP server?
io.github.zseta/progi is an MCP server listed in the public MCP registry as io.github.zseta/progi. MCP-native workflow engine: teach agents your processes once, they execute them consistently. This page covers its PyPI package (progi).
Is the io.github.zseta/progi MCP server safe to use?
io.github.zseta/progi scores 63 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. 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 io.github.zseta/progi MCP server expose?
io.github.zseta/progi exposes 10 tools: create_task, list_tasks, start_or_continue_task, update_progress_notes, submit_output, and 5 more. Their descriptions and schemas cost roughly 764 tokens of context every time the server is loaded.
Is the io.github.zseta/progi MCP server still maintained?
io.github.zseta/progi is still listed as active in the MCP registry. We last reached this channel on 20 September 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 io.github.zseta/progi MCP server under?
io.github.zseta/progi declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.