Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

subtask

PYPI · SUBTASK-MCP

Background sub-agents for Claude Code, Codex, Kimi and OpenCode, over MCP, with a spend cap.

Available components

+18 this week 81 Trust /100

Last scanned (23 hours ago)

Scores higher than 82% of PyPI servers

Category AI and Machine Learning

Trust breakdown (7 categories)

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 Security100
  • No malware found by supply-chain analysis.Pass
  • No known CVEs affecting this package version or its production dependencies.Pass
  • Runs setuptools.build_meta at install time, a recognised build step with no custom scripting around it. View diagnostics → Pass
  • 2 of 37 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency100
  • Source repository is publicly reachable at the declared URL. View diagnostics → Pass
  • Cryptographically verified build provenance (signed, bound to tedin7/subtask). View diagnostics → Pass
  • Clear OSI-approved license (MIT).Pass
  • Actively maintained (last published 0 days ago).Pass
  • Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability51
  • AI-judged instruction clarity (fair).Partial
  • Context-footprint check failed: tool/resource definitions use about 2378 tokens (~132/item across 18 items; 18 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management57
  • Stability check failed: the tool surface changed between 0.2.11 and 0.5.9: 1 tool removals, 0 breaking changes, 9 additions. See how to fix → Fail
Tool Coverage63
  • 94% of tools have a non-trivial description (not blank, and not just the tool's name).Partial
  • 0% of tool parameters carry a description.Fail
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; "cleanup" implies "remove" 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 19 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
Changelog

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 +16
    • Malware scan: unverified → pass ▲ security
  • 3 Nov 26 0
    • Malware scan: unverified → pass ▲ security
    • Package version: 0.5.5 → 0.5.9 functional
    • Package version: 0.5.5 → 0.5.8 functional
    • Package version: 0.5.5 → 0.5.6 functional
  • 2 Nov 26 −14
    • Malware scan: pass → unverified ▼ security
  • 1 Nov 26 +15
    • Stability: fail → unverified ▼ security
    • Tool safety: pass → unverified ▼ security
    • Malware scan: unverified → pass ▲ security
    • Schema quality: 107 → 132 ▼ functional
    • Capabilities: pass → unverified ▼ functional
    • Tool coverage: 93 → unverified ▼ functional
    • Package version: 0.5.0 → 0.5.5 functional
    • Package version: 0.5.0 → 0.5.4 functional
    • Package version: 0.5.0 → 0.5.3 functional
  • 31 Oct 26 −14
    • Malware scan: pass → unverified ▼ security
    • Security disclosure: unverified → pass ▲ functional
  • 30 Oct 26 −1
    • Security disclosure: pass → unverified ▼ functional
  • 29 Oct 26 +16
    • Malware scan: unverified → pass ▲ security
  • 27 Oct 26 +1

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

Diagnostics

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/subtask-mcp@0.5.9

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 tedin7/subtask
Certificate issuer https://token.actions.githubusercontent.com
Certificate SAN https://github.com/tedin7/subtask/.github/workflows/release.yml@refs/tags/v0.5.9
Rekor log index 3670389869
Predicate type PyPI publish attestation https://docs.pypi.org/attestations/publish/v1
Subject digest sha256:8bbd45bd6eab2c05c30640a6dbe34895d209714a29793b8dadaf1b6b18e97dac

Background: How many MCP packages publish verified provenance →

Install scripts 1 script
Hook Tier Command
build_backend allowlisted setuptools.build_meta

Background: Why install scripts are a supply-chain risk →

Dependencies 37 packages
Packages resolved 37
Stale 1
No linked repository 1
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 18 exposed · ~1,867 tokens

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 →

Tool Tokens
bisect ~85

First commit in good_ref..bad_ref that fails test_cmd, testing up to parallelism commits at once. auto_fix: start a fix job.

NameTypeReqDescription
auto_fixboolean––
bad_refstringyes–
good_refstringyes–
parallelisminteger––
repostring––
test_cmdstringyes–

No output schema declared.

No examples provided.

cleanup ~24

Remove a job's worktree, keep branch.

NameTypeReqDescription
idstringyes–

No output schema declared.

No examples provided.

consensus ~83

2-4 engines solve prompt blind in worktrees, then one job merges the best (verify, invariants). Returns a group id for wait().

NameTypeReqDescription
enginesarrayyes–
isolationstring––
max_usdnumber––
promptstringyes–
repostring––
verify_cmdstring––

No output schema declared.

No examples provided.

engines ~13

Free quota and API spend.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

inspect ~52

Raw log lines of a job (last `tail`, filtered by `grep`). Only when the summary is not enough.

NameTypeReqDescription
grepstring––
idstringyes–
tailinteger––

No output schema declared.

No examples provided.

integrate ~79

Bring worktree jobs back. diff first to review; apply = uncommitted, all or nothing, Python files of symbol_scope jobs merged by symbol; discard removes worktree and branch. auto_resolve: a reconcile job on conflict.

NameTypeReqDescription
actionstring––
auto_resolveboolean––
idsarrayyes–

No output schema declared.

No examples provided.

jev ~138

Show or change the shared Jev policy: status | auto | manual | off. Only the operator changes the policy: do not switch it to obtain or avoid a check. Auto checks every new final delivery once within the existing budget; read that outcome in wait()/result before any manual review. All advice is consultative. Credentials are never accepted here: add or replace a key in a terminal with `subtask jev setup` (hidden input), never in chat, argv or a tool argument. Changes apply to new submissions in every configured CLI; no server reload is needed.

NameTypeReqDescription
actionstring––

No output schema declared.

No examples provided.

map_reduce ~123

The same edit over many files: one job per batch of files matching glob ({{files}} in prompt_template), at most `concurrency` at once, each in a worktree with verify_cmd. Returns a group id for wait().

NameTypeReqDescription
batch_sizeinteger––
concurrencyinteger––
cwdstring––
enginestring––
glob_patternstringyes–
isolationstring––
prompt_templatestringyes–
repostring––
verify_cmdstring––

No output schema declared.

No examples provided.

plan ~97

Preview tasks before workers start. Read deterministic facts and advisory Jev contradictions, then launch=True with plan_id to start the unchanged plan once. Changed inputs require a new preview. This is a coordinator decision within the authorized task, not a new operator permission. Legacy start/start_many remain available. Read dependencies must be explicit in depends_on.

NameTypeReqDescription
launchboolean––
plan_idstring––
tasksarray––

No output schema declared.

No examples provided.

reply ~38

Jev auto adds advisory feedback checks; read the output. Continue a finished job.

NameTypeReqDescription
idstringyes–
messagestringyes–

No output schema declared.

No examples provided.

result ~43

Job summary; full=True for all; evidence=True for the JSON envelope.

NameTypeReqDescription
evidenceboolean––
fullboolean––
idstringyes–

No output schema declared.

No examples provided.

review ~229

Advisory Jev review of a terminal delivery against the parent's criteria (1-12). Read the automatic outcome in wait()/result first; do not resubmit the same delivery. Default prepares a local evidence packet without network; packets=True prepares separate claim packets and manifests offline (never submits). submit=True sends one request (unknown sends are never retried). Supply original_request from the coordinator to judge full scope; without it scope_assessment is unproven, which is neither a pass nor a contradiction. supported is advice, not acceptance. provider_choice is the raw answer; assessment includes local vetoes (missing, failed or mismatched evidence), which are not findings by the model. Jev never accepts, merges, deploys or retries the worker; local checks remain necessary. Key/budget errors are final for the call: keys only from `subtask jev setup`, never a tool argument.

NameTypeReqDescription
criteriaarrayyes–
idstringyes–
original_requeststring––
packetsboolean––
submitboolean––

No output schema declared.

No examples provided.

start ~436

Start one job; returns its id. kind: read|code|review|hard. Writes: repo= or isolation='worktree' (own branch). model: engine-specific model id (opencode, codex, kimi, API engines); omitted = the engine's default. verify: shell check run by subtask after the job; max_retries (0-5) resumes with the failure. invariants: default ['no_test_deletion','no_suppression'] fail verify on deleted/skipped tests or new noqa; [] = off. allowed_paths: files outside are reverted. symbol_scope: ['f.py::func'] only those defs may change; integrate merges by symbol. oracle_cmd: after verify passes, run on base and result; reports output_match and speedup_pct. adversarial: a Breaker job writes the tests first. context_refs: file:P[:A-B] | git:diff[:REF] | subtask:ID:summary|diff instead of pasting text; auto_repomap adds a symbol map. policy: worktree|sandbox|isolated|untrusted. tier: auto|fast|balanced|deep|free_only.

NameTypeReqDescription
adversarialboolean––
allowed_pathsarray––
auto_repomapboolean––
basestring––
context_refsarray––
contractobject––
cwdstring––
effortstring––
enginestring––
filesarray––
invariantsarray––
isolationstring––
kindstring––
max_retriesinteger––
max_turnsinteger––
max_usdnumber––
modelstring––
oracle_cmdstring––
policystring––
readonlyboolean––
repostring––
symbol_scopearray––
taskstringyes–
tierstring––
verifystring––

No output schema declared.

No examples provided.

start_many ~140

Start several jobs in one call. Items take start()'s arguments. With id + depends_on they form a group (grp-…) run as a DAG; subtask:<id>:summary in task/context_refs is replaced by the real job id. With Jev auto, the response includes advisory dependency checks; read them without treating them as permission. foreach=<parent id>: one copy per item of the JSON list the parent writes to .subtask/fanout.json ({{item}} in task), max 8; dependents wait for every copy. after='any': start when one parent succeeded.

NameTypeReqDescription
tasksarrayyes–

No output schema declared.

No examples provided.

status ~19

One line per job.

NameTypeReqDescription
idstring––

No output schema declared.

No examples provided.

steer ~52

Correct a job: hint (instruction sent when the attempt ends) | abort | retry (fresh job with the instruction).

NameTypeReqDescription
actionstringyes–
idstringyes–
instructionstring––

No output schema declared.

No examples provided.

stop ~18

Stop a job.

NameTypeReqDescription
idstringyes–

No output schema declared.

No examples provided.

wait ~198

Block until jobs or groups end and return their summaries. mode: all | any (first to end) | first_success (first done and verified; the rest are stopped). Returns early on a stalled job. since: cursor for clients without progress; with it, timeout is capped at 60 s. For Codex: wait(ids, mode='any', timeout=60, since=''), drop ended ids and pass back cursor=. An idle Codex 0.164.0 is not woken by ordinary local MCP progress or log notifications. Includes the automatic Jev delivery/evidence/risk advice, raw provider choice, wrapper assessment and next action: read it before a manual review and do not resubmit the same work.

NameTypeReqDescription
anyboolean––
idsarrayyes–
modestring––
sincestring––
stall_timeoutnumber––
timeoutinteger––

No output schema declared.

No examples provided.

Install

How do I install the subtask MCP server?

subtask runs locally as a PyPI package, launched with uvx subtask-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

pypi · subtask-mcp

# add to Claude Code
claude mcp add tedin7-subtask -- uvx subtask-mcp
Common questions

What is the subtask MCP server?

subtask is an MCP server listed in the public MCP registry as io.github.tedin7/subtask. Background sub-agents for Claude Code, Codex, Kimi and OpenCode, over MCP, with a spend cap. This page covers its PyPI package (subtask-mcp).

Is the subtask MCP server safe to use?

subtask scores 81 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 subtask MCP server expose?

subtask exposes 18 tools: plan, start, start_many, wait, status, and 13 more. Their descriptions and schemas cost roughly 1,867 tokens of context every time the server is loaded.

Is the subtask MCP server still maintained?

subtask 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 subtask MCP server under?

subtask declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.