feldspar-scan
Allows scanning Bitbucket repositories for dependency vulnerabilities, leaked secrets, and configuration issues by providing a repository URL.
Allows scanning Codeberg repositories for dependency vulnerabilities, leaked secrets, and configuration issues by providing a repository URL.
Allows scanning GitHub repositories for dependency vulnerabilities, leaked secrets, and configuration issues by providing a repository URL.
Allows scanning GitLab repositories for dependency vulnerabilities, leaked secrets, and configuration issues by providing a repository URL.
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/scanHuman-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 $? # -> 1test_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 |
| PyPI | pinned |
| PyPI | TOML |
| crates.io | TOML |
| npm | v2/v3 |
| npm |
|
| npm |
|
| Go |
|
| RubyGems |
|
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 |
| high |
| high |
| high |
| high |
| critical |
| medium |
| critical |
generic | 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 oneKEY=valueline — high.Dockerfile(orDockerfile.*) with noUSERinstruction — low, "runs as root".DockerfilewithADD http(s)://…— low.docker-compose*.yml/compose.ymlcontainingprivileged: true— medium..github/workflows/*.y(a)mlusingpull_request_targetandactions/checkoutand${{ github.event.pull_request.head— high, "pwn request pattern"..npmrc/.pypirccontaining_authToken=or apasswordline — 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 1clone 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.txtlines (>=,~=, unpinned) are ignored entirely.Yarn v2+/Berry (
yarn.lockYAML format),composer.lock, Maven/Gradle, NuGet, andgo.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 KEYheader) 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 toolsaudit_pricingPaid deep audit: scope, price, how to orderARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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 repositoryARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | https://github.com/owner/repo (also gitlab.com, codeberg.org, bitbucket.org) |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
v0.2.0- First observed
audit_pricing - First observed
scan_repository
TDQS
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.
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.
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.
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
Related MCP Connectors
Scan any public GitHub MCP-server repo for security issues. 37 MCP-specific L1 rules, 8 languages.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Audit GitHub repos for malicious and supply-chain code before you depend on them.
Security, SEO and AI-visibility scanner for web apps · free scans and focused checks via MCP.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAnalyze 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.9MIT
- AlicenseAqualityAmaintenanceMCP 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.144315Apache 2.0
- AlicenseAqualityBmaintenanceAn 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.91MIT
- AlicenseAqualityDmaintenanceThe only MCP that returns license + supply-chain risk + popularity + price in a single call. 78,094 curated Git assets. Zero config. MIT. Free forever.14401MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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