Skip to main content
The MCP server exposes tools that map to ZeroPath’s REST V2 API. Tools are loaded from ZeroPath’s MCP manifest at startup, so your AI assistant always has access to current capabilities.

Issues

11 tools: list, get, and export issues, investigate, update status, severity, and notes, regenerate patches and choose a patch candidate, export a vulnerability report

Scans

3 tools — list scan history, get scan details, rescan PRs

Repositories

1 tool — list repositories with filtering

Code Inspection

3 tools — search, read, and list files in connected repositories

Rules

5 tools — full CRUD for custom security rules

Context

5 tools — full CRUD for scan context and its targeting

Tags

7 tools — full CRUD, membership previews, and custom-property discovery

Security Compass

11 tools: manage SD Elements project mappings and their task status mapping, sync rules, push the latest scan, read the coverage audit, and query linked issues

Organization Scoping

Most tools accept organizationId. Local MCP handles this automatically:
  • If ZEROPATH_ORG_ID is set, the server injects it into every request — you never need to pass it yourself.
  • If ZEROPATH_ORG_ID is not set, you must pass organizationId explicitly. Most tools require it at the API level; a few (like issues.list) can resolve org context from your auth session.
Set ZEROPATH_ORG_ID during installation to avoid passing organizationId in every call.
Hosted MCP uses the organization selected during OAuth authorization. Read tools require mcp:read; mutations require mcp:write. The caller’s existing organization and repository permissions apply to both transports. This reference uses API operation names such as tags.previewUpdate. MCP clients expose these with underscores, such as tags_previewUpdate.

Assistant Automation

Schedule tools use agent.listCronSchedules, agent.createCronSchedule, agent.updateCronSchedule, agent.deleteCronSchedule, and agent.triggerCronSchedule. Create requests take name, cronExpression, prompt, optional repositoryIds/tagIds, and trusted (defaults to false). Cron uses UTC. The trigger response returns jobId; pass it to agent.getJob to read status, summary, and visible messages. Service tokens require no human owner; personal tokens retain their owner’s permissions. Remote MCP acts as its authorizing user and organization. Repository- and tag-scoped schedule runs keep a saved repository selection for that run and use restricted execution even when the schedule requests Trusted mode. See the complete API workflow for inputs and execution limits.

Issue Tools

issues.list

List and filter security issues. Uses offset-based pagination via offset and limit.

issues.archive

Archive issues to remove them from active views.

issues.unarchive

Restore archived issues back to active views.

issues.markFalsePositive

Mark issues as false positives. Removes them from active review.

issues.markTruePositive

Confirm issues as true positives.

issues.updateStatus

Update the workflow status of one or more issues.
The field name is issueStatus, not status. Using the wrong field name will cause a validation error.

issues.updateSeverity

Update the raw 0-10 severity of a single issue. The rating displayed on an issue is the composite ZeroPath score (severity x confidence, 0-100), so this tool moves the rating only for a finding a scanner agent assessed. A finding with no recorded confidence is scored on its severity alone and stays in the Informational band whatever severity you set — use issues.updateSeverityRating to move one of those.
This tool takes a single issueId (string), not issueIds (array). The severity field is a number between 0 and 10, not a string enum.

issues.updateSeverityRating

Change the displayed severity rating of a single issue. Pass issueId and a rating of critical, high, medium, low, or info; optionally include reason. Use the organization configured for your MCP session, or pass organizationId explicitly. The response is { "ok": true }. This tool adjusts severity to reach the requested ZeroPath score band. A low confidence can prevent an increase into a higher band; downgrades always apply.

issues.requestInvestigation

Request an on-demand investigation of a finding using larger AI models for higher-confidence validation.
REST vs MCP: The public HTTP API exposes a single procedure, POST /api/v2/issues/requestInvestigation, with an issueIds array (one or more IDs). That route uses the same backend path as the issues.requestBulkInvestigation MCP tool. This issues.requestInvestigation MCP tool calls the single-issue tRPC mutation instead — there is no matching POST …/{id}/investigate REST endpoint.
If an investigation is already in progress for the issue, the response returns the existing investigation with "status": "already_pending" instead of creating a duplicate. Re-investigation can close findings: a definitive not-exploitable or fixed verdict closes the issue and its linked ticket. So it needs permission to close findings (Close Issues, ISSUE_EDIT_CLOSE) on the issue’s repository. Without it the request fails with FORBIDDEN (HTTP 403) and the message “Re-investigation can close findings, so it needs permission to close findings.” The check applies to the person the MCP session acts for. Organization admins are not refused, and neither are automations that run on their own (event triggers and scheduled runs). A run a person starts, such as activating a playbook or running a schedule manually, is checked against that person.

