@mindstone/mcp-server-vanta

Vanta compliance MCP server — read and write vulnerabilities, tests, controls, people, vendors, documents, and compliance summaries via the Vanta API.

One-click install

After clicking the button, your host will prompt you to fill: VANTA_CLIENT_ID, VANTA_CLIENT_SECRET, VANTA_REGION, VANTA_REQUEST_TIMEOUT_MS.

{
  "mcpServers": {
    "Vanta": {
      "command": "npx",
      "args": [
        "-y",
        "@mindstone/mcp-server-vanta"
      ],
      "env": {
        "VANTA_CLIENT_ID": "",
        "VANTA_CLIENT_SECRET": "",
        "VANTA_REGION": "us",
        "VANTA_REQUEST_TIMEOUT_MS": "60000"
      }
    }
  }
}

Status

• Version: 0.3.1 · npm
• Auth: OAuth client-credentials grant (VANTA_CLIENT_ID + VANTA_CLIENT_SECRET)
• Tools: 25 (19 read + 6 write across vulnerabilities, tests, controls, frameworks, policies, integrations, risk scenarios, event logs, people, vendors, documents, compliance summary)
• Surface: cloud-api
• Regions: VANTA_REGION is accepted for backward compatibility; all standard tenants (US, EU, AU) share one API host (api.vanta.com). The knob routes nothing in this package.

Installation

npx -y @mindstone/mcp-server-vanta

Configuration

Set these environment variables before starting the server:

• VANTA_CLIENT_ID — Vanta OAuth Client ID (required)
• VANTA_CLIENT_SECRET — Vanta OAuth Client Secret (required)
• VANTA_REGION — accepted for backward compatibility; all standard tenants (US, EU, AU) share one API host (api.vanta.com). The knob routes nothing in this package.
• VANTA_REQUEST_TIMEOUT_MS — request timeout in milliseconds (default 60000)

To generate credentials, open the Vanta Developer Console, create a new "Manage Vanta" app type, and copy the Client ID and Client Secret.

Requested OAuth scopes

The connector requests exactly this scope string at every token exchange:

vanta-api.all:read vanta-api.all:write vanta-api.documents:upload

vanta-api.documents:upload is a separate scope from vanta-api.all:write and is required by Vanta's document-upload endpoint. Vanta issues one active token per application and validates scopes against the application, so there is no way to request a narrower set per tool — the trade-off is accepted deliberately: every install carries the upload scope, including installs that never upload.

Upgrading from an earlier version: if your Manage Vanta app cannot request vanta-api.documents:upload, token exchange fails with invalid_scope and every tool stops working. Update (or recreate) the app in the Developer Console so it may request all three scopes.

Tools

Read

• vanta_list_vulnerabilities / vanta_get_vulnerability
• vanta_list_tests / vanta_get_test
• vanta_list_controls / vanta_get_control
• vanta_list_frameworks / vanta_get_framework
• vanta_list_policies / vanta_get_policy
• vanta_list_integrations
• vanta_list_risk_scenarios / vanta_get_risk_scenario
• vanta_list_event_logs
• vanta_list_people
• vanta_query_test_results
• vanta_get_compliance_summary
• vanta_list_vendors / vanta_get_vendor

Write

• vanta_create_vendor
• vanta_update_vendor
• vanta_attach_vendor_document
• vanta_deactivate_vulnerability_monitoring
• vanta_reactivate_vulnerability_monitoring
• vanta_upload_document

File uploads

Vanta's upload endpoints take the file as multipart/form-data, so both upload tools take a public https:// URL and the connector downloads the file itself before forwarding the bytes to Vanta:

• vanta_upload_document attaches evidence to an existing Vanta document (document_id), via POST /v1/documents/{documentId}/uploads.
• vanta_attach_vendor_document attaches a document to a vendor (vendor_id, plus a required document_type such as SOC2_REPORT), via POST /v1/vendors/{vendorId}/documents.

Vanta accepts .pdf, .docx, .jpg, .png, and .xlsx files.

Known limitations

• Uploads land as drafts. Vanta files an API upload against a document as a draft; the document must be submitted for review in Vanta before auditors can see the evidence. The tool result says so via submission_required, but the connector has no tool that submits.
• No document creation. vanta_upload_document attaches a file to a document that already exists in Vanta; it cannot create the document.
• Bounded ID fallback scan. When a direct GET by ID returns 404, the connector cursor-paginates the collection looking for the ID, up to 50 pages (5,000 records). Beyond that bound it reports not-found with a partial-scan note instead of silently giving up at the first page.

Safety

This server enforces:

• Every string in a Vanta API response is wrapped in an <untrusted-content> envelope — with close-tag breakout escaping — before it reaches the model, unless it is a grammar-checked structural literal (identifiers, enum-like statuses, ISO-8601 dates, http(s) URLs, pagination cursors) that must stay verbatim so it can be quoted back into follow-up tool calls. This deny-by-default walk means fields Vanta adds later, and attacker-influenced fields the connector does not know (e.g. scanner-authored package identifiers), fail closed — enveloped — rather than reaching the model raw. External message text in API and OAuth error bodies is enveloped the same way; credential-shaped values are redacted.
• HTTPS-only URL validation on both upload tools (rejects file:, localhost, RFC1918, link-local incl. cloud metadata addresses, IPv6 loopback/ULA, and hostnames whose DNS records resolve to any of those).
• Bounded document fetching: at most 3 redirects, each hop re-validated through the same URL guard, a 30-second timeout, and a 25 MB size cap enforced while streaming (a source cannot lie its way past the cap with a false Content-Length).
• Content-Type handling is header sanitization, not byte-level MIME sniffing: untrustworthy source labels are replaced with application/octet-stream.
• Distinct, structured failures for every refusal — blocked host, non-HTTPS, oversize, timeout, redirect limit — rather than a generic error.
• 50-requests-per-minute rate limiting with single-flight token exchange.
• Zod validation of external responses at the client boundary (paginated list envelopes and the OAuth token response); a malformed payload fails with a structured RESPONSE_INVALID/AUTH error instead of an unchecked cast.
• Response truncation at 25 KB with binary-search trimming; a truncated response drops pageInfo and directs a smaller-page_size retry, because the full-page cursor would silently skip the dropped records.
• Bearer-token redaction in all error messages.

License

FSL-1.1-MIT