Connect Snyk to ChatGPT: Scan Projects and Manage Security Issues

If you need to connect Snyk to ChatGPT to automate vulnerability triage, trigger SAST/SCA scans, or audit organization memberships, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between ChatGPT's JSON-RPC tool calls and Snyk's highly structured REST APIs.

If your team uses Claude, check out our guide on connecting Snyk to Claude or explore our broader architectural overview on connecting Snyk to AI Agents.

Giving a Large Language Model (LLM) read and write access to an enterprise application security platform like Snyk is a massive engineering challenge. You have to handle complex nested JSON:API payloads, manage strict hierarchical authentication scopes (Tenant vs. Group vs. Organization), and orchestrate asynchronous scan jobs. Every time Snyk updates its API versions or adds a new finding type, your custom server code must be updated, redeployed, and tested.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Snyk, connect it natively to ChatGPT, and execute complex security workflows using natural language.

The Engineering Reality of the Snyk API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, implementing it against Snyk's highly specific API architecture is exceptionally painful.

If you decide to build a custom MCP server for Snyk, you own the entire API lifecycle. Here are the specific integration challenges that break standard CRUD assumptions when working with Snyk:

The Strict Hierarchy: Tenants, Groups, and Orgs

Snyk enforces a rigid structural hierarchy that dictates API authorization. A Tenant contains Groups, which contain Organizations, which contain Projects and Targets. The API endpoints are strictly segregated by these scopes. If an LLM needs to list all projects, it must target the Organization scope (/orgs/{org_id}/projects). If it needs to manage global service accounts, it must target the Group scope (/groups/{group_id}/service-accounts).

When building custom MCP schemas, you must explicitly define these required route parameters and ensure the LLM understands when to pass an org_id versus a group_id. If the tool schemas are ambiguous, the LLM will hallucinate UUIDs or pass the wrong context ID, resulting in immediate 401 Unauthorized or 404 Not Found errors.

JSON:API Specification and Deep Nesting

Snyk's v1 and REST APIs heavily utilize the JSON:API specification. This means responses are not flat JSON objects. They are deeply nested structures containing data, type, id, attributes, and relationships.

When you ask Snyk to create a new resource - for example, a Group Membership - you cannot just send { "role": "admin", "user_id": "123" }. You must send a fully compliant JSON:API envelope:

{
  "data": {
    "type": "group_membership",
    "attributes": {
      "role": "admin"
    },
    "relationships": {
      "user": {
        "data": { "type": "user", "id": "123" }
      }
    }
  }
}

LLMs are notoriously bad at adhering to deeply nested, boilerplate-heavy JSON formats unless prompted heavily. If your MCP server does not abstract or strictly validate these schemas, tool calls will fail constantly.

Asynchronous State Machines (HTTP 202)

In Snyk, expensive operations do not block the HTTP thread. If you trigger an SBOM generation, a cloud scan, or a SAST test, you do not simply receive the results in the response. You receive an HTTP 202 Accepted or 302 Found with a job ID or location header.

The MCP server must expose tools that allow the LLM to traverse this state machine. The LLM must first call the "Create Test" tool, parse the job_id from the response, and then repeatedly call the "Get Job Status" tool until the status changes to completed, at which point it can call the "Get Test Findings" tool. Designing tool descriptions that force the LLM into this exact sequence requires meticulous prompt engineering embedded in the tool descriptions.

Handling Rate Limits Transparently

Snyk enforces strict rate limiting based on the customer's plan tier, and an aggressive AI agent can easily burn through these limits when paginating through thousands of vulnerabilities.

A critical architectural note: Truto does not automatically retry, throttle, or apply backoff on rate limit errors. When the upstream Snyk API returns an HTTP 429 Too Many Requests, Truto passes that exact error directly back to the caller (the LLM). Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller (your ChatGPT client or agent orchestration framework) is strictly responsible for interpreting these headers and executing retry and backoff logic. Do not assume the integration layer will magically absorb rate limit violations.

Hero Tools for Snyk Security Workflows

Truto automatically generates MCP tools from Snyk's underlying API documentation. This documentation-driven approach means every endpoint is accurately mapped to an LLM-friendly schema.

Below are the highest-leverage "hero tools" available for Snyk.

List All Organization Issues

Tool name: list_all_snyk_org_issues This is the core tool for vulnerability triage. It retrieves all security issues (vulnerabilities, license issues, configuration defects) associated with a specific Organization. The LLM can use this to identify unpatched, high-severity CVEs across the entire fleet.

"Get all the critical severity issues for our engineering organization. Filter out anything that is already patched or ignored, and summarize the top 5 vulnerabilities affecting our npm packages."