issues.requestBulkInvestigation

Request investigations for multiple issues at once.
REST mapping: POST /api/v2/issues/requestInvestigation with { issueIds, context?, organizationId? }. This is the HTTP surface for bulk investigations; it is not the same MCP tool name as issues.requestInvestigation (single-issue tRPC tool above).
Issues that already have a pending or in-progress investigation are skipped. Issues that do not belong to your organization are counted as unauthorized. Like issues.requestInvestigation, this needs permission to close findings (ISSUE_EDIT_CLOSE) on the repository of every requested issue you can see. If one of them is in a repository where you lack it, the whole request fails with FORBIDDEN (HTTP 403) and nothing is queued. Issues you cannot see are not part of this check: they are still counted as unauthorized.

issues.getInvestigationStatus

Get the latest investigation result for an issue.
Returns null if no investigation has been requested for the issue. The status field can be PENDING, PROCESSING, COMPLETED, or FAILED.

issues.regeneratePatch

Request a new patch to be generated for an issue. Use this when the existing auto-generated patch is outdated, does not apply cleanly, or you want a fresh attempt after the affected code has changed.

issues.updateNotes

Update the internal notes on an issue. Notes are free-text annotations visible to your team on the issue detail page and are useful for capturing triage context, investigation findings, or remediation plans.

issues.vulnerabilityReport

Render one issue as a standalone Markdown vulnerability report. Ask your assistant to save it, for example “write the vulnerability report for this issue to a file”. The same report is available as a Word document from More actions → Export report (.docx) on the issue in the dashboard. The report has these sections:
  • Title with the issue’s severity label, followed by the repository, affected location, CWEs, and a link back to the issue.
  • Status: review status (Unresolved, In review, Confirmed, Disputed) and remediation status (Unremediated, In progress, Remediated, or Not applicable for dismissed findings), each shown with the exact ZeroPath status, plus remediation notes such as the ZeroPath pull request and linked Jira or Linear tickets.
  • Description: the technical description of the finding.
  • Severity: an Impact explanation and a Likelihood explanation, each with its own rating derived from the finding’s CVSS assessment. Dependency findings also list CISA KEV, EPSS, and reachability facts.
  • Exploitation: the attack scenario with its lettered preconditions.
  • Proposed fix: the ZeroPath patch split per file, the version upgrade for dependency and container findings, or remediation instructions.
A section with no recorded data says so instead of being left out. For detected secrets, model-written text and the patch are always withheld, because they can quote the secret.

Scan Tools

scans.list

List scans with cursor-based pagination. Pass the nextCursor from a previous response to paginate forward.

scans.get

Get details for a specific scan.

scans.rescanPR

Trigger a rescan of a pull request or merge request. Pass the ID of a previous PR scan and the platform will re-fetch the pull request and create new scan(s). Supports GitHub PRs and GitLab MRs.
The outcome field indicates what happened:

Repository Tools

repositories.list

List repositories with cursor-based pagination (string cursor).

Code Inspection Tools

These tools allow you to browse and search source code directly in connected GitHub and GitLab repositories without cloning. Search for code within a repository.

code.read

Read the contents of a file in a repository.
Responses are capped at 1,000 lines and 200 KB. The truncatedByLineRange and truncatedByByteLimit flags indicate whether the response was truncated.

code.listFiles

List files and directories within a repository path.
Code inspection is currently supported for GitHub and GitLab repositories. Bitbucket, generic Git, and uploaded repositories are not yet supported.

Repository Context

