Connect Salesloft to Claude: Analyze Activity & Engagement History

If you need to connect Salesloft to Claude to automate sales activity logging, analyze engagement history, or orchestrate prospect sequences, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's tool calls and Salesloft'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 Salesloft to ChatGPT or explore our broader architectural overview on connecting Salesloft to AI Agents.

Giving a Large Language Model (LLM) read and write access to a high-volume sales engagement platform like Salesloft is a significant engineering challenge. You have to handle strict API quotas, map massive, deeply nested JSON schemas to MCP tool definitions, and manage the lifecycle of OAuth tokens. Every time Salesloft deprecates an endpoint or introduces a new requirement for a resource, 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 Salesloft, connect it natively to Claude Desktop, and execute complex sales workflows using natural language.

The Engineering Reality of the Salesloft 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, the reality of implementing it against Salesloft's API presents unique domain challenges. Salesloft is built for high-velocity sales teams, and its API architecture reflects strict rules around data uniqueness, relationship linking, and throughput.

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

The ID vs. GUID Dichotomy Salesloft uses a dual-identifier system across its resources. Depending on the endpoint, you might need to query using a standard numeric id or a string-based guid (Global Unique Identifier). For instance, fetching a user might require a guid, while updating a person requires an id. An LLM has no inherent context on which identifier to use when traversing resources. Your MCP server must explicitly guide the model via tightly constrained JSON Schema definitions so it passes the correct identifier format to the target endpoint.

Strict Upsert Collisions Salesloft is highly protective of CRM data integrity. When utilizing upsert operations (like creating a person), the API requires an upsert_key (such as email_address or crm_id). If the API detects that multiple existing records match the provided upsert key, the request will immediately fail rather than attempting to merge them. Your integration layer must be prepared to handle these 422 Unprocessable Entity errors and prompt the LLM to execute a deduplication search before re-attempting the write.

Harsh Rate Limits and HTTP 429s Salesloft enforces strict rate limits based on cost limits and concurrent requests per second. When building AI agents, LLMs can rapidly trigger sequential tool calls, easily blowing past these limits.

A critical factual note on rate limits: Truto does not retry, throttle, or apply backoff on rate limit errors. When Salesloft returns an HTTP 429 Too Many Requests, Truto passes that error directly back to the caller (the MCP client). However, Truto does normalize the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller (the AI framework or agent orchestrator) is strictly responsible for interpreting these headers and executing its own backoff strategy.

Generating the Salesloft MCP Server

Truto's MCP server generation is dynamic and documentation-driven. Rather than hand-coding tool definitions, Truto derives them directly from the connected Salesloft instance's resource definitions and schema documentation. A tool only appears in the MCP server if it has a corresponding documentation entry, ensuring the LLM only sees curated, AI-ready endpoints.

Each server is scoped to a single integrated account (a connected Salesloft instance for a specific tenant). The server URL contains a cryptographically hashed token that authenticates the request, identifies the tenant, and configures tool filtering.

There are two ways to generate a Salesloft MCP server in Truto.

Method 1: Via the Truto UI

For ad-hoc agent testing or internal operations, you can generate an MCP server directly from the dashboard.

1. Navigate to the Integrated Accounts page for your Salesloft connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration (e.g., allow only read operations, or filter by specific tags).
5. Copy the generated MCP server URL. It will look like https://api.truto.one/mcp/a1b2c3d4...

Method 2: Via the Truto API

For production workflows, you will want to dynamically provision MCP servers for your end-users as they authenticate their Salesloft instances. Truto generates a secure token, hashes it for edge validation, and returns a ready-to-use URL.

Make a POST request to /integrated-account/:id/mcp with your desired configuration:

fetch('https://api.truto.one/integrated-account/YOUR_ACCOUNT_ID/mcp', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer YOUR_TRUTO_API_TOKEN',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    name: "Salesloft Activity Analyzer",
    config: {
      methods: ["read", "write"] 
    },
    expires_at: "2026-12-31T23:59:59Z"
  })
})
.then(res => res.json())
.then(console.log);

The response contains the secure URL you will provide to Claude:

{
  "id": "mcp_srv_8x9y0z",
  "name": "Salesloft Activity Analyzer",
  "config": { "methods": ["read", "write"] },
  "expires_at": "2026-12-31T23:59:59.000Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6g7h8..."
}

