io.github.zseta/progi
PYPI · PROGI
MCP-native workflow engine: teach agents your processes once, they execute them consistently.
Available components
Last scanned (21 hours ago)
Scores higher than 73% of PyPI servers
Category Workflow Automation
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 build step with no custom scripting around it. View diagnostics → Pass
- 1 of 32 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency97
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Cryptographically verified build provenance (signed, bound to zseta/progi). View diagnostics → Pass
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 140 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 Management100
- No destabilizing schema changes in the last 30 days.Pass
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
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.
- 4 Nov 26 −15
- Malware scan: pass → unverified ▼ security
- 3 Nov 26 +15
- Malware scan: unverified → pass ▲ security
- 30 Oct 26 −14
- Malware scan: pass → unverified ▼ security
- Stability: 0.97 → pass security
- 29 Oct 26 +14
- Malware scan: unverified → pass ▲ security
- Stability: pass → 0.97 functional
- 28 Oct 26 −15
- Malware scan: pass → unverified ▼ security
- 23 Oct 26 +1
- Stability: 0.97 → pass security
- 22 Oct 26 −1
- Stability: pass → 0.97 functional
- 16 Oct 26 +1
- Stability: 0.97 → pass security
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 4 Nov 2026 · Analysed pypi/progi@0.3.2
Provenance Verified
A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.
| Result | Verified |
|---|---|
| Ecosystem | pypi |
| Reason | Verified |
| Discovered via | Registry attestation endpoint |
| Source repo | zseta/progi |
| Certificate issuer | https://token.actions.githubusercontent.com |
| Certificate SAN | https://github.com/zseta/progi/.github/workflows/publish.yml@refs/heads/main |
| Rekor log index | 1839423484 |
| Predicate type | PyPI publish attestation https://docs.pypi.org/attestations/publish/v1 |
| Subject digest | sha256:b1f73fc14220795fbf2373b6da7653bbf24a7a33672c9df942cb8fcee9385d3f |
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 32 packages
| Packages resolved | 32 |
|---|---|
| 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.
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
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 76 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 4 November 2026. 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 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 4 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 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.