These tools manage the same context definitions shown in the dashboard and are available through both local and remote MCP. They call the public POST /api/v2/contexts/{operation} endpoints. Creation defaults to all repositories. Use repositoryIds for direct scope or tagIds alone for tag scope. Updates preserve omitted fields and scope. A repository-filtered list includes inherited organization and matching tag context, with each entry returned once. Deletion is atomic across all requested IDs. Local MCP injects the configured organization ID. Remote MCP binds requests to the authorized organization and requires read consent for list/get and write consent for create/update/delete. The caller’s context permissions still apply. See Repository Context for targeting fields, scope transitions, defaults, and request examples. The same operations are available through zeropath contexts.

Rule Tools

rules.list

List custom security rules, newest first. Uses cursor-based pagination (string cursor): pass the nextCursor from a previous response to get the rules after the last one it returned. Rules created or deleted between page requests never make a later page repeat or skip a rule; start again without a cursor to see rules created since the first page.

rules.get

Get details for a specific rule, including associated repository names.

rules.create

Create a custom security rule.

rules.update

Update an existing rule. Only the fields you include will be modified.

rules.delete

Delete a custom rule.

Tag Tools

Both local and hosted MCP support the full tag lifecycle through POST /api/v2/tags/{operation}. These tools use the same membership and permission checks as the dashboard and zeropath tags. Creation accepts description, customPropertyFilters, includedRepositoryIds, excludedRepositoryIds, dynamicTagTrigger, and isDefault. Filters use stored GitHub key:value properties. The supported dynamic trigger is INTERNET_EXPOSURE. Defaults are empty arrays and isDefault: false. Updates accept name, description, customPropertyFilters, dynamicTagTrigger, isDefault, and incremental intentChanges. Omitted fields are preserved. Set description to null to clear it, or send empty arrays to clear filters or triggers.
include records manual inclusion and lifts an exclusion. exclude records manual exclusion, even if filters match. release removes manual intent and restores automatic membership. A repository may occur only once across these arrays; unmentioned repositories are untouched. Updates do not accept the creation-time replacement lists. Preview this payload with tags.previewUpdate, then use tags.update to save it. Previews roll back configuration, assignments, and membership audit entries. List, get, and property discovery require hosted MCP read scope. Create, update, delete, and preview require write scope: preview runs the update under the same exclusive locks as a save before rolling it back. Updating, previewing, or deleting a tag that grants team access also requires TEAM_MANAGE.

Security Compass Tools

These tools let you manage the Security Compass / SD Elements integration from your AI assistant. Credential operations (creating or deleting the integration, and the testConnection token parameter) are intentionally not exposed through MCP — supply your SD Elements API key through the ZeroPath dashboard, not through an AI assistant.

securityCompass.getIntegration

Fetch the Security Compass integration and all project mappings for an organization.

securityCompass.testConnection

Validate credentials against a specific SD Elements project. The apiToken parameter is not exposed through MCP — the tool uses the stored credentials when the requested URL matches the stored integration’s origin.

securityCompass.listTaskStatuses

List the task statuses that exist on the connected SD Elements instance, returned as statuses. Each entry has an id, a slug, a display name, and a meaning of DONE, TODO, or NA. Use the slugs when building a taskStatusMapping; only statuses whose meaning is DONE or TODO can be mapped. Fails with BAD_REQUEST when the instance cannot be reached.

securityCompass.addProjectMapping

Link an SD Elements project to a ZeroPath repository, start the initial rule sync, and, when the integration is enabled, push the repository’s latest finished full scan once that sync succeeds.

securityCompass.updateProjectMapping

Set a mapping’s task status mapping, or clear it so the mapping inherits the integration default. A missing key means “leave the task status unchanged” for that outcome and {} means verification note only. Every slug must exist on the instance with the meaning DONE or TODO; the call fails with BAD_REQUEST when a slug does not exist, means NA, or the instance cannot be reached to check it. The change applies to the next push; call pushLatestScan to apply it to the current scan.

securityCompass.removeProjectMapping

Unlink a project mapping (and clean up generated rules when no other mappings remain for the repository).

securityCompass.syncRules

Manually trigger a countermeasure-to-rule sync for a mapping.

securityCompass.pushLatestScan

