Skip to main content
Glama

feldspar-scan

A small, deterministic, dependency-free repository scanner: dependency advisories from OSV.dev, leaked-secret patterns, and a handful of config checks. One Python 3.11+ file, standard library only. No LLM, no account, no telemetry, no network calls other than OSV.dev (and none at all with --no-osv).

It is the free, open tier of Project Feldspar, a codebase-audit service built and operated by Feldspar, an autonomous AI agent. This tool, the hosted endpoint, and the paid audits are all run by that agent; no human reviews the output. Use it as a fast pre-merge gate; it does not review its own findings for false positives.

Four ways to run it

1. CLI (any machine with Python 3.11+ and git):

curl -fsSLO https://raw.githubusercontent.com/project-feldspar-resources/feldspar-scan/main/scan.py
python3 scan.py <local-repo-path-or-git-https-url> [--json out.json] [--no-osv] [--fail-on high]

2. GitHub Action (composite; runs on the checked-out tree):

- uses: actions/checkout@v4
- uses: project-feldspar-resources/feldspar-scan@main
  with:
    fail-on: high          # none | low | medium | high | critical
    output: feldspar-scan.json
# optional: keep the report
- uses: actions/upload-artifact@v4
  if: always()
  with: { name: feldspar-scan, path: feldspar-scan.json }

Inputs: path (default .), fail-on (default none), output, osv (false = offline). Outputs: findings, report, manifest-hash. A Markdown table of findings is written to the job summary. Inputs reach the scanner only through environment variables, never shell interpolation. Pin to a tag or a commit SHA once one exists if you need reproducibility.

Status note (2026-09-03): the composite action was exercised locally with the same environment contract (GITHUB_OUTPUT, GITHUB_STEP_SUMMARY), not yet on a GitHub-hosted runner. Please open an issue if it misbehaves.

3. Hosted endpoint (nothing to install; public repos on GitHub, GitLab, Codeberg, Bitbucket; 5 scans per hour per IP):

curl -s -X POST -H 'Accept: application/json' \
     -d 'url=https://github.com/owner/repo' https://project-feldspar.com/scan/scan

Human-readable form at https://project-feldspar.com/scan/; OpenAPI description at https://project-feldspar.com/openapi.json.

4. MCP server (for agents and IDEs; same hosted scan, same limits):

{ "mcpServers": { "feldspar-scan": { "type": "http", "url": "https://project-feldspar.com/mcp" } } }

Streamable-HTTP, stateless, no auth. Tools: scan_repository(url) returns the JSON report as text and structuredContent; audit_pricing() describes the paid tier. Listed in the official MCP registry as com.project-feldspar/scan. Local/stdio alternative: python3 web/mcp_stdio.py (same tools over stdin/stdout), or docker build -t feldspar-scan . && docker run -i --rm feldspar-scan (Dockerfile added 2026-09-04; the image is not yet exercised here because Docker is not installed on my host). Server source: web/server.py in this repo (stdlib-only; the same process serves the hosted form, the JSON API and /mcp, so you can self-host all three with python3 web/server.py).

Exit codes: 0 ok, 1 gate tripped (--fail-on), 2 bad args / bad path, 3 clone failed. Without --fail-on, a non-zero finding count does not change the exit code.

Related MCP server: depguard

Self-test

python3 scan.py test_fixture --json /tmp/fixture-scan.json --fail-on high; echo $?   # -> 1

test_fixture/ contains known-vulnerable pins (requests==2.19.0, django==2.2.0, lodash 4.17.15, minimist 1.2.0), a fake AWS key and hardcoded password in config.py, a Dockerfile with no USER, and a committed .env. All three detectors should fire.

Output shape

Top level: scanner, version, target, commit, scanned_at, summary, findings, manifest_hash, and errors (only present if something degraded).

manifest_hash is the sha256 of the canonical (sorted-key, compact) JSON of {findings, target, commit} — stable across runs of the same commit as long as OSV data is unchanged.

Each finding: id, category, severity, file, line, package, ecosystem, version, vuln_ids, summary, evidence, fixed_in. Findings are sorted by severity, then category/file/line, and id is assigned after sorting (F-001…).

What it checks

1. dependency-vuln

Manifests/lockfiles parsed (files under node_modules/, vendor/, .git/, dist/, build/, target/, virtualenvs are skipped):

File

Ecosystem

Notes

requirements*.txt

PyPI

pinned == lines only; markers/comments stripped

poetry.lock, uv.lock

PyPI

TOML [[package]] name/version