Create a Snyk Test (SCA/SAST)

Tool name: create_a_snyk_org_test Triggers an asynchronous scan for a specific target. This tool initiates the state machine. The LLM must capture the resulting job ID to poll for completion.

"Initiate a new SAST and SCA scan on the frontend-monorepo project. Give me the job ID so we can monitor the execution status."

List Test Findings

Tool name: list_all_snyk_test_findings Once a test job completes, this tool extracts the actual scanner-agnostic findings. It provides the LLM with the deep technical details of the discovered vulnerabilities and policy breaches.

"The test job 8f2c3b1a just completed. Retrieve all the test findings, filter for High and Critical risks, and list the exact file paths and line numbers where the SAST scanner found SQL injection vulnerabilities."

List Inventory Assets

Tool name: list_all_snyk_inventory_assets Retrieves a polymorphic collection of inventory assets in an organization. The LLM uses this to understand the attack surface - discovering cloud resources, container images, and IaC templates managed by Snyk.

"Search our Snyk inventory assets and list all the Docker container images currently being monitored. Show me the asset ID and the associated risk score for each."

Bulk Update Group Memberships

Tool name: snyk_group_memberships_bulk_update Used for Access Control and Identity Governance. This tool allows the LLM to modify a user's role across a Snyk Group, manipulating the complex JSON:API payload to update permissions.

"Update the group membership for user ID 445566. Change their role to 'Viewer' across the entire Group to adhere to our least-privilege quarterly access review."

List Open Source Licenses

Tool name: list_all_snyk_licenses Retrieves the software bill of materials (SBOM) license footprint. The LLM can use this to audit compliance against company policies (e.g., finding unauthorized AGPL or GPL dependencies).

"Scan our organization's license inventory and flag any projects that are currently using GPL-3.0 or AGPL-3.0 licenses. Let me know which dependencies are introducing them."

Note: This is just a selection of the highest-value operations. For the complete tool inventory and schema definitions, see the Snyk integration page.

Workflows in Action

Connecting Snyk to ChatGPT enables highly complex, multi-step security workflows. Because Truto's tools expose the raw capabilities of the Snyk API, ChatGPT can orchestrate remediation and auditing tasks autonomously.

Workflow 1: Asynchronous Scan Execution and Triage

When a developer pushes a major refactor, a DevSecOps engineer can ask ChatGPT to manually trigger a test and triage the results without leaving the chat interface.

"Trigger a new scan on our payment-gateway repository. Wait for it to finish, then tell me if any new critical CVEs were introduced."

Execution Steps:

1. Trigger the Scan: ChatGPT calls create_a_snyk_org_test passing the organization and target payload. It receives an HTTP 202 response containing a job_id.
2. Poll the Status: ChatGPT enters a polling loop, calling list_all_snyk_org_test_jobs using the job_id. It repeats this (with backoff) until the job status returns as completed.
3. Extract Findings: ChatGPT calls list_all_snyk_test_findings using the test ID retrieved from the completed job.
4. Analyze Results: The LLM parses the polymorphic vulnerability data, filters for new critical issues, and presents a summarized technical brief to the engineer.