Connecting the MCP Server to Claude

Once you have your Truto MCP URL, connecting it to Claude is a matter of configuration. Because Truto manages the protocol translation, state parsing, and token injection, the URL is entirely self-contained.

Option A: Via the Claude Desktop UI

If you are using Claude's graphical interface for testing or local usage:

1. Open Claude Desktop and navigate to Settings -> Integrations -> Add MCP Server.
2. Give the server a recognizable name (e.g., "Salesloft (Truto)").
3. Paste the URL you generated in the previous step.
4. Click Add. Claude will immediately issue an initialize JSON-RPC call to the URL, discover the available tools, and present them in the UI.

Option B: Via the Manual Config File (claude_desktop_config.json)

For programmatic setup or terminal-based AI assistants (like Cursor), you can configure the MCP connection manually using the Server-Sent Events (SSE) transport adapter.

Open your claude_desktop_config.json file (typically found in ~/Library/Application Support/Claude/ on macOS) and add the following entry:

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

Restart Claude Desktop. The model now has direct, contextual access to the underlying Salesloft instance.

Hero Tools for Salesloft

When Truto generates tools for Salesloft, it flattens the input namespace so query parameters and body payloads are handled seamlessly by the LLM. It automatically injects descriptions and pagination properties (like limit and next_cursor) directly into the JSON schema.

Here are the highest-leverage hero tools to expose to your AI agents.

1. list_all_salesloft_accounts

Fetches an array of account records, filterable by CRM IDs, custom tags, ownership, and engagement ranges. This is the entry point for agents conducting account research.

Contextual usage: This tool supports complex nested query parameters. Instruct the LLM to sort by updated_at DESC to prioritize recently active accounts.

"Find all Salesloft accounts tagged with 'Enterprise Q4' that have had engagement in the last 7 days. Return their IDs, domain names, and the current owner."

2. list_all_salesloft_people

Retrieves person (contact) records associated with accounts. Supports robust filtering, pagination, and sorting.

Contextual usage: Because Salesloft isolates People from Accounts at the top level, agents will typically call the accounts tool first to get the account_id, then pass that into this tool to find the relevant stakeholders.

"List all people associated with account ID 10495. I need their first names, last names, job titles, and email addresses."

3. create_a_salesloft_person_upsert

Creates or updates a person record based on a required upsert_key (typically email_address or crm_id).

Contextual usage: Always use this instead of the standard create tool when injecting new leads from external systems to avoid duplicating contacts. If the upsert key matches multiple records, the LLM must catch the failure and alert the user to a CRM data conflict.

"Upsert Jane Doe (jane.doe@example.com) into Salesloft as a VP of Engineering. Use her email address as the upsert key. Associate her with account ID 10495."

4. list_all_salesloft_activity_histories

Fetches a chronological log of all past activities found on the Salesloft Activity Feed for a specific person or account.

Contextual usage: This is the most powerful tool for giving an LLM "memory" of a deal. It returns unstructured dynamic_data that Claude excels at summarizing into actionable insights.

"Pull the activity history for Jane Doe over the last 30 days. Summarize all email opens, clicks, and replied threads into a concise bulleted list."

5. create_a_salesloft_call

Logs a phone call to a specific person, optionally completing a pending call task and syncing the notes directly to the underlying CRM (like Salesforce).

Contextual usage: The agent must provide the to phone number, duration, and a mapped disposition string. Note that task_id cannot be combined with action_id in the payload schema.

"Log a 5-minute call to Jane Doe. Set the disposition to 'Connected' and the sentiment to 'Interested'. Add this note: 'Great conversation, requested a technical demo next week.'"

6. create_a_salesloft_task

Creates a follow-up task (like an email reminder, phone call, or action item) associated with a person, user, or opportunity.

Contextual usage: Requires an ISO-8601 formatted string for due_date.

"Create a call task for me to follow up with Jane Doe on Thursday at 10:00 AM. Title it 'Follow up on technical demo'."

To view the complete inventory of available Salesloft tools, including their request bodies, required fields, and response schemas, visit the Salesloft integration page.

Workflows in Action

When you combine these MCP tools with Claude's reasoning capabilities, you can build autonomous agents that execute multi-step sales operations. Here are two real-world scenarios.

