Audits GitHub repositories for health and security posture using OpenSSF Scorecard, including overall scores and weak checks. Supports authentication with a GitHub token for higher rate limits and private repositories, and clones repository URLs for local scanning.
Scans dependencies for license hits and HIGH/CRITICAL vulnerabilities via Trivy, returning findings alongside SBOM-based package inventories from Syft.
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., "@Sentron audit github.com/expressjs/express for vulnerabilities and license issues"
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.
Ask a security expert before you adopt open source.
Your AI assistant should have to ask too.
Sentron is an MCP security gateway. It sits between Claude, Cursor, and the messy reality of GitHub: Scorecard for repo health, Trivy for licenses and vulns, Syft for SBOMs. When an assistant is about to trust a dependency, Sentron makes it run the checks a careful human would.
Status: v0.1.0 — usable locally, opinionated, still early. See docs/roadmap.md.
AI coding tools install packages, clone repos, and recommend binaries at machine speed. Humans used to pause and ask:
Is this project maintained, or abandoned with a shiny README?
Are there known HIGH/CRITICAL CVEs in what I'm about to pull?
What's actually in the box (SBOM), and under which licenses?
That pause is disappearing. Sentron puts it back — as tools your assistant can call before it says "looks fine."
It does not replace judgment. It replaces the blank stare when nobody ran Scorecard.
Related MCP server: Orcorus Repository Scanner
Tool | Under the hood | Answers |
| Overall score, weak checks, process smell | |
| License hits + HIGH/CRITICAL vulns | |
| Package inventory / ecosystem counts | |
| Sentron job runner | Poll long scans (Claude Desktop ~60s cap) |
Long scans start in the background and return a job_id. Poll until completed. That keeps Claude Desktop from timing out mid-Scorecard.
$PATH)brew install scorecard trivy syft # or your package manager of choicegit clone https://github.com/grootynix/sentron.git
cd sentron
uv sync.env (never in mcp.json)cp .env.example .env
# GITHUB_AUTH_TOKEN=... # Scorecard rate limits / private reposClaude Desktop — ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"sentron": {
"command": "/Users/YOU/.local/bin/uv",
"args": ["run", "--directory", "/ABS/PATH/TO/sentron", "sentron"]
}
}
}Cursor — see .cursor/mcp.json. Same idea: launch via uv, no tokens in the JSON.
Quit and reopen the client. Ask it to audit a repo and poll get_job_status.
uv run python - <<'PY'
import asyncio, json
from sentron.tools.syft import run_syft
async def main():
print(json.loads(await run_syft("."))["summary"]["total_packages"])
asyncio.run(main())
PYClaude / Cursor
│ stdio MCP
▼
sentron.server (FastMCP)
│ start job → job_id
▼
sentron.jobs ──poll──► get_job_status
│
├── tools/scorecard.py → scorecard CLI
├── tools/trivy.py → trivy CLI
└── tools/syft.py → git clone (if URL) + syft CLICLI binaries are executed with asyncio.create_subprocess_exec, timeouts, and PATH preflight. Missing tools return a JSON error with install hints — not a stack trace.
Full write-up: docs/architecture.md.
Doc | Contents |
Install, tokens, client config | |
Arguments, response shapes, polling | |
Env vars, | |
Modules, data flow, design choices | |
v0.1 → v1.0 and beyond | |
How to report issues | |
Dev setup, PRs |
Current release: 0.1.0 (see CHANGELOG.md)
Python: 3.11+
License: Apache-2.0
Stability: APIs may shift before 1.0. Pin a tag if you automate on this.
v0.1 — Scorecard + Trivy + Syft over MCP, async jobs, local secrets — shipped
v0.2 — Policy profiles ("block CRITICAL", license allowlists), better summaries for agents
v0.3 — CI / GitHub Action mode; SARIF / CycloneDX export
v1.0 — Stable tool schema, signed releases, documented threat model
Details: docs/roadmap.md.
Not a magic "safe / unsafe" oracle
Not a hosted SaaS (v0.1 runs on your machine)
Not a replacement for Scorecard, Trivy, or Syft — it orchestrates them
If a check fails because your fine-grained PAT can't read branch protection, Sentron skips that check and says so. Bring a classic repo-scoped PAT if you need the full set.
Bugs, sharp edges, and small PRs welcome. Read CONTRIBUTING.md and the Code of Conduct.
Copyright 2026 Sentron contributors.
Licensed under the Apache License, Version 2.0.
Third-party CLIs (Scorecard, Trivy, Syft) keep their own licenses; you install them separately. See NOTICE.
Built on the shoulders of OpenSSF Scorecard, Aquasecurity Trivy, Anchore Syft, and the Model Context Protocol.
Start an OpenSSF Scorecard audit (async — returns job_id immediately).
Scorecard often takes 60–120s. This tool returns a job_id right away.
Poll get_job_status until status is completed, then read result.
Args:
repo_url: GitHub repository URL or owner/repo shorthand.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | 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 well: it discloses the async contract, that a job_id is returned immediately, and the 60–120s expected runtime. It omits auth requirements and error/failure behavior, which keeps it below a 5.
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 with the action and async caveat, and the polling instructions are actionable. There is mild redundancy in restating the job_id return twice, but nothing wasteful enough to hurt.
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 async lifecycle, timing expectation, next-step tool, and result location are all covered, and an output schema exists so return-format detail is unnecessary. Missing only failure-path and permission context for a job-launching tool.
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 0%, so the description must compensate, and it does: it explains repo_url accepts either a full GitHub URL or owner/repo shorthand, which the bare string schema does not convey. It's only one parameter, so the added meaning is sufficient.
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 ('Start an OpenSSF Scorecard audit') plus the scope of what it evaluates, which distinguishes it from scan_licenses_and_vulns and generate_sbom without needing to name them. An agent can tell what this does from the first clause alone.
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 directs the agent to poll get_job_status until status is completed and then read result, which is concrete when-and-how guidance. It does not state when to prefer this over the sibling scanning tools, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start Syft SBOM generation (async — returns job_id immediately).
Poll get_job_status until completed.
Args: target: Image, directory, or other source accepted by Syft.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. To its credit, it discloses the critical async contract: the tool returns a job_id immediately and requires polling. It says nothing about runtime expectations, failure modes for invalid targets, resource requirements, or whether jobs can be cancelled.
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 async behavior is stated up front and followed by the polling instruction, with no filler. The leftover 'Args:' docstring formatting is slightly noisy but still readable.
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 tool is simple, with one parameter, and an output schema exists, so return values need not be explained. The description covers the essential workflow gap: the need to poll get_job_status. Only the error-handling and target-format details are thin.
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 0%, so the description must compensate for the single undocumented parameter. It partially does so by giving examples (image, directory), but 'other source accepted by Syft' is circular and offers no concrete format guidance such as 'docker:alpine' or 'dir:/path'.
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 names a specific verb and resource: start Syft SBOM generation. It also states the async nature. It distinguishes this from get_job_status by describing the follow-up relationship, but it does not distinguish this tool from the sibling scan_licenses_and_vulns.
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 gives a clear post-invocation workflow: it returns a job_id immediately, and you then poll get_job_status until completion. However, it does not explain when to choose this tool over scan_licenses_and_vulns, nor does it list prerequisites such as whether the target must be accessible locally.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a background Sentron scan job until it completes.
Args:
job_id: ID returned by audit_repo_health, scan_licenses_and_vulns,
or generate_sbom.
Returns:
JSON with status (started|running|completed|failed).
When completed, includes the original tool result payload.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description must carry the behavioral burden. It does disclose the asynchronous job model, the terminal state set, and that the result payload is attached on completion, but it omits retry/backoff expectations, behavior for unknown job_ids, and whether the call blocks or returns immediately.
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 one-line purpose followed by compact Args/Returns sections. Every line adds information an agent needs; there is no filler.
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 polling tool with an output schema present, this is close to complete: origin of the ID, status vocabulary, and result availability are all covered. Only error-path behavior for a stale or invalid job_id is missing.
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 0%, so the schema gives no hint about what job_id means. The description compensates well by naming the three sibling tools whose return values supply it, which is the key semantic an agent needs.
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 (poll), a specific resource (a background Sentron scan job), and the terminal condition (until it completes). It is trivially distinguishable from the three siblings, which launch jobs rather than report on them.
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 makes the usage path explicit: this tool is called with a job_id returned by audit_repo_health, scan_licenses_and_vulns, or generate_sbom, and is polled until completion. It stops short of saying whether to back off between polls or what to do on an invalid/expired job_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a Trivy license + vulnerability scan (async — returns job_id).
Trivy frequently exceeds 60s (clone + DB). Poll get_job_status for results.
Args:
target: Repository URL or local path accepted by trivy repository.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full load and does well: it discloses the async execution model, the returned job_id, and the realistic latency (clone + DB download exceeding 60s). It omits prerequisites such as Trivy availability, repository auth/credentials, and any failure modes, which leaves a gap for a mutation-adjacent heavy operation.
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 efficient: the async/job_id fact comes first, polling guidance second, parameter semantics last in a short Args block. The Args heading is slightly unusual for a single parameter but does not waste space.
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-value detail is not required. For a one-parameter async job launcher the description covers what to pass, what comes back, and how to retrieve results; only permission/auth prerequisites and error behavior are unaddressed.
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 0% — the single 'target' property has no description — so the description must compensate. It does, characterizing target as a repository URL or local path matching what `trivy repository` accepts, which is exactly the disambiguation an agent needs to construct a valid value.
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 gives a specific verb and resource — 'Start a Trivy license + vulnerability scan' — and names the exact result artifact (job_id). It does not, however, distinguish this from the sibling generate_sbom, which is presumably also a Trivy-based scan, so an agent must infer which scanning tool is appropriate by name alone.
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?
Clear operational routing: this is async, so the agent knows to call get_job_status afterward rather than expecting inline results, and the >60s warning tells it not to block. What is missing is any guidance on when to pick this over generate_sbom or audit_repo_health.
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.1.0audit_repo_healthgenerate_sbomget_job_statusscan_licenses_and_vulnsScored across 4 tools
Each tool maps to a distinct engine and artifact: OpenSSF Scorecard repo health, Trivy license/CVE scanning, Syft SBOM generation, and generic job polling. The descriptions clearly state which CLI/backend each wraps and how the async pattern ties them together, so an agent can select correctly.
All four names follow a consistent snake_case verb_noun pattern (audit_repo_health, scan_licenses_and_vulns, generate_sbom, get_job_status). Verbs vary appropriately with the action while the structure remains predictable.
Four tools is well-scoped: three distinct scan starters plus one shared poller, with no redundancy. Every tool earns its place in the async workflow.
The core async lifecycle (start job + poll for result/status) is fully covered, including failure status. Minor gaps exist: no job cancellation, no list-jobs or job-history tool, and no way to re-fetch a result once a job is no longer polled.
Evaluates any GitHub repository for license risk, maintenance velocity, stars/forks, and supply-c.
Evaluates any GitHub repository for license risk, maintenance velocity, stars/forks, and security.
Trust-check any dependency for agents: OpenSSF Scorecard, licenses, CVEs, deps. 7 ecosystems.
Security scanner for AI-written code: SAST, secrets, dependencies, IaC, containers and DAST.
