Tools
What the Sentrasec MCP server makes available to your agent.
These tools run against your authenticated workspace over stdio. No network port is opened, and the server acts as you, so an agent cannot reach findings you cannot.
| Tool | What it does |
|---|---|
security.scan | Run any scanner against a registered app: sast, sca, secrets, iac, kspm, apisec, container or dast. Defaults to all, which means every code scanner — DAST is excluded because it sends live traffic to a running system. Results are deduplicated, saved to your workspace and attributed to the key that ran them. |
security.list_findings | List a scan’s findings, optionally filtered to a minimum severity. Each carries file, line, classification and remediation. |
security.get_finding | One finding in full, including the agent fix prompt — a specific instruction with acceptance criteria for fixing that exact finding. |
security.get_scan | Re-read a scan by id: status, who triggered it, and its findings. |
security.list_scans | An app’s scan history, showing the kind, status and key label behind each run. |
security.scan_local | Scan a local directory in-process, without an app or credentials. Results stay in the session and feed straight into security.fix. Prefer security.scan once an app is registered — only that path deduplicates, enriches and files results to your workspace. |
security.list_findings_local | List findings from a security.scan_local run. The offline counterpart to security.list_findings — not enriched with a fix prompt or CWE/OWASP mapping. |
security.get_finding_local | One finding from a security.scan_local run, in full. The offline counterpart to security.get_finding, and the triage step before security.fix. |
security.fix | Apply a tier-1 autofix to a finding from security.scan_local, closing the scan-triage-fix-rescan loop without leaving MCP. Returns a diff; dry run by default, apply=true writes it. |
security.explain | Explain a vulnerability by its knowledge-graph node id: description, CWE, OWASP mapping and remediation. |
security.dast_scan | Probe a URL that is not yet registered as an app. Prefer security.scan with kind=dast when the app exists, so history accumulates against it. |
security.list_rules | List the detection rules available in the engine. |
security.list_languages | List the languages the scanners support, with tier and parser status. |
security.version | Return the running sentrasec-mcp server version. |
security.issue_cert | Issue a pentest certificate covering a set of scans. Ed25519 signing is not wired yet, so the certificate is unsigned today — treat it as a scan summary, not as an attestation a third party can verify. |
security.verify_cert | Verify a security certificate by id, returning its grade and validity. |
Scanners behind security.scan
security.scan takes a kind. Each one is a different engine, so naming the right one narrows a large repository to the answer you want:
| kind | What it runs |
|---|---|
sast | Taint-tracking static analysis — injection, unsafe sinks, hardcoded credentials. |
sca | Lockfile dependency inventory, including AI/LLM package classification. |
secrets | Provider-shaped credential detection. Matches are redacted in output. |
iac | Dockerfile, Kubernetes, Terraform, CloudFormation, Bicep, Helm misconfiguration. |
container | Image build posture from a registry ref or OCI tar, with a hygiene score. |
kspm | Kubernetes posture against CIS checks. |
apisec | OpenAPI contract analysis — BOLA and authorisation-shape candidates. |
dast | Live probing of a running URL across 13 vulnerability families. |
all is the default and means every code scanner. DAST is excluded from it deliberately, because it sends live traffic to a running system — ask for dast explicitly when that is what you want.
SCA reports inventory, not CVEs, today. Turning a dependency list into vulnerability findings needs graph enrichment, which is currently disabled, so a scan returns no SCA findings even against a known-vulnerable pinned version. Do not tell a user their dependencies are clean on the strength of that — say they were not checked.
How agents use them
Tools follow the standard MCP schema, so your client discovers them automatically once the server starts. You ask in plain language and the agent picks the right one:
Scan this project and tell me whether anything is exploitable in production.
There is no need to name a tool or learn its arguments. The agent selects and calls them, then explains the result in context.