Scenario 1: The Pre-Meeting Account Brief

Sales reps often waste hours reading through disparate activity logs before a call. An agent can automate this data compilation in seconds.

"I have a meeting with Acme Corp tomorrow. Find their account record, identify all key stakeholders associated with the account, and summarize the last 14 days of activity history across all of them so I know exactly where the deal stands."

Execution Steps:

1. Claude calls list_all_salesloft_accounts searching for "Acme Corp" to retrieve the account_id.
2. Claude calls list_all_salesloft_people filtering by the retrieved account_id to get a list of person IDs (the stakeholders).
3. Claude loops through the person IDs, calling list_all_salesloft_activity_histories for each one, passing a timestamp filter for the last 14 days.
4. Claude synthesizes the unstructured activity JSON into a neat, readable executive brief for the sales rep.

Scenario 2: Autonomous Post-Call Logging and Follow-up

After a call, reps dictate notes. An AI agent can parse that dictation, log the call formally in Salesloft, and assign future tasks without manual CRM data entry.

"I just spoke with John Smith at TechLogix for 15 minutes. We connected, and he is highly interested. Log the call, write down that he wants to review the security whitepaper, and create a follow-up task for me to email him that paper next Tuesday."

sequenceDiagram
    participant User as Sales Rep
    participant Claude as Claude Desktop
    participant Truto as Truto MCP Server
    participant Salesloft as Salesloft API
    
    User->>Claude: Submit post-call dictation
    Claude->>Truto: tools/call list_all_salesloft_people (query: John Smith, TechLogix)
    Truto->>Salesloft: GET /v2/people?name=John%20Smith
    Salesloft-->>Truto: Returns Person ID (88219)
    Truto-->>Claude: JSON Tool Result
    
    Claude->>Truto: tools/call create_a_salesloft_call (payload: id=88219, duration=15m, disposition=Connected)
    Truto->>Salesloft: POST /v2/activities/calls
    Salesloft-->>Truto: 201 Created
    Truto-->>Claude: JSON Tool Result
    
    Claude->>Truto: tools/call create_a_salesloft_task (payload: id=88219, type=email, due=Next Tuesday)
    Truto->>Salesloft: POST /v2/tasks
    Salesloft-->>Truto: 201 Created
    Truto-->>Claude: JSON Tool Result
    Claude->>User: Confirmation: Call logged and task created.

Execution Steps:

1. Claude calls list_all_salesloft_people to resolve "John Smith" at "TechLogix" to a specific Person ID.
2. Claude maps the natural language inputs to the schema for create_a_salesloft_call, calculating the duration and setting standard enums for disposition.
3. Claude parses "next Tuesday" into an ISO-8601 string and calls create_a_salesloft_task using the same Person ID.
4. Claude confirms to the user that the CRM has been updated.

Security and Access Control

Giving an LLM access to your CRM data requires strict guardrails. Truto's MCP architecture provides several layers of access control configured at the token level, ensuring agents only touch what you explicitly allow.

• Method Filtering: By defining config.methods: ["read"] during token generation, you can restrict the MCP server to only allow get and list operations. The server will silently drop all create, update, and delete tools, making it impossible for the LLM to mutate Salesloft data.
• Tag Filtering: You can group integration resources by functional tags (e.g., "crm", "support"). If you pass config.tags: ["crm"], the MCP server will only generate tools related to those specific tagged resources.
• Secondary Authentication: By default, the hashed token in the URL provides sufficient access. For zero-trust environments, enabling require_api_token_auth: true forces the MCP client to also pass a valid Truto session or API Bearer token in the request headers.
• Time-To-Live (TTL): You can set an expires_at ISO datetime when generating the MCP server. Truto uses edge storage and durable alarms to automatically revoke the server URL precisely when the TTL expires, leaving no stale access credentials behind.

Automate Sales Data with Confidence

Building an integration with Salesloft is complex, but exposing it to an AI agent doesn't have to be. By leveraging Truto's managed MCP servers, you bypass the friction of OAuth token management, pagination normalization, and schema mapping. Your agents get immediate, secure access to dynamic tools generated straight from Salesloft's documentation.

Stop writing boilerplate API wrappers and start building agentic workflows.