Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Description from the maker (original English)
Read-only audit evidence for security, tests, native coverage, runtime failures and repair status.
These three are never merged into one score: opinions, measurements and popularity are different things.
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
Pick the AI app you use, then copy the settings.
You need
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"code-factory": {
"command": "uvx",
"args": [
"factoryline-code-factory",
"factory",
"mcp",
"serve"
]
}
}
}Run this in your terminal
claude mcp add code-factory -- uvx factoryline-code-factory factory mcp servePaste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"code-factory": {
"command": "uvx",
"args": [
"factoryline-code-factory",
"factory",
"mcp",
"serve"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Paste into .vscode/mcp.json in your project
{
"servers": {
"code-factory": {
"type": "stdio",
"command": "uvx",
"args": [
"factoryline-code-factory",
"factory",
"mcp",
"serve"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
Runs on your computer; the tool list appears in your AI app after you install it.
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 6, 2026
The registry name was verified with the GitHub account zrk222, which owns the repo
We have not read this repo from GitHub yet
We have not read this repo from GitHub yet
This one runs on your computer; there is no internet endpoint
Runs on your computer and uses local settings instead
Runs on your computer; we can only read tool lists from internet endpoints
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
The registry does not list a required key, though some servers ask you to sign in on first use.
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
The GitHub repo last changed –, and the latest version (0.48.2) reached the registry 22 days ago.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Python (uv) on your computer.
In the same category: Spec Driven Development, Remote Desktop Commander, Fomu MCP
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Kenya government form guides: checklists, draft letters, eCitizen, Huduma, timelines. Sample data.
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
Your agent handed you a change. Now you need to decide what to accept. Code Factory brings the findings, source context and recorded checks into one review trail. Inspect a finding, choose the repair, and rerun the affected checks. You keep the evidence with the change and the decision in your hands. Start with one command:
python -m pip install factoryline-code-factory
factory scan --root .
Your workflow: scan → review the findings → repair → run your tests and the affected checks again. The basic scan reads eligible Python source; it does not run your project. Missing evidence is INCOMPLETE, not a clean bill of health.
The Python source budget defaults to 2,000 files. factory scan --max-files 1000 sets a smaller per-run budget; over-budget scans stop explicitly without silently dropping files. This runtime budget is separate from CF's own architecture caps. Human output includes finding locations and audited/discovered source counts. Exit 0 means no blocking finding or failed check; advisories and missing evidence may remain. Exit 2 means blocked or invalid analysis. A clean Python static result does not establish runtime coverage or release approval. Use --static-only for the Python-only path; the default also orchestrates other applicable evidence lanes. JavaScript, shell and other language audits require external workers.
The bounded security review follows values through supported local helpers to HTTP, file, and SQL sinks, and checks an upload directory separately from its sanitized filename. Studio surfaces a shared next action; optional JEV integration remains advisory; unavailable evaluations stay incomplete. These changes are not a claim of exhaustive analysis or measured detection accuracy. Review findings, run the affected checks, and decide what to accept before using a repair.
Want a visual workspace? Run factory studio --root .. Need options? factory --help shows the short path; factory --help-all shows all commands. Start with the quick guide.
Keep pytest, mutation testing, CodeQL, Semgrep and your review checklist. CF adds test-quality findings and source-bound local evidence alongside them. A basic scan needs no adoption ceremony, signing keys, tenant setup or Docker. Native worker execution has separate setup and safety requirements.
Code Factory is the product. Its internal engines and advanced governance features are optional workflows, not prerequisites for reviewing your code.
Describe your idea to your coding agent and create PRD.md. The optional beginner guide helps turn it into concrete acceptance checks. For an existing repository, start with the scan above.
For a new builder, start with an idea and make the expected behavior concrete. For an experienced developer, start with the repository or proposed diff. SpecLine helps structure requirements; ForgeLine adds architecture and test-intent checks; Code Factory connects the findings, evidence and next action. The basic scan does not require those optional workflows.
Then inspect the findings, repair the code, and rerun the affected checks. Keep your coding agent and review services, including CodeRabbit, Devin or Blitzy. CF adds its combination of test-intent checks, optional runtime mutation evidence and local receipts bound to source. Review services also offer testing and analysis; CF's evidence helps you inspect the work alongside them.
Demonstration, October 16, 2026: the installed local CF runtime scanned one fictional Python file and reported two planted security findings. Studio shows 1/1 source files assessed and incomplete evidence. These are real sample-run observations, not an accuracy benchmark, a JetBrains IDE capture or a release approval. Unrun runtime lanes remain visible as not run.
Try the free local core on your own repository. If it helps, a GitHub star makes it easier to discover; fork it to improve a rule or contribute a reproducible positive and negative example. Reports of missed issues and false alarms are useful contributions too.
Code Factory + ForgeLine (CF/FL) is a robust, local-first code-audit factory. It starts by collecting local software review evidence for the candidate change. It connects requirements, architecture checks, Python AST security analysis, behavioral test evidence, workflow integrity, specialty AI review, and actionable repair. Its receipts support review; the tool does not certify software, guarantee that defects are absent, or approve a release.
Product naming: Code Factory is the product and ForgeLine is its audit and architecture engine. SpecLine, HSF, and Prestige are advanced internal lanes that appear only when a project declares the corresponding scope; they are not separate products a new user must learn before running a scan.
This full-page local capture shows Graph Ops tracing a change from sealed lineage through a forensic finding to a proposed recovery path. The guarded action remains locked; the dashboard is a read-only inspection surface.
The Counterfactual Arena compares repair candidates and shows their evidence and risk. Winner controls and the Evidence Frontier show how a reviewer can inspect the rationale and choose the next proof.
The current Graph Ops UI also separates native deep-scan progress, evaluated deep-audit receipts, six runtime lanes, and individual JUnit test cases. Each panel labels its evidence state and next repair. Filter or search the recorded tests, then load more cases as needed; an inventory or a missing report never appears as a passing run. The JUnit reader accepts up to 10,000 cases and marks larger or malformed reports incomplete. A JUnit report is local observation without a current-candidate binding.
This local UI capture shows each reported test case with its status. The audit cards keep checks without a bound result explicitly marked not run.
Supplement: annotated live Assembly telemetry
The labels explain an original local Assembly capture. That pictured run is waiting for human input; it does not imply release approval or that every check passed.
factory scan --root . --deep
Deep mode orchestrates architecture, Python security and test-oracle checks, workflow integrity, requirements, runtime coverage, and dependency evidence. Languages including TypeScript/JSX, Go, Rust, Java, C/C++, C#, Ruby, PHP and Swift are inventoried explicitly; missing native analysis remains unmeasured.
For authorized native execution, use:
factory scan --root . --deep --worker-config .factory/worker-config.json --json
The configuration contains workspace-relative manifest, authorization, and trust_root paths plus manifest_sha256 and trust_root_sha256 pins. This invokes the existing signed Docker worker engine for configured CodeQL, Semgrep, secrets, dependency, container, runtime and fuzz lanes. Unsigned plans are rejected. Completed workers still require independent agent review; missing evidence and review cannot produce a passing verdict. Native execution requires its configured images and tooling and can take longer than a minute. Each unresolved lane includes its next action. Receipt presence alone is not verification, and no scan claims to detect every defect.
Package metadata now uses Production/Stable, starting with this source update. That release-status label is separate from detection accuracy, independent benchmark results, and provider publication.
In an interactive terminal, factory optionally makes one plain PyPI version check and caches the result for up to 24 hours, then prints a notice when a newer version is available. It never downloads or installs the update. The check is quiet in CI, JSON output, server/MCP, help, version, and non-interactive runs; set FACTORY_DISABLE_UPDATE_CHECK=1 to turn it off. The optional request does not include a project path, account identifier, or usage data. All audit and proof commands remain local unless an operator explicitly uses a separate provider integration.
Run repository commands from the project being reviewed. factory guide is a read-only orientation; it does not run tests or agents.
These commands show the current architecture policy, the bounded static security scan, and the runtime-audit setup:
factory architecture health --root . --json
factory audit security --root . --json factory runtime-audit status --root . --json
factory audit security checks a limited set of source patterns. It is not a penetration test. The runtime audit needs a separately reviewed plan and its own environment evidence. A status of NOT_RUN or a clean static scan is not a complete project audit.
To display individual tests in Graph Ops, run your suite with a JUnit report at .factory/test-reports/pytest.xml (for example, python -m pytest --junitxml=.factory/test-reports/pytest.xml). The local Studio reads the report and labels its candidate binding UNBOUND; it does not infer that those results still apply after source changes.
The prior snapshot's repository self-audit receipt records A (97.9/100) and 1,055/1,085 functions attributed to test intent (97.24%). That static measurement applies to its recorded source digest and is superseded for this candidate by the clean tracked-snapshot result above; it is not runtime coverage or certification.
ForgeLine 0.10.8 computes Python complexity for public module functions and public class methods in its recorded metrics.scope.code_files; names starting with _ are excluded. Its AST metric counts branches, boolean alternatives, exception handlers, with, and assertions. Ruff C901 uses a different McCabe metric and also checks private functions. CI therefore runs python -m ruff check --select C901 factoryline tests separately at limit 10. The ForgeLine maximum must not be read as the maximum of every Python function. CI also checks action and reusable workflow references for immutable commit pins; the generic workflow evidence validator alone does not inspect those refs.
Candidate preflight requires release-cadence admission and strict architecture health. Protected main requires CI and a separate specialty AI source review; the coordinator records that assessment, separately from test evidence.
Only the beginning is shown; read the rest in the repo