sequenceDiagram
    participant User as "User (ChatGPT)"
    participant Truto as "Truto MCP Server"
    participant SnykAPI as "Snyk API"

    User->>Truto: call create_a_snyk_org_test
    Truto->>SnykAPI: POST /orgs/{id}/tests
    SnykAPI-->>Truto: 202 Accepted (job_id: 123)
    Truto-->>User: returns job_id: 123

    loop Async Polling (HTTP 202)
        User->>Truto: call list_all_snyk_org_test_jobs (job_id: 123)
        Truto->>SnykAPI: GET /orgs/{id}/test-jobs/123
        SnykAPI-->>Truto: status: "in_progress"
        Truto-->>User: returns in_progress
    end

    User->>Truto: call list_all_snyk_org_test_jobs (job_id: 123)
    Truto->>SnykAPI: GET /orgs/{id}/test-jobs/123
    SnykAPI-->>Truto: status: "completed" (test_id: 456)
    Truto-->>User: returns completed, test_id: 456

    User->>Truto: call list_all_snyk_test_findings (test_id: 456)
    Truto->>SnykAPI: GET /orgs/{id}/tests/456/findings
    SnykAPI-->>Truto: returns findings JSON
    Truto-->>User: returns findings to context```

### Workflow 2: Automated License Compliance Audit
Legal and compliance teams often need to verify that engineering has not introduced "copyleft" licenses that could jeopardize intellectual property.

> "Audit our Snyk organization for any restrictive open-source licenses. Specifically, find any AGPL or GPL licenses, identify the projects using them, and draft a Jira ticket description for engineering to remove them."

**Execution Steps:**
1.  **Retrieve License Data:** ChatGPT calls `list_all_snyk_licenses`, passing filters for specific license types (e.g., AGPL-3.0) in the query parameters.
2.  **Cross-Reference Projects:** The tool returns the violating dependencies alongside the `project_id`. ChatGPT calls `get_single_snyk_org_project_by_id` to get the human-readable project name and repository location.
3.  **Draft Remediation:** The LLM synthesizes the findings into a structured markdown document suitable for a Jira epic, detailing the specific packages that must be refactored.

## Generating and Connecting the MCP Server

Truto handles the heavy lifting of mapping Snyk's complex JSON:API structures into standard JSON-RPC 2.0 tools. You just need to generate the MCP server URL and plug it into ChatGPT.

### 1. Create the MCP Server in Truto

An MCP server in Truto is scoped to a specific authenticated Snyk tenant (an "Integrated Account"). You can generate the server URL via the UI or programmatically via the API.

**Method A: Via the Truto UI**
1. Log into Truto and navigate to the **Integrated Accounts** page for your Snyk connection.
2. Click the **MCP Servers** tab.
3. Click **Create MCP Server**.
4. Select your desired configuration (e.g., filter for read-only tools or specific tags like `["security", "audit"]`).
5. Copy the generated MCP Server URL (e.g., `https://api.truto.one/mcp/a1b2c3d4e5f6...`).

**Method B: Via the Truto API**
You can programmatically provision MCP servers for your end-users. Make an authenticated POST request to generate a server restricted to read operations:

```bash
curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Snyk Security Triage",
    "config": {
      "methods": ["read"]
    }
  }'

The API returns a secure, ready-to-use URL:

{
  "id": "abc-123",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

2. Connect the MCP Server to ChatGPT

Once you have the URL, you must tell ChatGPT where to find the tools.

Method A: Via the ChatGPT UI

1. Open ChatGPT and go to Settings → Apps → Advanced settings.
2. Toggle Developer mode on (required for MCP support).
3. Under "Custom connectors", click Add new server.
4. Provide a name (e.g., "Snyk Security (Truto)").
5. Paste the Truto MCP URL into the Server URL field and click Add.

ChatGPT will immediately connect to the server, negotiate capabilities via the /mcp/:token endpoint, and populate the tool definitions dynamically.

Method B: Via Manual Configuration File (for local/custom agents) If you are using Claude Desktop, Cursor, or a custom Python agent, you define the server using Server-Sent Events (SSE).

{
  "mcpServers": {
    "snyk-security": {
      "command": "npx",
      "args": [
        "@modelcontextprotocol/server-sse",
        "--url",
        "https://api.truto.one/mcp/a1b2c3d4e5f6..."
      ]
    }
  }
}

Security and Access Control

Giving an LLM access to your application security posture requires strict guardrails. Truto's MCP servers are fully self-contained and heavily configurable at creation time:

• Method Filtering: Enforce read-only access. By setting config: { methods: ["read"] } during creation, Truto ensures the LLM can only query issues and inventory. Destructive actions (like snyk_group_memberships_bulk_delete) are stripped from the tool list entirely.
• Tag Filtering: Group tools by functional area. You can restrict the server to only expose tools tagged with vulnerabilities or licenses, preventing the LLM from accessing identity or billing endpoints.
• Require API Token Auth: By default, the cryptographically secure token in the MCP URL is the only authentication required. For zero-trust environments, you can set require_api_token_auth: true. The ChatGPT client must then pass a valid Truto API token in the Authorization header to invoke any tools.
• Ephemeral Servers: Set an expires_at timestamp when creating the server. Truto will automatically clean up the token in Cloudflare KV via a scheduled alarm, revoking the LLM's access entirely after the audit window closes.

The Strategic Advantage of Managed MCP

Building an integration with Snyk to extract vulnerabilities is difficult. Translating that integration into a dynamically generated, LLM-compatible toolset that handles JSON:API idiosyncrasies, async job polling, and hierarchical scoping is a massive resource drain.

By using Truto to generate managed MCP servers, you offload the infrastructure complexity. Your engineering team doesn't have to write custom prompt wrappers to explain Snyk's nested schemas to ChatGPT. The tools are derived directly from the API documentation, resulting in high-fidelity function calling out of the box.

Stop building fragile custom servers. Generate a secure, production-ready MCP endpoint for Snyk, connect it to ChatGPT, and let your AI agents manage your security posture in real-time.