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.

io.github.lvlrSajjad/sidecrew

NPM · SIDECREW · SCANNED SEP 27

Code changes and unit tests by local MLX models, behind a gate a machine can run.

Available components

82 Trust /100
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 Security98
  • No malware found by supply-chain analysis.Pass
  • No known CVEs affecting this package version or its production dependencies.Pass
  • No install/post-install scripts declared.Pass
  • 31 of 96 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 lvlrSajjad/sidecrew). View diagnostics → Pass
  • Clear OSI-approved license (MIT).Pass
  • Actively maintained (last published 2 days ago).Pass
  • Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability70
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 1750 tokens (~175/item across 10 items; 10 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 Management20
  • Stability observed for 6 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 100% of tool parameters carry a description.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 10 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • 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 supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Install

How do I install the io.github.lvlrSajjad/sidecrew MCP server?

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

npm · sidecrew

# add to Claude Code
claude mcp add lvlrsajjad-sidecrew -- npx -y sidecrew
// .cursor/mcp.json
{
  "mcpServers": {
    "lvlrsajjad-sidecrew": {
      "command": "npx",
      "args": [
        "-y",
        "sidecrew"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "lvlrsajjad-sidecrew": {
      "command": "npx",
      "args": [
        "-y",
        "sidecrew"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add lvlrsajjad-sidecrew -- npx -y sidecrew
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "lvlrsajjad-sidecrew": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "sidecrew"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add lvlrsajjad-sidecrew --command npx --arg -y --arg sidecrew
# ~/.hermes/config.yaml
mcp_servers:
  lvlrsajjad-sidecrew:
    command: "npx"
    args: ["-y", "sidecrew"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "lvlrsajjad-sidecrew": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "sidecrew"
      ]
    }
  }
}
# add to Vellum
assistant mcp add lvlrsajjad-sidecrew -t stdio -c npx -a -y sidecrew
// mcp.json
{
  "mcpServers": {
    "lvlrsajjad-sidecrew": {
      "command": "npx",
      "args": [
        "-y",
        "sidecrew"
      ]
    }
  }
}
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.

  • 26 Sept 26 +16
    • Malware scan: unverified → pass ▲ security
  • 25 Sept 26 0
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
  • 24 Sept 26 −13
    • Malware scan: pass → unverified ▼ security
    • Stability: unverified → 0.10 ▲ functional
    • Package version: 0.1.2 → 0.2.0 functional
  • 22 Sept 26 +15
    • Malware scan: unverified → pass ▲ security
  • 21 Sept 26 64

    First indexed and scored.

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 27 Sept 2026 · Analysed npm/sidecrew@0.2.0

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 npm
Reason Verified
Discovered via Registry attestation endpoint
Source repo lvlrSajjad/sidecrew
Certificate issuer https://token.actions.githubusercontent.com
Certificate SAN https://github.com/lvlrSajjad/sidecrew/.github/workflows/release.yml@refs/tags/v0.2.0
Rekor log index 2934820755
Predicate type https://slsa.dev/provenance/v1
Subject digest sha512:304032f91c50f7d9fa582bac63b1043ced07eeefb338c63423332ed9e0eb5e578979c56a525fb57ef55903d50e001ffc112f0e0a6dbb72653a13d4eab

Background: How many MCP packages publish verified provenance →

Dependencies 96 packages
Packages resolved 96
Stale 31
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 10 exposed · ~1,750 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
sidecrew_escalate ~176

What the local workers could not do, assembled for you to write yourself. Reads .sidecrew/runs/<id>/escalations.jsonl and returns each failed task with the exemplar and rules the worker had, plus both attempts' errors. Costs no worker tokens — it reads a finished run off disk. Two failures in here are NOT the test's fault and must not be rewritten as though they were: a stage_reached of 'mutation' means the mutation tool broke, and four mutation counts of zero mean nothing in that function could be mutated.

NameTypeReqDescription
dirstring–where runs/ lives; default .sidecrew
modelstring–recorded as suggested_model; sonnet unless you say otherwise
run_idstring–defaults to the most recent run under .sidecrew/runs

No output schema declared.

No examples provided.

sidecrew_fix ~281

Run a whole change plan on this machine: workload #2a, behaviour-preserving changes — type errors, renames, null guards, API migrations, dead code. For each task the local model rewrites the listed files whole, and a gate a machine can run decides what you see: the diff stayed confined to the task's files, tsc is clean in them with none introduced elsewhere, and every test that passed before still passes. Generation is local and costs zero Claude tokens; only the FixResult comes back, so you see survivors and escalations rather than raw worker output. SLOW — the project's own suite runs per candidate, about 4–5 minutes each, so a 12-task plan is roughly an hour. Validate the plan first. Use --dry-run/dry_run to capture the baseline and stop before the first token, which is how you find out the tsconfig or the suite is the problem.

NameTypeReqDescription
concurrencyinteger–candidates in flight; a ceiling, lowered when free RAM says so
dry_runboolean–capture the first step's baseline, write the tasks and prompts, then stop
keep_sandboxboolean–leave the sandbox on disk to inspect what the gate actually saw
plan_pathstringyespath to change_plan.json, written by the change-planner agent

No output schema declared.

No examples provided.

sidecrew_fix_escalate ~208

What the local workers could not change, assembled for you to do yourself. Reads a fix run's escalations.jsonl and returns each failed task with the files it was given and every attempt's verdict — which confinement rule fired, which tsc errors remain, which tests regressed. Costs no worker tokens; it reads a finished run off disk. TWO of these are NOT the worker's fault and must not be rewritten as though they were: machine_failure means the sandbox or the runner broke (exclude it from any rate you quote), and a non-null `refused` means the worker said the change cannot be made inside those files — which is usually a plan to fix rather than a change to write.

NameTypeReqDescription
dirstring–where runs/ lives; default .sidecrew
modelstring–recorded as suggested_model; sonnet unless you say otherwise
run_idstring–defaults to the most recent run under .sidecrew/runs

No output schema declared.

No examples provided.

sidecrew_fix_plan_validate ~213

Check a change_plan.json before a run spends anything on it, and REFUSE the tasks no worker could ever pass: a file too large to return whole (a worker rewrites whole files, so ~8k completion tokens is the ceiling), a pre-existing tsc error the ask does not cover (the gate requires zero errors in the task's own files, so such a task is unsatisfiable at any temperature), a file outside the tsconfig's program, two tasks in one step sharing a file. Call it after writing or editing a plan. The expensive half is a real tsc over the project — tens of seconds — and it is the half that produces the refusals; compile: false is the fast structural pass. Worth it: the gate costs about 262 s per attempt, so one refused task saves nine minutes.

NameTypeReqDescription
compileboolean–default true; false skips tsc and therefore skips the refusals
plan_pathstringyespath to change_plan.json

No output schema declared.

No examples provided.

sidecrew_generate ~83

One WorkerTask -> one candidate test, generated by the MLX model running on this machine. Costs zero Claude tokens and touches no network: it is an HTTP call to http://localhost:<port>/v1. Raw worker output — verify it before showing it to anyone.

NameTypeReqDescription
taskobjectyesthe task, as docs/specs/pipeline.md defines it

No output schema declared.

No examples provided.

sidecrew_plan_validate ~154

Check a test_plan.json before a run spends anything on it: it parses, its module and exemplars are on disk, every line range really is the function it names, and — unless verify_exemplars is false — every exemplar survives the verifier. Call it after writing or editing a plan. Verifying the exemplars is the expensive half: one verdict per shape, seconds on TypeScript and tens of seconds on Swift. A stale source_sha is a warning here and a refusal in sidecrew_run_batch.

NameTypeReqDescription
plan_pathstringyespath to test_plan.json
verify_exemplarsboolean–default true; false is the fast structural pass, and the report warns that it was used

No output schema declared.

No examples provided.

sidecrew_review ~202

Which survivors are worth reading, and in what batches. Survival is a filter, not an endorsement — a test that pins today's wrong answer kills every mutant — so this returns survivors below the mutation-score threshold plus a deterministic audit sample of the rest, batched under a token cap. The threshold is per language and defaults accordingly: a Swift score is computed over one or two mutants against TypeScript's six to twelve. Reads a finished run off disk; no worker tokens.

NameTypeReqDescription
audit_fractionnumber–of the survivors above the threshold; default 0.1
dirstring–where runs/ lives; default .sidecrew
max_batch_tokensinteger–estimated input tokens per batch; default 12000
run_idstring–defaults to the most recent run under .sidecrew/runs
thresholdnumber–overrides the per-language default (0.6 TypeScript, 1.0 Swift)

No output schema declared.

No examples provided.

sidecrew_run_batch ~168

Run a whole plan on this machine: for every function x shape, generate -> verify -> retry once with the error appended -> escalate. Generation is local and costs zero Claude tokens; only the BatchResult comes back, so you see survivors and escalations rather than raw worker output. Minutes, not seconds — roughly 10 s per TypeScript candidate and 40 s per Swift one.

NameTypeReqDescription
concurrencyinteger–candidates in flight; a ceiling, lowered when free RAM says so
dry_runboolean–write the tasks and report the concurrency, then stop before the first token
plan_pathstringyespath to test_plan.json
test_targetstring–Swift only: the test target under Tests/ (ADR-0014), overriding the plan

No output schema declared.

No examples provided.

sidecrew_status ~117

Is a local worker up, which model and revision it is serving, free RAM, and which verifier tools this project has. Call it before a run: everything else here needs a worker, and a missing stryker or muter is why a verdict would fail for a reason that is not the test's fault.

NameTypeReqDescription
portinteger–worker port; default 8000
projectstring–the project being verified — tsc/vitest/stryker are reported from its node_modules, not sidecrew's

No output schema declared.

No examples provided.

sidecrew_verify ~148

compile -> run -> mutate one candidate against the function its task_id names, and return a Verdict. Survive means it compiled, passed against the unmodified source, killed at least one mutant of that function, and was not tautological. Runs entirely on this machine.

NameTypeReqDescription
candidateobjectyeswhat a worker produced, or a hand-written test in the same shape
function_namestring–defaults to the part of task_id before the first colon
plan_pathstringyespath to the test_plan.json the candidate was generated from
test_targetstring–Swift only: the test target under Tests/ (ADR-0014), overriding the plan

No output schema declared.

No examples provided.

Common questions

What is the io.github.lvlrSajjad/sidecrew MCP server?

io.github.lvlrSajjad/sidecrew is an MCP server listed in the public MCP registry as io.github.lvlrSajjad/sidecrew. Code changes and unit tests by local MLX models, behind a gate a machine can run. This page covers its npm package (sidecrew).

Is the io.github.lvlrSajjad/sidecrew MCP server safe to use?

io.github.lvlrSajjad/sidecrew scores 82 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 27 September 2026. 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 io.github.lvlrSajjad/sidecrew MCP server expose?

io.github.lvlrSajjad/sidecrew exposes 10 tools: sidecrew_status, sidecrew_generate, sidecrew_verify, sidecrew_run_batch, sidecrew_plan_validate, and 5 more. Their descriptions and schemas cost roughly 1,750 tokens of context every time the server is loaded.

Is the io.github.lvlrSajjad/sidecrew MCP server still maintained?

io.github.lvlrSajjad/sidecrew is still listed as active in the MCP registry. We last reached this channel on 27 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.lvlrSajjad/sidecrew MCP server under?

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