Ask about highs, findings, and gates in chat: wiring AngusSecurity MCP

Once AngusSecurity MCP is connected, you can ask for scan conclusions right in IDE chat: any highs on this check, how to fix a finding, whether the gate will block, whether a report is ready—look up highs and alerts, explain findings, compare two checks, read or download report snapshots; with matching permissions and write on, you can also scan the current repo, image, or artifact. What comes back is a redacted conclusion, not a full raw scan dump into the model.

Main practical scenarios:

Takeaway: Security MCP exposes up to sixteen tools—most query findings, alerts, CVEs, licenses, gates, and reports; with permissions and write on, you can also scan or create a report for a finished check. No suppress of false positives, no secret plaintext, no publish/share. Use a portal-issued user access token for this product.

Console and host wiring: Connect AngusSecurity with MCP in the references. “Which repo holds this coordinate / client setup” is AngusRepo MCP—eight tools, write always off. Here the answer is scan conclusions, CVEs, licenses, gates, and report snapshots. Unified engines and how reports export: replace scanner scripts; how to export scan reports.

Explicitly out of scope: suppress false positives, reveal secret plaintext, change alert status, edit policies, publish/share/delete reports, manage credentials and engines, upload a whole unnamed tree, export engine raw output.

Chat only sees named tools; the server loops back in-process to the existing management API so permissions and audit stay one path.

IDE / Agent
  --POST {gateway}/security/mcp-->  Boot /mcp
  --loopback Bearer-->  /api/v1/** (named semantic tools)

A separate Node that re-wraps REST would duplicate policy. Loopback has no generic path parameter, so the model cannot invent the general upload gateway, reveal, or publish routes.

Rate limit: at most 30 successful calls per account per minute; then rate_limited—wait briefly.

With write on and full related permissions, an analyst or admin should see exactly 16 on tools/list. Viewers see fewer—§4.

Pagination starts at 1; at most 20 per page.

Explicitly not in the list: suppress, reveal, publish, share, delete reports, edit policies, upload a whole unnamed tree, export engine raw output.

A report is a snapshot at generation time and does not rewrite when the next scan finishes—same stance as “how to export scan reports” in the references.

If the account lacks permission, the tool does not appear; calling it by name yields permission_denied. MCP does not grant extra access. Try the same action in the console with the same account before blaming MCP.

Visibility matches what that user sees on /api/v1, same as the console. Personal tokens: avatar → Me (/profile). Use a service account for CI; do not commit a personal session into a repository.

Keep the token in an environment variable; do not commit it:

{
  "mcpServers": {
    "angus-security": {
      "url": "https://<gateway-host>/security/mcp",
      "headers": { "Authorization": "Bearer ${ANGUS_SECURITY_TOKEN}" }
    }
  }
}

Public shape is gateway {host}/security/mcp. A direct private process uses https://<security-host>/mcp (default port 1811; behind a reverse proxy you need not expose that port publicly). Copy the URL from System → MCP in the console.

Stdio-only hosts forward with @anguskit/mcp --product security (reads ANGUS_TOKEN / ANGUS_BASE_URL, not the same names as ANGUS_SECURITY_TOKEN):

{
  "mcpServers": {
    "angus-security": {
      "command": "npx",
      "args": ["-y", "@anguskit/mcp", "--product", "security"],
      "env": {
        "ANGUS_BASE_URL": "https://<gateway-host>",
        "ANGUS_TOKEN": "${ANGUS_SECURITY_TOKEN}"
      }
    }
  }
}

ANGUS_BASE_URL is the gateway origin without /security/mcp. Without a product prefix in private deploy, use --endpoint + https://<security-host>/mcp. If the default npm registry lacks the package, the docs suggest https://repo.anguskit.com/npm/npm-public/. Full host table: MCP docs in the references.

Example A: scan, then ask for issues

Example B: explain an existing finding

Example C: gate and report

After connect, also tools/list against the role table, then smoke-test security_explain_finding on a finding that already exists in the console.

Comparison explains product trade-offs, not a buying rank. Details follow each vendor’s docs of the day.

Three common failures after connect: the wrong product’s token won’t get in, an empty finding list rewritten as “safe,” and asking for report body while the scan or report is still running—see the table and FAQ below.

No. Explain and alerts keep masks; suppress, reveal, and approval stay in the console. One reason: some suppress scopes auto-approve—if the model frames “accept risk” as a fix, it would write an effective suppress.

Queries need Reports:VIEW. Downloads need Reports:EXECUTE and do not use the write switch. What the write switch removes is security_scan and security_create_report.

CLI and pipelines remain the main path for batch runs and gates; MCP brings the same jobs and findings into IDE chat. Unified engines: replace scanner scripts in the references.

Named tools keep the loopback whitelist small, avoid exposing the whole admin API to the model, and make projection redaction easier.

repod_ connect? MCP uses this portal’s user access token with the same rights as the console. Treating automation or cross-product tokens as chat identity widens the surface—401 before auth proceeds.

security_license_summary answer “this job”? It rolls up licenses visible to the account and cannot bind a jobId. For one job’s license issues, use security_issues.

No. Also distinguish: job unfinished, a capability with notScanned=true, and filters that missed. None of those mean the target is safe.

/security/mcp + PAT;