create-starter scaffolds projects from Starter Series templates and audits repos for release, CD, CI-security, and agent-instruction hygiene — 9 read-only-or-dry-run MCP tools sharing one engine with the CLI.
Scaffold — create_project builds a new repo from a template with a validated name (^[A-Za-z0-9][A-Za-z0-9_-]*$), optional description, output dir, and git init.
Discover — list_templates returns the template table (id, name, stack, category, description).
Audit release readiness — audit_release reports matched starter, version/last-tag drift, CHANGELOG drift vs merged PRs, publish-workflow kind, and a ship-ready verdict with blockers/warnings.
Audit publishing — audit_cd probes npm, PyPI, Open VSX, VS Marketplace, AMO, and GitHub Releases for per-destination drift (in-sync / needs-publish / local-stale / not-found / unsupported).
Audit security hygiene — audit_security checks 9 items (gitleaks, CodeQL, dep audit, license check, --ignore-scripts, Dependabot, secret scanning, claude-code-security-review, security guidance) and returns hardened / needs-attention / soft.
Audit agent instructions — audit_instructions finds exact duplicates, cross-file surface overlap, and advisory keyword risk summaries (not semantic drift detection).
Produce a handoff — generate_launch_proof_report runs all four audits and returns a client-ready Markdown Launch Proof Report with gates, blockers, and an overall verdict.
Remediate — add_component dry-run lifts a starter's CI/CD layer (ci / security / dependabot / maintenance / all) into an existing repo; seed_security_guidance drafts claude-security-guidance.md.
Safe by design — audits are read-only, add_component writes nothing unless dry_run: false, and nothing rewrites app code or secrets-bearing workflows.
Note — the schema's create_project template enum lists 11 templates (incl. discord-bot, telegram-bot, electron-app, react-native, cloudflare-pages) while the README says only 6 public templates are generatable; the README's note that other former templates can still be audited may explain the gap.
Scaffolds browser extensions targeting Chrome Web Store (MV3) and audits CD status.
Scaffolds projects for Cloudflare Pages using Wrangler.
Scaffolds Discord bots using discord.js v14 with Docker support.
Scaffolds Docker-deployable projects for any language with GHCR and SSH deploy.
Scaffolds cross-platform Electron apps with code signing.
Scaffolds React Native (Expo) projects with EAS build.
Scaffolds browser extensions targeting Firefox (MV3) and audits CD status.
Audits GitHub Releases publication status.
Audits npm package publication status against the repository.
Audits PyPI package publication status against the repository.
Scaffolds Python MCP server projects using FastMCP.
Planned support for auditing Railway deployments.
Scaffolds Telegram bots using grammY with Docker support.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@create-starter list available templates"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Scaffold and audit Starter Series projects — MCP server, Claude Code skill, and CLI in one package.
Part of: Human-Controlled AI Systems — scaffolding is the easy half. What keeps a shipped repo trustworthy is the audit primitives (audit, audit-cd, audit-security) verifying release, CD, and CI security hygiene against a known bar — gating each merge instead of asking a human to re-check by hand.
Korean documentation is maintained under docs/ko/README.md; the root README stays English-only.
Security checks inspect local workflow definitions and referenced starter-series/.github policy, including composite actions and invoked scripts. Evidence includes source paths and content hashes. Unreadable or unsupported reusable workflows are reported as unverified; this checks configuration, not the latest Actions run or a live vulnerability scan.
CLI — package and binary identity are starter-series; npx starter-series my-package --template npm-package scaffolds one of 6 public templates with Zod-validated input, atomic rename on success, retry + timeout + 50 MB download cap.
MCP server — nine stdio tools: list_templates, create_project, audit_release, audit_cd, audit_security, audit_instructions, generate_launch_proof_report, seed_security_guidance, add_component. One binary chooses the mode by argv (positional -> CLI, none -> MCP stdio).
Claude Desktop extension — .mcpb bundle on every release; drag onto the Claude Desktop settings window.
Claude Code plugin + skill — /plugin install create-starter@starter-series ships the MCP server and the conversational create skill together.
MCP Registry metadata — io.github.starter-series/create-starter; registry submission is gated on the unscoped npm package being live and tarball-verified.
audit_release — detects matched starter, version vs last-tag drift, CHANGELOG drift vs merged PRs (git log <tag>..HEAD), publish-workflow kind (release-please / publish-on-tag / auto-release).
audit_cd — probes npm, PyPI, Open VSX, VS Marketplace, AMO, GitHub Releases for per-destination publish drift (in-sync / needs-publish / local-stale / not-found / unsupported).
audit_security — checks 9 items: 8 core CI primitives (gitleaks with pin check, CodeQL, dependency audit, license check, --ignore-scripts, Dependabot grouped, secret-scanning hint, claude-code-security-review Action) plus the optional repo-author claude-security-guidance.md. The 8 core checks gate the HARDENED verdict; this repo passes 8/8 core.
audit_instructions / audit-instructions — reviews agent instruction files (AGENTS.md, CLAUDE.md, GEMINI.md, Copilot instructions) for exact same-file duplicates, cross-file surface overlap, and keyword-based risk reminders. Duplicate/overlap findings need review; keyword risk summaries are advisory only and not exhaustive safety or semantic drift detection.
proof-report / generate_launch_proof_report — runs release, CD, security, and instruction-review audits together and writes a client-ready Launch Proof Report. This is the monetizable handoff surface: evidence first, no "certified" claim, exit code 1 unless the repo is actually launch-ready.
add_component — the remediation half of the audit loop: lifts a starter's CI/CD layer (ci / security / dependabot / maintenance / all) into an existing repo without re-scaffolding. Dry-run by default with a per-file plan (create / identical / skip-exists / overwrite); refuses a dirty git tree unless forced; never touches app code or secrets-bearing CD workflows. The dry-run plan doubles as a drift report against the starter.
Graduation guide — docs/graduation-from-vibe-coding.md (+ Korean): five-step path from Lovable/Bolt/v0 exports to GitHub Actions + a real deploy target, using the release/CD/security audit primitives.
Related MCP server: MCP Server Boilerplate
audit_cd support for Chrome Web Store, EAS, Railway, Fly, and GHCR. Currently reported as unsupported because those destinations require auth or have no public read API.
One binary, two surfaces. CLI and MCP stdio share one scaffolding engine. Argv decides which surface answers. No duplicated logic for "the same thing called from a human vs an agent".
Atomic on failure. Extraction happens in a sibling .<name>-incomplete-<rand> directory and only renames into the final path on success. Network failure, corrupt archive, partial write — none of them leaves a half-scaffolded directory behind.
Audit is first-class. Templates ship a security baseline (gitleaks pinned to SHA, CodeQL, Dependabot grouped, --ignore-scripts, claude-code-security-review). The audit commands check whether a downstream repo still matches that bar — turning the baseline from a one-time scaffold into an ongoing gate.
Eat your own dogfood. This repo passes audit_security 8/8 core checks (HARDENED); the 9th is the optional claude-security-guidance.md. If the tool that audits other repos can't pass its own bar, the bar isn't real.
Read-only outside its sandbox. Downloads are capped (50 MB, 30 s timeout, 3 retries). Relative output paths cannot escape cwd; absolute paths are accepted only as explicit user intent. git init failure is logged but non-fatal.
Full vendor parity in audit_cd. Destinations without a public read API stay unsupported rather than reporting confidently-wrong state.
Rewriting app code. The graduation flow lifts CI/CD from the matching starter; it never touches application code.
A general-purpose project generator. Templates are the 6 public Starter Series templates. New stacks land as new starters, not as flags on create_project.
Semantic instruction drift or AI safety enforcement. audit_instructions is a review aid for exact duplicate/surface overlap and keyword reminders. It is not a semantic similarity engine, runtime guardrail, red-team harness, or exhaustive safety/security linter.
npx starter-series my-package --template npm-package
# Or build from a create-starter checkout:
npm ci
npm run build
node dist/index.js my-package --template npm-packagestarter-series — scaffold a project from the Starter Series.
Usage
starter-series <name> --template <id> [options]
starter-series audit [path]
starter-series audit-cd [path]
starter-series audit-security [path]
starter-series check [path] [--instructions]
starter-series audit-instructions [path]
starter-series proof-report [path] [--output <file>] [--stdout]
starter-series seed-security-guidance [path] [--force]
starter-series add-component [path] [--component <g>] [--starter <id>] [--apply] [--force]
starter-series --list
starter-series --help
Options
-t, --template <id> Template ID (see --list)
-d, --description <text> One-line project description
-o, --output-dir <path> Output directory (default: ./<name>)
--no-git Skip "git init" after scaffold
--output <file> proof-report output (default: <path>/launch-proof-report.md)
--stdout print proof-report Markdown; with --output, also writes the file
--component <group> add-component group: ci, security, dependabot, maintenance, all
--starter <id> add-component source starter override
--apply Write the add-component plan (default is dry-run)
--force Overwrite differing component files or guidance
--list List templates and exit
-h, --help Show help and exit
-v, --version Print version and exit
Environment
CREATE_STARTER_DEBUG=1 Emit verbose stderr logsID | Stack |
| TypeScript + |
| Python + FastMCP |
| Jest + ESLint + OIDC publish |
| Chrome/Firefox MV3 |
| VS Marketplace + Open VSX |
| any language + GHCR + SSH |
Only the six public templates listed here are available for generation and component downloads. Existing projects based on former templates can still be audited.
Run starter-series --list (CLI) or call list_templates (MCP) for the authoritative, up-to-date list.
Already have a working app on a vibe-coding platform and want to graduate to GitHub Actions + your own deploy target? Read docs/graduation-from-vibe-coding.md (한국어) — a 5-step path that uses audit, audit-cd, and audit-security to diagnose your repo, then lifts CI/CD from the matching starter without rewriting your app code.
git clone https://github.com/starter-series/create-starter
cd create-starter
npm install
npm run buildRequires Node.js ≥22.
Grab the latest .mcpb bundle from the Releases page and drag it onto the Claude Desktop settings window. Claude Desktop unpacks the bundled dist/ and node_modules/ and registers create-starter as an MCP server — no npm, no config file, no absolute path.
.mcpb(MCP Bundle, formerly.dxt) is Anthropic's packaged extension format for MCP servers. See Desktop Extensions.
To rebuild the bundle locally:
npm ci
npm run bundle:mcpb # produces create-starter-<version>.mcpbRegister the built binary in your MCP client (Claude Desktop, Cursor, etc.):
{
"mcpServers": {
"create-starter": {
"command": "node",
"args": ["/absolute/path/to/create-starter/dist/index.js"]
}
}
}Then ask your agent: "Use create-starter to scaffold a new discord bot named my-bot." The agent will call list_templates if needed and then create_project.
The binary speaks MCP stdio when called with no extra arguments, and switches to CLI mode when given any positional argument or flag. Both modes share the same scaffolding engine.
The plugin bundles both the MCP server and the create skill — one install wires them up together.
From the Claude Code REPL:
/plugin marketplace add starter-series/create-starter
/plugin install create-starter@starter-seriesThen ask Claude: "scaffold a new discord bot named my-bot" and the create-starter:create skill guides the conversation into the MCP tools.
For local development (no marketplace round-trip):
claude --plugin-dir /path/to/create-starterPoint at a git clone so edits in skills/create/SKILL.md or dist/index.js take effect the moment the session starts.
After registry publication, this server uses the Official MCP Registry namespace:
io.github.starter-series/create-starterMCP-compatible clients that integrate registry discovery can install it by name without manual path wiring. The registry entry points at the npm package starter-series, so the registry step must run only after the npm package is published and verified.
Ownership is verified through GitHub OIDC (namespace io.github.starter-series/*) and npm tarball inspection (package.json#mcpName). See .github/workflows/publish-mcp-registry.yml for the publish flow.
For npm release setup (trusted-publisher registration, including the post-2026-05-20 allowed-action step), see docs/RELEASING.md.
Scaffolding:
list_templates — returns the full template table as JSON.
create_project — args:
template (required) — template ID from the table above.
name (required) — project name matching ^[A-Za-z0-9][A-Za-z0-9_-]*$.
description (optional) — one-line description.
output_dir (optional) — defaults to ./<name> relative to the MCP server's cwd. Relative paths must stay inside cwd; absolute paths are accepted as explicit user intent.
init_git (optional, default true) — run git init after scaffold.
Audit (each takes an optional path arg, default = MCP server cwd; all read-only):
audit_release — release-readiness diagnosis. CLI mirror: starter-series audit [path].
audit_cd — per-destination publish-drift probe. CLI mirror: starter-series audit-cd [path].
audit_security — baseline CI security hygiene check. CLI mirror: starter-series audit-security [path].
audit_instructions — agent-instruction duplicate and surface-overlap review, with advisory keyword risk summaries. CLI mirror: starter-series audit-instructions [path].
generate_launch_proof_report — combined Markdown launch handoff from release, CD, security, and instruction-review audits. CLI mirror: starter-series proof-report [path] [--output <file>] [--stdout].
seed_security_guidance — generate a starter-aware claude-security-guidance.md draft. CLI mirror: starter-series seed-security-guidance [path] [--force].
add_component — propose or apply starter CI/CD components to an existing repo as a dry-run plan. CLI mirror: starter-series add-component [path] [--component <g>] [--starter <id>] [--apply] [--force].
Project names are regex-validated before any filesystem touch; relative output paths are rejected if they escape the working directory.
Downloads enforce a 30 s timeout, 3-attempt exponential backoff, and a 50 MB size cap.
Extraction happens in a sibling .<name>-incomplete-<rand> dir; on any failure (network, corrupt archive, extraction error) the tmp dir is removed. The final path only appears via an atomic rename once everything succeeded.
git init failures are logged to stderr but do not fail the scaffold; the project is usable without a .git directory.
Every Starter Series template ships with the 9 checks audit_security looks for — no opt-in required:
Check | What it catches |
gitleaks (SHA256-pinned manual install) | Committed secrets in code or history |
CodeQL (weekly + PR) | Static analysis for JS/TS/Python |
Dependency audit ( | Known CVEs in transitive deps |
License check | GPL/AGPL contamination |
| Malicious postinstall scripts |
Dependabot grouped updates | Lockfile-conflict storms from one-by-one bumps |
GitHub secret scanning + push protection | Tokens leaked at push time |
| AI-based diff review |
| Org-specific rules consumed by Anthropic's in-session Claude Code Security Guidance Plugin (released 2026-05-26) |
This was Vercel's stack during their 2026-04-21 npm supply-chain incident — they pre-empted compromise via the same pre-wired checks plus Socket/npm/GitHub coordination. The Starter Series ships those checks pre-wired in every starter.
MIT © heznpc
starter-series check --instructions [path]
starter-series check --instructions [path] --json
starter-series check --instructions [path] --update-statecheck without --instructions runs the existing release, CD, security and instruction audits. audit-instructions remains a compatible alias. MCP clients keep using audit_instructions(path?, update_state?); the library entry remains auditInstructions(path?, { updateState? }).
One scan covers AGENTS/CLAUDE/GEMINI, overrides, Copilot instructions, Cursor rules, Claude rules/skills and .agents rules/skills/workflows. The check reports import and symlink aliases, verbatim mirrors, local overrides, exact duplicates and cross-file overlap. Canonical selection is inferred from links and filenames unless explicitly configured. It does not detect semantic similarity. Instruction source files are never rewritten.
Optional .starter-series/instructions.json selects a canonical source and records owner decisions. Copy the exact id, evidenceHash and paths from the JSON report into a decision's id, evidenceHash and scope; then explicitly supply the owner's reason, identity and approval date:
{
"schemaVersion": 1,
"canonical": "AGENTS.md",
"decisions": []
}Each decision requires reason, approvedBy, approvedAt (YYYY-MM-DD), and at least one of reviewAfter, expiresAt (YYYY-MM-DD) or reviewReason. A decision only accepts its exact finding and scope. Evidence changes, expiry or a due review make it stale; approval is never generated by the checker. Accepted findings remain visible. This file records owner approval; it is not an authentication mechanism.
Checks are read-only by default. --update-state (or MCP update_state: true) explicitly saves .starter-series/instructions-state.json for new/changed/known/resolved delta comparison. State contains identities and evidence hashes, not instruction text; commit it only if the team wants a shared baseline. Malformed metadata fails the check. Exit codes remain 0 for clean/advisory or accepted findings, 1 for pending/stale review findings, and 2 for usage or operational errors.
Lift a starter's CI/CD layer into an EXISTING repo without re-scaffolding — the remediation half of the audit loop (audit_security/audit_release diagnose; this installs the missing files from the matching starter). Components: ci (.github/workflows/ci.yml), security (codeql.yml + SECURITY.md), dependabot (dependabot.yml + auto-merge), maintenance (stale + weekly health check), or all. DRY-RUN BY DEFAULT: returns a per-file plan (create / identical / skip-exists / overwrite) and writes nothing until dry_run is false. Existing-but-different files are skipped unless force — so the dry-run plan doubles as a drift report against the starter. Never touches app code or secrets-bearing CD workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to the repo (default: the MCP server's cwd). Use the absolute path of the project the user is working in. | |
| force | No | Overwrite files that differ from the starter AND allow applying onto a dirty git tree. Default false. | |
| dry_run | No | Preview only (default true). Set false to write the planned files. | |
| starter | No | Template id to lift from (see list_templates). Auto-detected from the repo when omitted. | |
| component | No | Which group to lift (default: all). |
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| dryRun | Yes | |
| starter | Yes | |
| written | Yes | |
| repoPath | Yes | |
| warnings | Yes | |
| component | Yes | |
| starterSource | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so excellently. It discloses dry-run default, per-file plan statuses, skip/overwrite behavior for existing files, force semantics, and explicitly states it 'Never touches app code or secrets-bearing CD workflows.' This is rich behavioral context beyond any schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with the main action, but it is longer than the 'two sentences' ideal. However, every sentence contributes essential information (component taxonomy, dry-run behavior, force semantics, safety boundary). No filler, but a slightly tighter structure would earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fully complete for a complex tool with 5 optional parameters and an output schema. It covers purpose, usage context, parameter semantics, and safety limitations. Since an output schema exists, not describing return values is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial meaning: it details the contents of each component (ci, security, etc.), explains auto-detection for starter, describes dry_run behavior and force implications on dirty trees. This goes well beyond the schema property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Lift a starter's CI/CD layer into an EXISTING repo') and specifies the resource (CI/CD components). It distinguishes itself from siblings by framing it as the 'remediation half of the audit loop' opposite to audit_security/audit_release, and from create_project by noting 'without re-scaffolding.' This meets the 5-level bar for specific verb+resource+scope and sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use: after audits diagnose, as the remediation step to install missing files. It also implies when not to use (instead of re-scaffolding with create_project) and names the diagnostic sibling tools. This is clear, contextual usage guidance with exclusions implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the local repo's version has been published to its destination registries (npm, PyPI, Open VSX, VS Marketplace, AMO, GitHub Releases). Makes outbound HTTPS requests to public registry APIs; never mutates. Reports per-destination drift (in-sync / needs-publish / local-stale / not-found).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to the repo to audit (default: the MCP server's cwd). Use the absolute path of the project the user is working in. |
| Name | Required | Description |
|---|---|---|
| overall | Yes | |
| repoPath | Yes | |
| destinations | Yes | |
| localVersion | Yes | |
| versionSource | Yes | |
| matchedStarter | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and does well: it discloses that the tool makes outbound HTTPS requests to public registry APIs and never mutates, plus enumerates the four outcome states (in-sync / needs-publish / local-stale / not-found). It stops short of noting network-failure behavior or rate limiting, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with zero filler: purpose first, then network/read-only behavior, then the returned states. Front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be re-explained, and the description already summarizes the read-only network profile and drift outcomes. The only material gap is the lack of differentiation from the audit_release sibling, which matters in this crowded audit_* family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'path' parameter is already fully documented in the schema, including its default. The description adds no additional parameter syntax or semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Check whether the local repo's version has been published to its destination registries', and enumerates the exact registries (npm, PyPI, Open VSX, VS Marketplace, AMO, GitHub Releases). However, it does not distinguish itself from the similarly-named sibling audit_release, leaving the agent to infer the boundary between the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (verify publish state of a local release before/after publishing), but there is no explicit when-to-use, when-not-to-use, or routing to an alternative such as audit_release. Nothing tells the agent which of the several audit_* siblings is appropriate for a given situation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check local instruction discovery, source topology, exact duplicates/overlap, owner decisions and previous-run delta. Read-only by default; update_state explicitly saves the baseline, never source instructions. No semantic or safety enforcement.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to the repo to audit (default: the MCP server's cwd). Use the absolute path of the project the user is working in. | |
| update_state | No | Explicitly save the current instruction delta baseline; default false. |
| Name | Required | Description |
|---|---|---|
| files | Yes | |
| review | Yes | |
| overall | Yes | |
| repoPath | Yes | |
| topology | Yes | |
| duplicates | Yes | |
| riskSummaries | Yes | |
| surfaceOverlaps | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses read-only-by-default behavior, that update_state explicitly saves a baseline, that source instructions are never modified, and that no semantic or safety enforcement is applied (an important scope limit). It does not mention permissions or rate limits, but the core safety/mutation profile is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler; the scope of checks is front-loaded and the behavioral caveats follow immediately. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the two-parameter surface is simple. The description covers the mutation semantics and limits adequately; the only real gap is the absence of guidance on choosing this audit over the sibling audits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema for update_state: it clarifies what is persisted (the delta baseline) and what is expressly out of scope ('never source instructions'). The path parameter's guidance is left to the schema, which already documents it fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Check') and enumerates the exact resource surface: local instruction discovery, source topology, duplicates/overlap, owner decisions, and previous-run delta. That enumeration clearly separates it from sibling audits (audit_security, audit_release, audit_cd), so an agent can distinguish it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the enumerated checks tell the agent this is the tool for auditing project instruction files, but there is no explicit when-to-use statement, no prerequisites, and no routing against siblings like audit_security. The agent must infer the trigger condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit a local repo for release-readiness against the Starter Series quality bar. Detects matched starter, CHANGELOG drift vs merged PRs, version-bump status, and publish-workflow presence. Read-only; never mutates the repo.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to the repo to audit (default: the MCP server's cwd). Use the absolute path of the project the user is working in. |
| Name | Required | Description |
|---|---|---|
| version | Yes | |
| repoPath | Yes | |
| changelog | Yes | |
| shipReady | Yes | |
| matchedStarter | Yes | |
| publishWorkflow | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does state the safety profile explicitly: 'Read-only; never mutates the repo.' It also enumerates the detection categories. It does not cover prerequisites (e.g., repo must be a git checkout with a remote), permissions, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences: purpose first, then the specific checks, then the safety guarantee. No filler and every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be described, and read-only behavior is covered. The remaining gap is minor: no mention of prerequisites or environment assumptions for the audit to succeed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single path parameter is fully documented in the schema, including the cwd default and the advice to use absolute paths. The description adds only that the target is 'local', so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (audit) and resource (local repo) plus the exact scope: release-readiness against the Starter Series quality bar. The enumerated checks (matched starter, CHANGELOG drift vs merged PRs, version-bump status, publish-workflow presence) make it easy to distinguish from siblings like audit_security, audit_cd, and audit_instructions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'release-readiness' implies the usage context (pre-release gating), but there is no explicit when-to-use or when-not-to-use guidance, and no routing to sibling audit_* tools. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit a local repo for baseline security CI hygiene against the Starter Series quality bar: gitleaks, CodeQL, dependency audit, license check, --ignore-scripts, Dependabot, secret-scanning hints, claude-code-security-review Action, and claude-security-guidance.md. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to the repo to audit (default: the MCP server's cwd). Use the absolute path of the project the user is working in. |
| Name | Required | Description |
|---|---|---|
| checks | Yes | |
| overall | Yes | |
| summary | Yes | |
| repoPath | Yes | |
| ecosystem | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly states 'Read-only' and enumerates the specific checks performed, providing behavioral context despite no annotations. Does not mention potential side effects, but read-only covers the main risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the audit target, then lists checks, and ends with read-only. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the tool's purpose, scope, and read-only nature; output schema exists for return details. For a single-parameter read-only audit, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema fully documents the single 'path' parameter with default and usage guidance; description adds no param details beyond schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it audits a local repo for baseline security CI hygiene, listing specific checks (gitleaks, CodeQL, etc.). Distinguishes from sibling audit tools (audit_release, audit_cd, audit_instructions) via the security focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for security CI hygiene validation against the Starter Series quality bar, but does not explicitly state when to use this over siblings or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scaffold a new project from a Starter Series template
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Project name (alphanumeric start, '-' or '_' only) | |
| init_git | No | Initialize a fresh git repo after scaffold (default: true) | |
| template | Yes | Template ID (use list_templates to see options) | |
| output_dir | No | Output directory (defaults to ./<name>, relative to the MCP server's cwd) | |
| description | No | One-line project description |
| Name | Required | Description |
|---|---|---|
| path | Yes | |
| filesReplaced | Yes | |
| filesExtracted | Yes | |
| gitInitialized | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It only implies file creation via 'Scaffold' and omits side effects such as git initialization (default true), output directory behavior, overwrite handling, and required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It is appropriately concise for a tool whose parameter details are fully covered by the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter creation tool with no annotations, the description is incomplete. Although output schema and parameter descriptions are rich, the description omits usage guidance, side effects, and behavioral context needed to invoke the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters thoroughly. The description adds no additional parameter meaning beyond what the schema provides, making the baseline score of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Scaffold') and resource ('new project') with a clear source ('Starter Series template'). It distinguishes the tool from sibling audits and add_component by being project-level, but it does not explicitly name alternatives like list_templates or add_component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The phrase 'from a Starter Series template' hints at a prerequisite, but the description never mentions list_templates or explains selection relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run audit_release, audit_cd, audit_security, and audit_instructions together, then return a client-ready Markdown Launch Proof Report. Read-only by default; set write=true to write launch-proof-report.md or output_path inside the target repo.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to the repo to audit (default: the MCP server's cwd). Use the absolute path of the project the user is working in. | |
| write | No | Write the Markdown report to disk. Default false. | |
| output_path | No | Report file path. Relative paths are resolved inside the target repo. Ignored unless write=true. |
| Name | Required | Description |
|---|---|---|
| gates | Yes | |
| overall | Yes | |
| blockers | Yes | |
| markdown | Yes | |
| repoPath | Yes | |
| warnings | Yes | |
| outputPath | Yes | |
| generatedAt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden and does well: it discloses the default read-only behavior and the mutation side effect of writing to disk when write=true, plus where the file lands. Lacks detail on permissions, error handling, or whether the individual audits still run when write=true, but the core safety/mutation profile is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and followed by the write behavior. Every clause earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not explain return values, and it covers the composition, the read-only default, and the write destination. No annotations to compensate for, and all 3 parameters are schema-documented. Complete for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents path, write, and output_path fully. The description reinforces the write/output_path relationship (write=true writes to the repo) but adds no syntax beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (run/generate) and resource (Launch Proof Report), and explicitly distinguishes itself from siblings by naming the four audit tools it composes (audit_release, audit_cd, audit_security, audit_instructions). An agent can tell this is an aggregate/report tool versus the individual audit tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains composition (runs the four audits together) and the write toggle condition, giving clear context for use. Does not state when NOT to use it (e.g., when only one audit dimension is needed), but the 'together' framing implies the aggregate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Starter Series project templates
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| templates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'List' implies a read-only operation, but the description does not explicitly state side effects, authentication needs, or return format. However, for a simple list tool, this is minimally acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that fully conveys the tool's purpose without redundancy. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and an output schema exists, the description is complete. It fully explains what the tool returns (a list of templates) and requires no additional context. The full sentence 'List all available Starter Series project templates' provides sufficient information for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter descriptions. The description appropriately states the scope ('all available') and does not need to explain any parameter semantics. The baseline of 4 for zero parameters applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and resource ('all available Starter Series project templates'), making it distinct from sibling tools like generate_launch_proof_report or create_project. It clearly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys usage: this is for retrieving templates, while sibling tools are for generating reports, adding components, or creating projects. Although no explicit exclusions or alternatives are mentioned, the context is clear enough for an agent to choose this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a starter claude-security-guidance.md at the repo root, tailored to the detected Starter Series template. The file is consumed in-session by Anthropic's Claude Code Security Guidance Plugin (released 2026-05-26) as a guard while Claude writes code. Use force: true to overwrite an existing file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to the repo (default: the MCP server's cwd). Use the absolute path of the project the user is working in. | |
| force | No | Overwrite an existing claude-security-guidance.md. Default false (returns status='exists' instead). |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| filePath | Yes | |
| repoPath | Yes | |
| bytesWritten | Yes | |
| relativePath | Yes | |
| matchedStarter | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool writes a file at the repo root, that the generated content varies by detected template, and that force overwrites an existing file. It could say more about permissions or failure modes, but the schema covers the default 'exists' status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded and only three sentences, with the core action first and the overwrite instruction last. The plugin release date is minor trivia that does not help an agent invoke the tool, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter write tool with full schema coverage and an output schema, the description supplies enough context: what file, where, why it exists, and how to overwrite. It is close to complete, though it omits any note on what happens when no Starter Series template is detected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters are fully documented there (path defaults to cwd, force defaults to false). The description only reiterates the force overwrite behavior already stated in the schema, so it adds little parameter meaning beyond the structured field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Generate a starter `claude-security-guidance.md` at the repo root'. It also adds the tailoring condition (detected Starter Series template), which clearly separates it from the audit_* siblings that inspect rather than create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for use: the file is consumed by the Claude Code Security Guidance Plugin and acts as a guard while Claude writes code, and explains that force: true should be used to overwrite. It does not name a when-not or a direct alternative, but no sibling offers the same seeding function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.5.3audit_cd8 fields changedOutput schema / properties / destinations / items / properties / publishedAt / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / destinations / items / properties / publishedAt / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / destinations / items / properties / publishedVersion / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / destinations / items / properties / publishedVersion / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / localVersion / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / localVersion / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / matchedStarter / properties / id / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / matchedStarter / properties / id / typeAdded value: +[
+ "string",
+ "null"
+]audit_instructions4 fields changedInput schema / properties / update_stateAdded value: +{
+ "description": "Explicitly save the current instruction delta baseline; default false.",
+ "type": "boolean"
+}Output schema / properties / reviewAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "delta": {
+ "additionalProperties": false,
+ "properties": {
+ "changed": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "known": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "new": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "resolved": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "new",
+ "changed",
+ "resolved",
+ "known"
+ ],
+ "type": "object"
+ },
+ "findings": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "decision": {
+ "enum": [
+ "pending",
+ "accepted",
+ "stale"
+ ],
+ "type": "string"
+ },
+ "evidenceHash": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "duplicate",
+ "overlap",
+ "topology"
+ ],
+ "type": "string"
+ },
+ "paths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "kind",
+ "paths",
+ "evidenceHash",
+ "decision"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "stateUpdated": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "findings",
+ "delta",
+ "stateUpdated"
+ ],
+ "type": "object"
+}Output schema / properties / topologyAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "canonicalPath": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "files": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "byteIdenticalTo": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "evidence": {
+ "type": "string"
+ },
+ "imports": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "existsInScan": {
+ "type": "boolean"
+ },
+ "path": {
+ "type": "string"
+ },
+ "specifier": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "specifier",
+ "path",
+ "existsInScan"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "isSymlink": {
+ "type": "boolean"
+ },
+ "path": {
+ "type": "string"
+ },
+ "role": {
+ "enum": [
+ "canonical",
+ "import_alias",
+ "symlink_alias",
+ "verbatim_mirror",
+ "contextual_layer",
+ "local_override"
+ ],
+ "type": "string"
+ },
+ "sha256": {
+ "type": "string"
+ },
+ "symlinkTarget": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "path",
+ "role",
+ "evidence",
+ "imports",
+ "isSymlink",
+ "symlinkTarget",
+ "byteIdenticalTo",
+ "sha256"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "schemaVersion": {
+ "const": 1,
+ "type": "number"
+ },
+ "sourceStrategy": {
+ "enum": [
+ "standalone",
+ "single_source",
+ "mixed",
+ "unresolved"
+ ],
+ "type": "string"
+ },
+ "warnings": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message",
+ "path"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "canonicalPath",
+ "sourceStrategy",
+ "files",
+ "warnings"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "repoPath",
- "files",
- "duplicates",
- "surfaceOverlaps",
- "riskSummaries",
- "overall"
-]New value: +[
+ "topology",
+ "review",
+ "repoPath",
+ "files",
+ "duplicates",
+ "surfaceOverlaps",
+ "riskSummaries",
+ "overall"
+]audit_release8 fields changedOutput schema / properties / changelog / properties / file / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / changelog / properties / file / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / matchedStarter / properties / id / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / matchedStarter / properties / id / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / version / properties / current / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / version / properties / current / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / version / properties / lastTag / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / version / properties / lastTag / typeAdded value: +[
+ "string",
+ "null"
+]create_project1 field changedInput schema / properties / template / enumPrevious value: -[
- "mcp-server",
- "mcp-server-python",
- "npm-package",
- "discord-bot",
- "telegram-bot",
- "browser-extension",
- "vscode-extension",
- "electron-app",
- "react-native",
- "cloudflare-pages",
- "docker-deploy"
-]New value: +[
+ "mcp-server",
+ "mcp-server-python",
+ "npm-package",
+ "browser-extension",
+ "vscode-extension",
+ "docker-deploy"
+]generate_launch_proof_report2 fields changedOutput schema / properties / outputPath / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / outputPath / typeAdded value: +[
+ "string",
+ "null"
+]seed_security_guidance2 fields changedOutput schema / properties / matchedStarter / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / matchedStarter / typeAdded value: +[
+ "string",
+ "null"
+]v0.4.0add_componentaudit_cdaudit_instructionsaudit_releaseaudit_securitycreate_projectgenerate_launch_proof_reportlist_templatesseed_security_guidanceScored across 9 tools
The four audits target clearly distinct concerns (security CI, release-readiness, CD publishing, instruction discovery), and create_project vs add_component differ by new-vs-existing repo. The only mild overlaps are generate_launch_proof_report aggregating the audits and seed_security_guidance vs audit_security (one generates, one audits), but descriptions make these boundaries clear.
All tools use consistent snake_case verb_noun naming (audit_security, list_templates, add_component, create_project, audit_release, audit_cd, audit_instructions, generate_launch_proof_report, seed_security_guidance). The pattern is predictable throughout, with 'audit_' prefixing the diagnostic family.
Nine tools is well-scoped for a scaffolding/audit server, with each tool earning its place across scaffolding, component installation, four distinct audit domains, an aggregate report, and guidance seeding.
The surface covers the full scaffold-audit-remediate loop (create_project, add_component, four audits, aggregate report, guidance seed, template listing). Minor gaps exist, such as no get_template details or project update/removal, but core lifecycle workflows are covered.
Build, deploy and manage MaShop e-commerce projects from Claude, Cursor or any MCP client.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
