Describe what this MCP server can do and how to use it. Call this when the user asks 'what can you do?', 'what does this server support?', or is otherwise unsure how to start.

Returns 'pong' — use to verify the MCP server is reachable.

Return the StepSecurity customer/tenant identifier configured on this MCP server, along with a link to the tenant's admin console. Call this when the user asks 'what's my tenant?', 'which customer am I scoped to?', or wants to confirm the default before a detection sweep. Reads the STEP_SECURITY_CUSTOMER env var set in the MCP client config.

List supply-chain threat-center incidents tracked by StepSecurity for a GitHub organization. ALWAYS call this first when the user mentions a known supply-chain incident or malicious package by name (e.g. 'axios compromise', 'trivy incident', 'Shai-Hulud') to find the matching incident and its ID before searching for exposure. Returns a compact summary (no markdown body) — then call get_threat_incident with the ID for full details.

Get full details of one threat-center incident — including the 'Am I Affected?' markdown section which lists the EXACT compromised package names + versions and C2 IOCs (domains/IPs) to check. Call this after list_threat_incidents to extract the concrete things to search for. The incident's ecosystem field ('npm' or 'pypi') dictates which exposure tools to call: for npm → check_npm_package_exposure + check_npm_package_on_dev_machines. For pypi → check_pypi_package_exposure + check_python_package_on_dev_machines. Always also call check_ioc_in_baseline for each C2 domain/IP mentioned, regardless of ecosystem.

Org-wide (CI-side) 'Am I Affected?' check for an npm package. Searches all monitored repos — workflow runs, PRs, and default branches — for uses of the package at the given versions. Pass an empty versions array to match any version. IMPORTANT: this only covers CI. For a complete 'am I affected' answer, also call check_npm_package_on_dev_machines in parallel to cover developer laptops.

Search the Harden-Runner org baseline for a domain or IP indicator of compromise. Uses the server-side search query (case-insensitive substring) so only matching endpoints come over the wire. Returns which repos/workflows/runs contacted the endpoint; each observation has a dashboard_url — when presenting results you MUST include a clickable link per observation, not just the first one. For a tenant-wide search across every org under your customer, use find_endpoint_calls_in_tenant instead.

Find which workflows across the organization use a given GitHub Action. Useful for responding to a compromised Action (e.g. 'which repos use aquasecurity/setup-trivy?'). Returns one entry per workflow that references the Action.

List Harden-Runner detections for an organization, filtered by detection type and status. Common detection IDs: 'Action-Uses-Imposter-Commit', 'Suspicious-Process-Events' (aggregates Runner-Worker-Memory-Read + Reverse-Shell + Privileged-Container), 'Anomalous-Outbound-Network-Call', 'Source-Code-Overwritten', 'Secret-In-Build-Log', 'Harden-Runner-Config-Changed', 'NPM-Package-Upgrade-To-Suspicious-Version', 'Agent-Tampered'.

Developer-machine 'Am I Affected?' check for an npm package. Searches across all enrolled developer laptops (Dev Machine Guard) for installs of the package. Complements check_npm_package_exposure — CI and dev machines are INDEPENDENT exposure surfaces, so when investigating a malicious-package incident you MUST check both. Uses the StepSecurity customer/tenant identifier (optional — falls back to STEP_SECURITY_CUSTOMER env var). The server's version filter is not applied — pass versions to filter results client-side to specific compromised versions, otherwise all installs are returned.

Org-wide (CI-side) 'Am I Affected?' check for a PyPI (Python) package. Searches all monitored repos — workflow runs, PRs, and default branches — for uses of the package at the given versions. Pass an empty versions array to match any version. IMPORTANT: this only covers CI. For a complete 'am I affected' answer, also call check_python_package_on_dev_machines in parallel to cover developer laptops. Use this (not check_npm_package_exposure) when the threat-center incident's ecosystem is 'pypi'.

Developer-machine 'Am I Affected?' check for a PyPI (Python) package. Searches across all enrolled developer laptops (Dev Machine Guard) for installs of the package. Complements check_pypi_package_exposure — CI and dev machines are INDEPENDENT exposure surfaces, so for a malicious-PyPI-package incident you MUST check both. The server's version filter is not applied — pass versions to filter results client-side to specific compromised versions, otherwise all installs are returned.

List anomalous outbound network-call detections across the tenant (all orgs installed under the customer). 'Anomalous' = a destination endpoint was contacted that is NOT in the repo's Harden-Runner baseline of allowed endpoints — a common indicator of supply-chain exfiltration. Typically the most-used detection type during an investigation. Every result has a dashboard_url — when you present detections to the user you MUST include a clickable link per detection, not just the first one.

List detections where Harden-Runner actively BLOCKED an outbound network call (egress-policy enforcement). Different from anomalous calls: blocked = the call was prevented; anomalous = the call happened but wasn't in baseline. Every result has a dashboard_url — when you present detections to the user you MUST include a clickable link per detection, not just the first one.

List HTTPS outbound network-call detections (TLS-intercepted calls with method + path). Useful when you need to see WHAT an outbound call did — e.g. POSTs to a suspicious endpoint during a build. Every result has a dashboard_url — when you present detections to the user you MUST include a clickable link per detection, not just the first one.