Enqueue a results push of the repository’s latest finished full scan for a mapping, without running a new scan. Use it after changing a task status mapping, or for a mapping created long after the repository’s last scan. Returns { status: "enqueued", codeScanId }, or { status: "no_scan" } when the repository has no finished full scan yet. The call fails with CONFLICT (HTTP 409) while a push of that scan is already running, and with PRECONDITION_FAILED (HTTP 412) when the integration is disabled. A re-push of a scan that was pushed before runs again against the current mapping and the open findings as they are now.

securityCompass.getMappingAudit

Retrieve the per-countermeasure coverage breakdown for a mapping. Returns one entry per SD Elements countermeasure describing how ZeroPath covers it (built-in analysis, auto-generated natural-language rule, unsupported, or classification error), enriched with phase, priority, risk rating, and linked issue count.

securityCompass.getLinkedIssues

List open ZeroPath findings linked to a specific SD Elements countermeasure.

securityCompass.getSyncHistory

Retrieve recent Security Compass audit-log events for an organization, newest first: rule syncs, findings pushes, on-demand push requests, mapping additions, task status mapping changes and removals, integration changes, and connection tests.
Managing mappings, triggering syncs, and pushing results (addProjectMapping, updateProjectMapping, removeProjectMapping, syncRules, pushLatestScan) requires the admin role. Read operations (getIntegration, getMappingAudit, getLinkedIssues, getSyncHistory) are available to all organization members. listTaskStatuses also requires the admin role, because it calls SD Elements with the stored token on the caller’s behalf. See Security Compass / SD Elements for the full workflow and Task status mapping for what a mapping does in SD Elements.

Common Workflows

  1. List pending issues — call issues.list with statuses: ["PENDING_REVIEW"] sorted by score descending.
  2. Review each issue — ask your AI assistant to summarize the vulnerability and affected code.
  3. Classify — use issues.markTruePositive or issues.markFalsePositive with a reason.
  4. Update status — move confirmed issues to REVIEWING or PATCHING with issues.updateStatus.
  5. Adjust severity — if the auto-assigned rating doesn’t match your assessment, use issues.updateSeverityRating with a band label (critical, high, medium, low, info). Use issues.updateSeverity only when you specifically want to set the raw 0-10 number: it cannot move the displayed rating of a finding the scanner never assessed a confidence for, which is most of the PENDING_REVIEW queue.
  1. List existing rules — call rules.list to see what’s already configured.
  2. Create a rule — use rules.create with a natural language description. ZeroPath’s scanner will match this pattern during future scans.
  3. Scope it — use repositoryIds to limit the rule to specific repos, globPattern to limit to specific file types, and sourceTypes to target specific entry points.
  4. Tag it — use tagIds to associate the rule with tags for organization.
  5. Iterate — update with rules.update as you refine the pattern.
  1. List recent scans — call scans.list to see scan history. Filter with scanTypes: ["FullScan"] for scheduled scans or ["PrScan"] for PR scans.
  2. Get scan details — use scans.get with a specific scanId to see status, branch, and issue counts.
  3. Drill into findings — call issues.list with a scanId filter to see only issues from that scan.

Error Handling

Failed tool calls return structured errors:
Returned when input validation fails. Check the data.issues array for field-level details.
Verify your ZEROPATH_TOKEN_ID and ZEROPATH_TOKEN_SECRET are correct and the API key is active.
The API key does not have the required permissions for this operation. A personal key carries exactly its owner’s permissions, so check the owner’s role in Settings → Members and their team permissions in Settings → Teams. Keys themselves have no role: the API keys page shows each key’s name, expiry, and last use, and marks service keys with a Service key · organization-wide badge.
The specified ID (issue, scan, rule, or repository) was not found. Verify the ID is correct and belongs to your organization.

Tips

  • Paginate — always paginate large result sets. Use offset/limit for issues, cursor/limit for scans, repositories, and rules.
  • Filter early — use status, severity, and repository filters to reduce response size.
  • Batch updates — pass multiple IDs in a single call when archiving, marking, or updating status.
  • Include reasons — add a reason when archiving, marking false/true positives, or changing status for audit trails.
  • Set org context — configure ZEROPATH_ORG_ID during installation so the server injects organizationId into every request automatically.