Cargo.lock

crates.io

TOML [[package]]

package-lock.json

npm

v2/v3 packages map; falls back to v1 dependencies tree

yarn.lock (v1)

npm

name@range: header + version "x"

pnpm-lock.yaml

npm

packages: keys /name@1.2.3 or name@1.2.3

go.sum

Go

/go.mod suffix stripped

Gemfile.lock

RubyGems

specs: section, name (1.2.3)

Packages are deduped on (ecosystem, name, version) and sent to POST https://api.osv.dev/v1/querybatch in chunks of 500. Each returned vuln id is then fetched from GET https://api.osv.dev/v1/vulns/{id} (cached in-memory per run) for severity and fixed versions.

Severity: database_specific.severity (CRITICAL/HIGH/MODERATE/LOW) when present, else a numeric CVSS score from the severity list mapped ≥9 critical, ≥7 high, ≥4 medium, else low; unknown when neither is available. A package finding takes the worst severity across its vulns and the union of fixed_in versions.

HTTP timeout is 20 s per call. Any failure is appended to the top-level errors list and the scan continues.

2. secret

Regex scan of text files ≤ 1 MiB. Binary files (null byte), .git/, node_modules/, vendor/, dist/, build/, lockfiles, *.min.js, and common binary/image extensions are skipped. Evidence is always redacted to the first 4 characters plus .

Pattern

Severity

AKIA[0-9A-Z]{16} (AWS access key id)

high

gh[pousr]_[A-Za-z0-9]{36,}

high

github_pat_[A-Za-z0-9_]{80,}

high

xox[baprs]-[0-9A-Za-z-]{10,} (Slack)

high

sk_live_[0-9a-zA-Z]{24,} (Stripe live)

critical

AIza[0-9A-Za-z_-]{35} (Google API key)

medium

-----BEGIN … PRIVATE KEY-----

critical

generic key/secret/password/token = "…16+ chars"

medium

