Your agent needs to read and write Salesloft: pull cadence steps, find prospects who opened but never replied, log call outcomes, enroll people into the right sequence. Salesloft now ships two paths to that data. There is a Salesloft MCP Server that launched in April 2026 and is natively listed in Claude's connector directory, and there is the v2 REST API that integrations have been building against for years. They are not interchangeable. They differ on capability coverage, on which auth flows they accept, and on who owns the credential lifecycle in production. Here's how to pick.
These are two different products with two different audiences. One is a feature sold to revenue teams; the other is a platform surface sold to developers and partners. That distinction drives most of what follows.
Salesloft shipped its MCP Server in the April 2026 release, describing it as a way for AI tools to pull live data directly from Salesloft so answers reflect actual pipeline, calls, and accounts. Availability is limited to users with the Salesloft Agentic add-on, and a workspace admin has to enable it per user. Setup is documented in the Salesloft MCP Server help article.
In July 2026, Clari and Salesloft announced an expansion that puts Salesloft natively in Claude's connector directory and adds Cadence and activity data, Clari Copilot call intelligence, forecasting data, and write-back capabilities on a rollout running through late summer 2026.
The Salesloft platform API is a versioned REST interface at api.salesloft.com/v2 covering people, accounts, cadences, cadence memberships, actions, tasks, notes, calls, emails, email templates, and users. The full endpoint reference is published on the developer portal.
Authentication accepts a bearer token from any of three sources: the Authorization Code flow, the Client Credentials flow, or a customer API key. The API also exposes webhook subscriptions so a service can react to changes rather than poll for them.
Four dimensions decide this for an agent builder: what the agent can do, what credential it can hold, what you own when things break, and which scenario you are actually building for.
Salesloft has not published an MCP tool inventory or schema reference on its developer portal. That absence is itself the finding. The table below reflects what Salesloft has stated publicly, and marks anything it has not documented rather than guessing.
The Salesloft MCP Server is built for a rep sitting in Claude asking about their own pipeline. That is a legitimate and well-served use case. It is a different thing from a platform surface you architect a multi-tenant product on top of.
Three gaps matter concretely. There is no event subscription surface, so an agent that reacts to a reply, a bounce, or a cadence completion has to poll or use API webhooks. There is no published schema contract, so an agent bound to specific tool signatures can break when Salesloft ships a server update. And the write-back rollout is in flight, so a capability you validate this week may behave differently next month.
The MCP Server's access model is administrative: an admin turns it on for a rep, the rep connects through their AI client, and the connection carries that rep's identity. That is architecturally correct for user-present work and a hard stop for anything headless.
The REST API gives you three distinct credential shapes:
This is the detail that surfaces at three months, not at demo time. Salesloft access tokens carry an expires_in of 7200 seconds. When you exchange a refresh token, Salesloft revokes every previous refresh token for that grant and issues a new one you must persist.
That makes concurrent refresh a correctness problem rather than a performance one. Two agent workers handling the same rep at the same moment will both attempt a refresh, one will win, and the loser's stored refresh token is now dead. The rep gets silently disconnected and nobody finds out until a scheduled run returns nothing. Handling this correctly requires distributed locking around refresh, proactive renewal against expires_in, and atomic write-back of the rotated token.
On the MCP path, Salesloft manages hosting, schemas, and permission enforcement. You still own per-rep connection state, detecting when an admin disables the add-on for someone, and adapting when tool behavior changes underneath you without a version bump.
On the REST path you own endpoint selection, request construction, pagination, retry logic, and the full token lifecycle described above. That is more surface area and considerably more control. You pin to v2, you migrate on your schedule, and a Salesloft server-side change to an AI feature does not restructure the contract your pipeline depends on.
Salesloft's rate limit is 600 cost per minute, applied at the team level rather than per integration. Every integration your customer runs draws from the same budget, including yours.
Deep pagination is penalized on a sliding scale: pages 101 to 150 cost 3 points, 151 to 250 cost 8, 251 to 500 cost 10, and 501 and above cost 30. Salesloft's guidance is to build a cursor poller keyed on updated_at instead of walking page numbers. Responses carry x-ratelimit-endpoint-cost and x-ratelimit-remaining-minute, and an agent doing real work should read both. Agentic workflows fan out into multiple sequential calls per user action, so the math moves faster than it does for a traditional integration.
Two lists, both specific to Salesloft rather than generic MCP advice.
Use the Salesloft MCP Server when:
Use the Salesloft REST API when:
Both paths hand you a credential per rep. Neither hands you a vault, rotation logic, or a revocation flow. That infrastructure gets built regardless of which path you chose.
A sales engagement agent is per-rep by nature. Cadence ownership, activity attribution, and manager visibility all depend on the action being recorded under the rep who triggered it. Run that agent for 60 reps across 12 customer workspaces and you have 60 OAuth grants to store encrypted, 60 access tokens expiring on a two-hour clock, and 60 rotating refresh tokens that must be written back atomically.
Then a rep leaves. Their Salesloft access is disabled, but a stored refresh token in your database does not know that. A scheduled agent does not decide to stop using it. It just keeps trying, and the failure is a silent 401 in a background job rather than an alert. This is exactly the kind of scenario covered in detail when examining credential ownership across agent tool-calling patterns.
A single service-account token is the shortcut everyone reaches for, and it looks correct in a demo. In production it collapses attribution. Every logged call, every note, every cadence enrollment appears under one identity. Manager dashboards break, activity reporting breaks, and the audit trail cannot answer which human initiated a given action.
Scalekit's Salesloft connector runs the per-rep OAuth flow, holds each rep's tokens in an AES-256 vault namespaced per tenant, and resolves the correct credential server-side on every tool call. Refresh and rotation are handled for you, which removes the concurrent-refresh race entirely. The credentials never enter your agent runtime or the LLM context. The MCP versus API decision does not change any of that. For a deeper look at why building this yourself carries hidden costs, see the hidden cost of building OAuth internally for AI agents.
Scalekit ships one Salesloft connector rather than separate API and MCP variants. The same connector is callable as native tool schemas through execute_tool and reachable over a Scalekit-hosted MCP endpoint at https://mcp.scalekit.com/salesloft. You pick the interface; the auth model is identical either way.
The connector ships 36 prebuilt tools spanning the objects a sales engagement agent actually touches: accounts, people, cadences, cadence memberships, actions, tasks, notes, calls, emails, email templates, and users. Each ships with an LLM-ready schema tested against the live API, including the filter surface that makes these tools useful.
salesloft_people_list alone accepts 53 parameters covering cadence membership, reply state, bounce state, contact restrictions, owner, stage, and timestamp windows. Writing and maintaining that schema yourself is the hidden tax. Writing the schema is the hard part, not the API call.
Create a Salesloft OAuth application under Settings then Your Applications then OAuth Applications, and register its client ID and secret in the Scalekit dashboard under AgentKit then Connections. Note the connection name you create; the string must match the connection_name in your code exactly. This is the single most common integration error.
Each rep authorizes once. Scalekit creates a connected account tied to your application's identifier for that person and tracks its auth state from then on.
Before the agent loop runs, retrieve the tools this rep's connected account is authorized to call. This is not a catalog browse. The surface returned is derived from what this specific rep authorized, so a rep without write scope never sees a write tool in context, and the model cannot select what it cannot see.
Scalekit returns input_schema in exactly the shape Anthropic's tool use API expects, so nothing needs reshaping. The loop below is complete.
Identical model, Node SDK. Note that tool listing lives on scalekit.tools while execution lives on scalekit.actions.
Scalekit returns native StructuredTool objects, so there is no adapter layer to write. For more on how LangChain tool calling works in agentic contexts, see LangChain tool calling: how it works, where it stops, and how Scalekit completes it.
Handing an agent all 36 Salesloft tools is a mistake in two directions at once. At roughly 200 tokens per tool schema, the full surface burns around 7,200 tokens of context before the agent does any work, and at thousands of runs per day that is a real operating cost. Selection accuracy degrades at the same time, because the model is choosing from a decision space it was never designed to handle at that scale.
Virtual MCP Servers fix both by declaring exactly which tools an agent role can see. The fix is not better prompting. It is surface reduction.
A cadence hygiene agent needs four tools, not thirty-six. Create the server once and reuse the static mcp_server_url for every rep.
Four tools instead of thirty-six drops schema overhead by roughly 89 percent. It also means this agent structurally cannot delete a person or create an account, because those tools are not on its endpoint.
The endpoint is static. The identity is not. Confirm the rep's connection is still live, then mint a short-lived token scoped to that rep before every run.
Real sales agents rarely stop at Salesloft. A deal intelligence agent reads Salesloft cadence execution, pulls call context from Gong, and writes back to Salesforce. Each of those connectors adds its own tool surface, and the combined catalog crosses a hundred tools quickly.
One Virtual MCP server definition covers all of them with the specific tools each agent role needs, and one session token per run resolves every connector under the same rep. No credential sharing between reps, no per-rep server configuration, and no MCP server for you to deploy, host, or maintain. Cross-tenant tool calling requires per-tenant authorization, and there is no shortcut around that. For a concrete example of this pattern in practice, see how to build a deal intelligence agent with Gong, Attio, and Slack.
Salesloft's own API Logs show you which integration hit which endpoint on a given team. What they cannot tell you is which human triggered a given agent run, or which agent role in your product made the call.
Scalekit logs every downstream tool call: which rep's connected account resolved, which tool ran, what came back, and when. History is retained for 90 days and is exportable to a SIEM. Auth logs cover the credential side of the same trail, including token issuance, refresh, and revocation events, with filtering by user, organization, and status.
When a compliance reviewer asks whether the agent was authorized to remove a person from a cadence last Tuesday, the answer needs three facts in one place: who authorized the connected account, what scope it carried at execution time, and what the tool actually did. Standard application logging captures a user ID and a timestamp and none of the rest.
Failure-first visibility matters just as much. A rep who revokes Salesloft access fails closed on the next tool call, that event is logged, and other reps on the same connection are unaffected. That is the difference between noticing a broken integration and discovering it in a quarterly pipeline review. For a structured approach to this problem, see agent tool observability: your agent is running — is it actually working?
The decision comes down to who is present when the agent runs.
If reps already have the Salesloft Agentic add-on and the job is call prep, account briefings, and pipeline questions answered in natural language, the Salesloft MCP Server gets there with no code from you. Treat it as a feature your customers turn on, not as a platform you build a product on.
If the agent runs on a schedule, reacts to webhook events, or acts across multiple customer workspaces with independent revocation boundaries, build against the REST API. Client Credentials for service-level work, Authorization Code per rep for anything attributed to a human, and a real cursor poller instead of deep pagination.
Most production Salesloft agents end up running both modes in the same product. The interactive assistant sits on one path, the overnight pipeline on the other. What does not change across that split is the credential layer: 60 reps still means 60 rotating grants, and that is the part that needs production-grade infrastructure rather than a database column. The patterns that emerge when moving from single-tenant to multi-tenant are worth studying before you commit to an architecture — see how tool calling auth changes when you move from single-tenant to multi-tenant.
If you are working through cadence attribution, per-rep scoping, or the refresh rotation race, other people are solving the same problems right now.
Join the Scalekit Slack community to compare notes, or talk to an engineer if you want help on a specific architecture decision.
Browse the Scalekit Salesloft connector: scalekit.com/connectors/salesloft
