Sentron
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_AUTH_TOKEN | No | GitHub authentication token used by Scorecard for higher rate limits and access to private repos (set in .env, never in mcp.json) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| audit_repo_healthA | Start an OpenSSF Scorecard audit (async — returns job_id immediately). Scorecard often takes 60–120s. This tool returns a Args:
repo_url: GitHub repository URL or |
| scan_licenses_and_vulnsA | Start a Trivy license + vulnerability scan (async — returns job_id). Trivy frequently exceeds 60s (clone + DB). Poll Args:
target: Repository URL or local path accepted by |
| generate_sbomA | Start Syft SBOM generation (async — returns job_id immediately). Poll Args: target: Image, directory, or other source accepted by Syft. |
| get_job_statusA | Poll a background Sentron scan job until it completes. Args:
job_id: ID returned by Returns:
JSON with |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.