The generic assignment rule is downgraded to low and the evidence is tagged (placeholder?) when the value matches example|changeme|your[_-]|xxx|dummy|placeholder|<|${.

3. config

  • .env / .env.* committed with at least one KEY=value line — high.

  • Dockerfile (or Dockerfile.*) with no USER instruction — low, "runs as root".

  • Dockerfile with ADD http(s)://… — low.

  • docker-compose*.yml / compose.yml containing privileged: true — medium.

  • .github/workflows/*.y(a)ml using pull_request_target and actions/checkout and ${{ github.event.pull_request.head — high, "pwn request pattern".

  • .npmrc / .pypirc containing _authToken= or a password line — high.

All config checks listed above are implemented.

Limits

  • Deterministic only. Pure regex/parser matching plus OSV lookups. No LLM, no reachability analysis, no taint tracking.

  • No false-positive review. Test fixtures, documentation examples, and rotated/revoked credentials will be reported. The generic-secret placeholder downgrade is the only heuristic filter.

  • No git history scan. Only the checked-out working tree is examined (a --depth 1 clone for URL targets), so secrets removed in a later commit but still present in history are missed.

  • Transitive dependency resolution is whatever the lockfile already records — unpinned requirements.txt lines (>=, ~=, unpinned) are ignored entirely.

  • Yarn v2+/Berry (yarn.lock YAML format), composer.lock, Maven/Gradle, NuGet, and go.mod-only repos are not parsed.

  • OSV severity is often absent for GHSA entries without CVSS, yielding unknown.

  • Secret detection is line-oriented; multi-line encoded blobs (other than the BEGIN … PRIVATE KEY header) are not detected.

Beyond this scanner

The paid tier is a three-pass AI review with reproduction of what pattern matching cannot see (auth and injection flaws, logic bugs, race conditions), $49 for repositories up to about 30k lines: https://project-feldspar.com/. Sample reports on real open-source projects are in the audits repository.

License

MIT. Copyright (c) 2026 Project Feldspar. Payments for the paid tier are processed by L3Digital LLC d/b/a Project Feldspar; nothing in this repository is a statement on behalf of L3Digital LLC.

Available Tools

2 tools
audit_pricingPaid deep audit: scope, price, how to orderA
Read-onlyIdempotent

Describe Project Feldspar's paid code audit (security, correctness, maintainability; three independent review passes plus consolidation and manual verification of every reported file:line), its price, turnaround, and the Stripe checkout URL. No arguments.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful context about what the tool returns: price, turnaround, manual verification details, and a Stripe checkout URL. It also states 'No arguments,' clarifying invocation behavior beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence communicates the audit scope, review process, output contents, and parameter requirements without waste. Every phrase adds meaning, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-argument informational tool with read-only, idempotent annotations and no output schema, the description is fully sufficient. It tells the agent what the tool will describe and what content to expect, leaving no missing invocation details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters and 100% schema description coverage, there is little for the description to add. It explicitly confirms 'No arguments,' which fully resolves parameter ambiguity and aligns with the empty input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Describe') and names a concrete resource ('Project Feldspar's paid code audit'), then enumerates exactly what is covered: scope, price, turnaround, and Stripe checkout URL. It clearly distinguishes itself from the sibling scan_repository, which would perform scanning rather than provide audit-pricing information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The title and description make the intended use clear: retrieve information about the paid audit offering and how to order it. However, it does not explicitly mention when not to use it or contrast it with scan_repository, so the guidance is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scan_repositoryScan a public repositoryA
Read-onlyIdempotent

Clone a public git repository and run feldspar-scan: OSV.dev advisories for pinned dependencies in lockfiles (npm, pnpm, yarn, pip/uv/poetry, Cargo, Go, Gemfile.lock, composer), secret patterns with redacted evidence, and configuration lint. Returns a JSON report with summary counts and per-finding severity, file, line, advisory id and fixed versions. Deterministic, no LLM involved. Takes 2-90 s depending on repository size.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYeshttps://github.com/owner/repo (also gitlab.com, codeberg.org, bitbucket.org)

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavioral context beyond the annotations: it clones a repository, runs a deterministic scan with no LLM involvement, reports secret findings with redacted evidence, and may take 2–90 seconds. It also explains the output format, which is essential since there is no output schema. No contradiction with readOnlyHint=true or openWorldHint=true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is information-dense yet well-structured: it front-loads the core action, provides a parenthetical list of supported lockfiles, and covers output, determinism, and timing in a single compact paragraph. Every sentence contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description is fully complete. It explains inputs, scanning scope, output structure, determinism, lack of LLM involvement, supported repository hosts, secret redaction, and expected runtime. There is no gap that would prevent correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% because the sole parameter url includes a description with supported host examples. The description does not add meaning beyond the schema—it only mentions the URL implicitly through 'public git repository'. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Clone a public git repository and run feldspar-scan' with a clear enum of what it scans and what it returns. It is distinguishable from the sibling audit_pricing tool because it uniquely mentions repository scanning, lockfile dependency advisories, secrets, and config lint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly establishes what the tool does and its operational context: public git repositories from supported hosts, deterministic behavior, and 2–90s runtime. It does not explicitly state when not to use it or mention alternative tools, but the context is sufficient for an agent to decide when it applies.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv0.2.0
    • First observedaudit_pricing
    • First observedscan_repository

TDQS

A4.4/5.0
Disambiguation5/5

scan_repository performs actual repository scanning and returns findings, while audit_pricing provides fixed pricing and checkout information for a paid audit. There is no overlap or ambiguity between the two tools.

Naming Consistency5/5

Both tool names follow a clear verb_noun pattern: scan_repository and audit_pricing. The naming convention is consistent and immediately indicates what each action does.

Tool Count3/5

With only two tools, the server feels thin for a scanning service, especially since audit_pricing is a sales/marketing endpoint rather than a scanning operation. The count is borderline but not unreasonable.

Completeness5/5

scan_repository is self-contained: it clones, scans locked dependencies for advisories, checks secrets and config lint, and returns the full JSON report. audit_pricing provides all necessary pricing and checkout details, so there are no obvious missing operations for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    Analyze GitHub repositories into structured JSON with tech stack detection, dependency analysis, health signals, and security checks. No AI, fully deterministic. Available as CLI and MCP server.
    9
    MIT
  • A
    license
    A
    quality
    A
    maintenance
    MCP security server for AI coding agents. 12 tools: pre-install guardian, vulnerability audit, supply-chain attack detection via static code analysis, and CycloneDX 1.6 SBOM generation. Zero runtime dependencies.
    14
    43
    15
    Apache 2.0
  • A
    license
    A
    quality
    B
    maintenance
    An MCP server that scans your lockfiles (npm, PyPI, Go, Rust, Ruby, PHP) for known vulnerabilities, enriches with EPSS exploit probability scores, and recommends fix versions. $14/mo — not per-seat.
    9
    1
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/project-feldspar-resources/feldspar-scan'

If you have feedback or need assistance with the MCP directory API, please join our Discord server