List suspicious-process-event detections across the tenant. This is a virtual detection ID that aggregates three real types: Runner-Worker-Memory-Read (credential theft from runner memory), Reverse-Shell, and Privileged-Container. Use for runtime-evidence of compromise during an incident. Every result has a dashboard_url — when you present detections to the user you MUST include a clickable link per detection, not just the first one.

List detections where a secret (API key, private key, token, etc.) was detected in a CI build log. The API returns the secret already masked (e.g. '----****') — safe to display. Includes rule_id (which detector fired), line_number and step_number for navigation to the leak. Every result has a dashboard_url — when you present detections to the user you MUST include a clickable link per detection, not just the first one.

List detections where a GitHub Action is pinned to a commit SHA that doesn't match any legitimate tag or branch head of that action's repo — a strong indicator of Action-tampering (e.g. a compromised tag pointing to malicious commit). Every result has a dashboard_url — when you present detections to the user you MUST include a clickable link per detection, not just the first one.

List every GitHub organization installed under a StepSecurity tenant. Call this first when a user asks for a tenant-wide view (e.g. 'find repos across my tenant using bun.sh') — then fan out find_repos_using_endpoint or similar per-org tools across the result. Each org has a dashboard_url pointing to its security summary — surface it as a clickable link per org. customer is optional; falls back to STEP_SECURITY_CUSTOMER.

List the 100 most recent Harden-Runner-monitored workflow runs for a GitHub organization, optionally narrowed to one repository. Use this to discover run IDs when the user asks about a run without giving an explicit ID — e.g. 'the latest run of trivy-scan in poc-1'. Every result has a dashboard_url — when you present runs to the user you MUST include a clickable link per run, not just the first one.

List every HTTPS call to github.com or api.github.com made by jobs in a specific workflow run. Useful for auditing which GitHub API endpoints a workflow touches — detecting writes to unexpected repos, surprising org access, or API calls from third-party Actions. Fast: one upstream API call. Requires a run_id — if the user doesn't supply one, call list_recent_workflow_runs first to find it. Returns calls grouped by job with step/tool attribution. The response has a top-level dashboard_url for the run AND a per-job dashboard_url deep-linking to the network-events tab scoped to that job. When presenting results, include the per-job link next to each job header.

Find every workflow-run observation of a given network endpoint across EVERY GitHub org installed under the tenant. Takes an endpoint substring (domain or IP), lists the tenant's orgs, and fans out a baseline search per org with bounded concurrency. Returns a flat list of observations: {org, repo, workflow, job, run_id, timestamp, dashboard_url}. Use this instead of check_ioc_in_baseline when the user asks 'did anyone in our tenant contact X?'. When presenting results you MUST include a clickable dashboard_url per observation.

Find every repo in an org whose Harden-Runner baseline contains a given network endpoint (domain or IP, substring match). Useful for questions like 'which repos contact bun.sh?', 'who still uses registry.npmjs.org?', or migration planning. Fans out one request per repo with bounded concurrency — expect 10–60 seconds on orgs with many repos. Returns only repos that matched — each one has a baseline_url which you MUST surface as a clickable link per repo (not just the first one). NOTE: this tool is single-org. For a tenant-wide sweep, first call list_tenant_github_orgs and then call this per org.

Group tenant-wide anomalous network-call detections by the calling process. Goal: spot VPN / mesh-networking daemons (tailscaled, twingate, zerotier-one, netbird, cloudflared, warp-svc, openvpn, wireguard) that are legitimately fanning out to many peer IPs and coordination endpoints as normal operation. For those, a single process-scoped rule suppresses both domain AND direct-IP benign anomalies with one rule. Returns per-process: count, distinct endpoints, distinct direct IPs, sample detections (with dashboard links), and a suggested single suppression rule. When a VPN process appears (is_vpn_process_candidate=true), propose a process-wide rule (just {process: , owner: '*', ...}). Do NOT auto-propose process-wide rules for other processes (dockerd, containerd, snapd, curl, etc.) — those can make security-relevant calls and deserve per-destination review.

List all suppression (detection) rules configured for the tenant. Use this before creating a new rule to check for duplicates or near-overlaps. Read-only.

Get one suppression rule by id. Read-only.

APPROXIMATE client-side preview of what creating a suppression rule would do. Fetches recent detections of the given detection_id and filters them against the proposed conditions, returning the count and up to 20 samples (with dashboard_url per sample). Use this BEFORE create_suppression_rule to show the user concrete impact. Preview uses exact + wildcard matching — the server's matcher is stricter (CIDR for ip_address, regex), so the final count after create may differ slightly.

Create a suppression rule. WRITE OPERATION — requires confirm: true and a read-only API key will 403. Before calling this, you MUST call preview_suppression_rule with the same conditions and show the user the expected impact. Creating a rule also retroactively suppresses matching past detections (synchronous server-side). After creation the tool verifies how many past detections were moved. Severity action is hardcoded to 'ignore' (only type the backend supports).

Update an existing suppression rule (name, description, or conditions). WRITE OPERATION — requires confirm: true.

Delete a suppression rule. WRITE OPERATION — requires confirm: true. NOTE: deleting a rule does NOT un-suppress detections it previously matched; they remain in the suppressed state with the deleted rule_id attached.