Quality suite commands

plugin-scanner has five maintainer and CI commands. Each one answers a different release question. A bare path such as plugin-scanner . runs scan.

Run plugin-scanner <command> --help for the flags in your installed version.

scan

Use scan for the weighted summary view:

plugin-scanner scan ./my-plugin --format json --profile public-marketplace
plugin-scanner scan . --format sarif --output plugin-scanner.sarif
plugin-scanner scan . --min-score 80 --fail-on-severity high

scan evaluates only the surfaces a plugin actually exposes, then normalizes the final score across applicable checks.

scan exits with status 1 when the score is below --min-score, a severity or --strict gate trips, or the selected policy profile fails.

lint

Use lint for rule-oriented authoring feedback:

plugin-scanner lint ./my-plugin --list-rules
plugin-scanner lint ./my-plugin --explain README_MISSING
plugin-scanner lint ./my-plugin --fix --profile strict-security

--list-rules prints one rule per line with its category, default severity, and whether it is fixable. --explain <rule id> prints the rule definition as JSON. --fix applies safe mechanical fixes to the files before linting and prints each change. lint accepts --format text or --format json, the same policy flags as scan (--profile, --config, --baseline, --strict), and exits with status 1 when the policy profile fails.

verify

Use verify for manifest, marketplace, MCP, skill, app, and asset readiness checks:

plugin-scanner verify ./my-plugin --format json
plugin-scanner verify . --format json
plugin-scanner verify ./my-plugin --online --format text

verify accepts --format text (default) or --format json and exits with status 1 unless every case passes.

MCP checks work like this:

• Remote MCP URLs must use HTTPS, must not embed credentials, and must not point at local or non-public addresses.
• Without --online, remote endpoints are recorded as an offline-skip and no network request is made.
• With --online, the scanner resolves the hostname, requires public addresses, and probes the endpoint over a pinned HTTPS connection with a short timeout. A 2xx response is reachable. 401 and 403 are recorded as auth required. Redirects are refused.
• Stdio MCP server commands are never executed. Each declared stdio server is recorded as a safety-skip case that counts as not passed, so it needs manual review before you trust it.

submit

Use submit for one artifact-backed gate before release or ecosystem intake:

plugin-scanner submit ./my-plugin --profile public-marketplace --attest dist/plugin-quality.json

submit runs scan, policy, and verify. It writes the quality artifact to the --attest path only when the score meets the minimum, the policy profile passes, and verify passes. The minimum is the profile's own minimum score unless you pass --min-score. It also accepts --config, --baseline, and --online, and it has no --format flag.

submit stays single-plugin on purpose so the artifact points at one concrete package. A marketplace root exits with an error. See Submission and registry payloads for the artifact shape.

doctor

Use doctor for targeted diagnostics or a troubleshooting bundle:

plugin-scanner doctor ./my-plugin --component mcp --bundle dist/doctor.zip

--component is one of all (default), manifest, marketplace, mcp, skills, apps, or assets. doctor always runs offline. Without --bundle it prints the report as JSON. With --bundle it writes a zip file that contains:

• doctor-report.json
• environment.txt, with the working directory, Python version, and OS name
• workspace-manifest.txt
• command-metadata.json
• stdout.log, stderr.log, and timeout-markers.txt

Read environment.txt and the logs before you attach a bundle to a public issue.

When to use which command

Next guides

• Ecosystems and repository mode
• Policies, output, and trust provenance
• Submission and registry payloads