Connect Sprinto to Claude: Automate Staff Scoping and Verifications

If you need to connect Sprinto to Claude to automate compliance checks, staff scoping, or evidence collection, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's tool calls and Sprinto's REST APIs. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on connecting Sprinto to ChatGPT or explore our broader architectural overview on connecting Sprinto to AI Agents.

Giving a Large Language Model (LLM) read and write access to a Governance, Risk, and Compliance (GRC) platform like Sprinto is a highly sensitive engineering operation. You are dealing with auditable systems of record. Every API call leaves a trace, and every state change impacts your SOC 2 or ISO 27001 posture. You have to handle OAuth token lifecycles, map strict GRC data schemas to MCP tool definitions, and deal with vendor-specific rate limits. Every time an endpoint updates, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Sprinto, connect it natively to Claude Desktop or enterprise Claude workspaces, and execute complex compliance workflows using natural language.

The Engineering Reality of the Sprinto API

A custom MCP server is a self-hosted integration layer that exposes REST APIs as JSON-RPC 2.0 tools. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against a GRC platform like Sprinto introduces unique challenges.

If you decide to build a custom MCP server for Sprinto, you own the entire API lifecycle. Here are the specific challenges you will face with the Sprinto API:

Immutable Audit Trails and State Constraints Sprinto is designed for auditors. State changes are heavily constrained. You cannot simply "delete" an evidence record if it was uploaded incorrectly; compliance APIs require specific transitions, such as deprecating old evidence or appending new background verification files with exact chronological markers. When passing tools to Claude, you must explicitly instruct the LLM on which primary keys (pk) to use and enforce strict ISO 8601 formatting for fields like evidenceRecordDate or verificationCompletedOn. Without a managed layer translating these constraints into clear JSON Schema descriptions, the LLM will repeatedly fail validation checks.

Cursor-Based Pagination for Compliance Edges Sprinto relies heavily on cursor-based pagination for listing entities like workflow checks. The API returns a paginated collection of edges, each containing a node (the actual data) and a cursor string used for page navigation. If you expose raw pagination structures to Claude without explicit instructions, the model will frequently hallucinate cursor values or fail to traverse the data set. Truto automatically normalizes this into a standard limit and next_cursor schema, actively instructing the LLM via injected schema descriptions to pass cursor values back unchanged.

Strict Rate Limits and Error Passthrough Sprinto enforces strict rate limits to protect its multi-tenant infrastructure. If your AI agent gets stuck in a loop scraping thousands of workflow checks, the upstream API will return an HTTP 429 Too Many Requests error. Truto does not retry, throttle, or apply backoff on rate limit errors. When an upstream API returns HTTP 429, Truto passes that error directly to the caller. Truto normalizes upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The caller - whether it is Claude Desktop, LangGraph, or a custom agent framework - is entirely responsible for implementing retry logic and backoff. Do not rely on the integration layer to absorb these errors; your agent logic must handle the isError: true response gracefully.

How to Generate a Sprinto MCP Server with Truto

Truto dynamically generates MCP tools based on the actual resources and documentation defined on the Sprinto integration. Instead of writing custom JSON-RPC handlers for every compliance endpoint, you can generate a complete MCP server in seconds.

There are two ways to generate a Sprinto MCP server: through the Truto UI or programmatically via the API.

Method 1: Via the Truto UI

If you are an IT administrator or DevOps engineer setting up a local Claude Desktop instance, the UI is the fastest path.

1. Navigate to the Integrated Accounts page in your Truto dashboard and select your connected Sprinto account.
2. Click the MCP Servers tab.
3. Click the Create MCP Server button.
4. Select your desired configuration (e.g., restrict methods to only read operations, or filter by specific tags like compliance).
5. Copy the generated MCP server URL. It will look like https://api.truto.one/mcp/a1b2c3d4e5f6...

Method 2: Via the API

For platform engineers building multi-tenant AI agents, you can generate MCP servers programmatically. This endpoint validates that the integration has tools available, generates a secure cryptographically hashed token, and returns a ready-to-use URL.

Request:

curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Sprinto Compliance Auditor",
    "config": {
      "methods": ["read", "write"],
      "tags": ["staff", "evidence"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

Response:

{
  "id": "mcp-789-xyz",
  "name": "Sprinto Compliance Auditor",
  "config": {
    "methods": ["read", "write"],
    "tags": ["staff", "evidence"]
  },
  "expires_at": "2026-12-31T23:59:59.000Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

This URL contains a cryptographic token that securely maps to the specific Sprinto tenant account. It is fully self-contained - no additional client-side OAuth handling is required.

How to Connect the Sprinto MCP Server to Claude

Once you have your MCP server URL, you must register it with your AI client so the model can discover the available Sprinto tools via the tools/list protocol method.

Method A: Via the Claude UI (Enterprise / Web)

If you are using Claude for Work (Team or Enterprise plans), you can add custom connectors directly in the interface.

1. In Claude, navigate to Settings -> Integrations (or Connectors depending on your plan tier).
2. Click Add MCP Server or Add custom connector.
3. Paste the Truto MCP server URL you generated earlier.
4. Click Add or Save.

Claude will immediately execute an MCP handshake (initialize), request the tool schemas, and make the Sprinto functions available to your workspace.

Method B: Via Manual Config File (Claude Desktop)

If you are a developer using Claude Desktop on macOS or Windows, you must update the local JSON configuration file. Truto provides an SSE (Server-Sent Events) transport utility to connect remote HTTP MCP servers to local clients that expect stdio executables.

Open your Claude Desktop configuration file (typically located at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows) and add the following:

{
  "mcpServers": {
    "sprinto-compliance": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/a1b2c3d4e5f67890"
      ]
    }
  }
}

Save the file and restart Claude Desktop. The hammer icon in the bottom right of the input bar will now list your Sprinto tools.

High-Leverage Sprinto Tools for AI Agents

Truto automatically generates a comprehensive suite of tools from the Sprinto integration schema. Instead of dumping the entire inventory, here are the most critical operations for automating staff scoping and evidence workflows.

List Workflow Checks

This tool retrieves the paginated list of workflow checks configured in the Sprinto instance. It is the necessary first step for identifying which specific checks require evidence to be uploaded. The tool handles the cursor-based pagination edges automatically.

"Fetch the first 20 workflow checks in our Sprinto environment and tell me which ones are missing evidence. If there is a next_cursor, let me know so we can page through the rest."

Contextual Usage: The LLM uses this tool to map human-readable check titles (like "Quarterly Access Review") to the strict internal pk (primary key) required by the Sprinto API for write operations.

Create Background Verification Report

This tool uploads a background verification record for a specific staff member. It securely binds the verification metadata to the employee's internal profile.

"Upload the background verification report for alice.smith@acmecorp.com. The verification was completed today. The file payload is attached in my previous message."

Contextual Usage: Required fields include the user's email, the exact verificationCompletedOn timestamp, and the verificationReportFile data. The LLM must be provided with the file data in a stringified format prior to calling this tool.

Upload Workflow Check Evidence

This tool posts compliance evidence directly to a specific workflow check. It actively updates the evidenceStatus of the check in the Sprinto dashboard.

"Take the SOC 2 penetration test report from our conversation history and upload it as evidence for the workflow check with PK 'check-49291'. Set the evidence record date to yesterday."

Contextual Usage: You must pass the exact workflowCheckPk, the evidenceRecordDate, and the binary or base64-encoded evidenceFile. The response returns the updated workflowCheck object, allowing the LLM to verify that the evidenceStatus changed from pending to submitted.

Mark Staff Member In-Scope

This tool adds a staff member to the compliance audit scope. Once in-scope, Sprinto maps the user against configured controls and begins automated checks (like MDM verification, policy acceptance, and security training tracking).

"We just hired Bob Jones as a backend engineer. Please mark bob.jones@acmecorp.com as in-scope for Sprinto compliance tracking immediately."

Contextual Usage: This requires the email address. It returns a user object containing the internal Sprinto pk, firstName, lastName, and fullName. This is incredibly useful for HR automation chains triggered by a new row in an HRIS.

Mark Staff Member Not In-Scope

This tool explicitly removes a staff member from the audit compliance scope. Sprinto will immediately cease tracking security tasks for this user, which is vital for managing software contractors or offboarded employees.

"Remove charlie.davis@acmecorp.com from the Sprinto compliance scope. Pass the reason as 'Contract ended on November 15th'."

Contextual Usage: Similar to the in-scope tool, this requires the email address. It accepts an optional reason field, which is highly recommended for audit trail cleanliness.

For the complete inventory of available Sprinto proxy APIs, pagination schemas, and precise data definitions, review the Sprinto integration page.

Workflows in Action

Connecting Sprinto to Claude is only useful if you build deterministic, multi-step agentic workflows. Here is how specific personas leverage this MCP architecture to automate GRC drudgery.

Scenario 1: Automated Onboarding and Background Verification

Persona: HR Operations or IT Administrator.

When a new employee signs their offer letter, IT must immediately pull them into the compliance scope and attach their cleared background check. Doing this manually for every hire is error-prone.

"We have a new hire, Sarah Lee (sarah.lee@acmecorp.com). First, mark her account as in-scope for compliance. Then, upload her background verification report - the completion date was October 1st, 2025, and I have provided the file contents above."

Execution Steps:

1. Claude calls sprinto_staff_members_mark_in_scope passing email: "sarah.lee@acmecorp.com".
2. Sprinto responds with Sarah's user object and internal pk.
3. Claude parses the completion timestamp and formats it to the required ISO string.
4. Claude calls create_a_sprinto_background_verification_report using the email, the timestamp, and the parsed file payload.

Outcome: The IT admin receives confirmation that Sarah is tracked against company controls and her background check is immutably logged for the next SOC 2 audit window.

Scenario 2: Continuous Evidence Collection for DevOps

Persona: Security Engineer or DevSecOps.

Engineering teams constantly push updates, but collecting evidence for infrastructure changes (like vulnerability scan reports or access reviews) often happens manually right before an audit. AI can continuously poll and resolve these checks.

"List all Sprinto workflow checks. Find the one titled 'Q3 Cloud Infrastructure Vulnerability Scan'. Once you have the PK, upload the AWS Inspector CSV file I provided as evidence, and mark the record date as today."

sequenceDiagram
    participant Dev as Security Engineer
    participant AI as Claude (MCP Client)
    participant Truto as Truto MCP Server
    participant API as Sprinto API

    Dev->>AI: "List checks, find Q3 Scan, upload evidence"
    AI->>Truto: call list_all_sprinto_workflow_checks(limit=50)
    Truto->>API: GET /workflow-checks
    API-->>Truto: JSON edges + cursor
    Truto-->>AI: Returns paginated checks
    
    Note over AI: AI parses JSON to find<br>PK for "Q3 Cloud Scan"
    
    AI->>Truto: call create_a_sprinto_workflow_check_evidence(pk, file, date)
    Truto->>API: POST /evidence
    API-->>Truto: HTTP 200 (evidenceStatus updated)
    Truto-->>AI: Returns success node
    AI-->>Dev: "Evidence successfully uploaded for check-9921"

Execution Steps:

1. Claude calls list_all_sprinto_workflow_checks to retrieve the active compliance requirements.
2. Claude filters the returned JSON edges to match the text "Q3 Cloud Infrastructure Vulnerability Scan" and extracts its pk.
3. Claude calls create_a_sprinto_workflow_check_evidence passing the extracted workflowCheckPk, the current date, and the provided file payload.

Outcome: The compliance team gets automated, chronological evidence uploads without chasing down DevOps engineers in Slack.

Security and Access Control

Exposing an integrated GRC account to an LLM requires strict boundary setting. Truto's MCP tokens provide granular security configurations at the infrastructure level, preventing the model from executing unauthorized actions regardless of the user's prompt.

• Method Filtering: By defining config.methods: ["read"] during server creation, you completely disable all write operations (create, update, delete). If the LLM attempts to upload evidence, the server immediately rejects the JSON-RPC call before it ever reaches Sprinto.
• Tag Filtering: You can restrict the MCP server to only expose tools tagged with specific domains. For example, setting config.tags: ["staff"] ensures the agent can only interact with user scoping tools, hiding core compliance checks and organizational data.
• Time-to-Live (TTL) Expiration: For temporary contractor access or automated CI/CD runs, use the expires_at property. Truto automatically schedules a Durable Object alarm that permanently deletes the server token at the exact timestamp. Once expired, token lookups fail immediately across the distributed KV edge.
• Additional API Authentication: By setting require_api_token_auth: true, possession of the MCP URL alone is insufficient. The calling client must inject a valid Truto API token into the HTTP Authorization header, enforcing a secondary identity check against your organization's user registry.

Architecting for Agentic Compliance

Connecting Sprinto to Claude transforms GRC from a reactive, manual checkbox exercise into an automated, programmatic layer of your business. By leveraging Truto as your managed MCP infrastructure, you bypass the entire lifecycle of maintaining custom schemas, wrestling with cursor pagination, and building OAuth pipelines.

Your engineering time should be spent defining the business logic of your AI agents - crafting intelligent prompts and orchestration graphs - not deciphering the undocumented quirks of a third-party REST API. Generate the MCP server, connect it to your LLM framework, and let the model handle the heavy lifting of compliance mapping.