Salesforce MCP vs Salesforce API for AI Agents

TL;DR

• Salesforce Hosted MCP is now GA and covers SObject CRUD, Flows, Invocable Apex, Apex REST, Data 360, and Tableau. Bulk API, Metadata API, Tooling API, and Streaming API are REST-only.
• The Hosted MCP server is OAuth + PKCE only, via External Client Apps. No API key option. No Connected App auth. If your agent runs headless or on a background schedule, MCP requires an interactive OAuth flow per user; there is no static credential shortcut.
• The REST API supports OAuth, JWT Bearer (RFC 7523) for server-to-server, and Connected App client credentials, including fully headless patterns with no user interaction required.
• Salesforce's per-user permission model enforces FLS, sharing rules, and CRUD on every MCP tool call. Architecturally correct. But it means N OAuth tokens per tenant in a multi-tenant B2B agent, and neither path stores, refreshes, or revokes those tokens for you.
• Scalekit's Salesforce connector handles the per-user OAuth flow, token storage, and refresh for both paths. The MCP vs API decision doesn't change your credential infrastructure.

Your agent needs to work with Salesforce. It needs to query opportunities, trigger flows when deals close, and update records on behalf of your sales reps. Salesforce Hosted MCP went GA on April 29, 2026. The REST API has been production-ready for a decade. Both paths work. They make different tradeoffs, and for background agents specifically, one of those tradeoffs is a hard blocker.

What Each Path Actually Is

Salesforce Hosted MCP

Salesforce Hosted MCP is a Salesforce-managed endpoint that exposes your org's data, flows, and Apex actions to any MCP-compatible AI client. It went GA in April 2026 and is available on Enterprise Edition and above. Salesforce handles hosting, scaling, and permission enforcement. You enable a server in Setup and it's live.

Auth is OAuth 2.0 + PKCE via External Client Apps (ECA) only. The required scopes are mcp_api and refresh_token. One critical constraint: you cannot use Connected Apps for MCP authentication. ECA is the only supported path.

MCP endpoint format: https://api.salesforce.com/platform/mcp/v1/platform/{server-type}

Official docs: developer.salesforce.com/docs/platform/hosted-mcp-servers

Salesforce REST API (and the Broader API Surface)

The REST API is one of six distinct Salesforce API surfaces agents need to reason about: REST (record CRUD and SOQL), Bulk API 2.0 (high-volume async, up to 150M records per job), Metadata API (org config deployment and retrieval), Tooling API (Apex and metadata with dependency graphs), Streaming API (change events via Bayeux/CometD), and SOAP (legacy, WSDL-based).

Auth supports OAuth Authorization Code, JWT Bearer Grant (RFC 7523) for server-to-server with no interactive flow, and Connected App client credentials. Per-user delegation and service-account patterns both work.

API limits apply across all surfaces. Enterprise Edition defaults to 100K calls per day. Every call counts, including MCP tool calls.

Official docs: Salesforce Platform API Integration Guide on Trailhead

Comparing Them Where It Matters for Agents

Capability Coverage

The Hosted MCP server exposes 11 server types. The gap with the full REST API surface is real and specific.

Where the MCP Ceiling Is

The Hosted MCP server is built for user-facing, record-level interactions. Everything above the record layer is REST-only: bulk operations, metadata management, org automation governance, dependency analysis.

If your agent's job involves configuring the org, processing high volumes of records, or subscribing to real-time changes, MCP is not the right path. That's not a temporary limitation; it reflects what the MCP server was designed for.

The Auth Path Each One Puts You On

MCP Auth: OAuth Only, Per User, Every Time

The Hosted MCP server enforces OAuth Authorization Code + PKCE per user, with no alternative. The mcp_api scope is separate from the api scope: MCP credentials do not grant REST API access, and REST credentials do not grant MCP access. You configure an ECA once per server; every user who connects goes through their own OAuth flow.

This is architecturally correct for user-facing agents. It is a hard constraint for background agents.

The Headless Gap

If your agent runs on a schedule (nightly pipeline sync, background opportunity scoring, automated deal reporting), the MCP path requires a pre-established user session per user. There is no static credential option.

The REST API's JWT Bearer Grant (RFC 7523) gives you clean server-to-server auth with no interactive flow. The agent authenticates with a private key, receives a scoped access token, and operates without user interaction. That's the right pattern for headless execution. MCP does not support it.

The Multi-Tenant Reality

For a B2B agent serving 40 sales reps across 8 enterprise orgs, MCP's per-user model means 40 OAuth tokens to store, refresh (Salesforce access tokens expire at the org's session timeout, defaulting to 2 hours), and revoke when someone leaves.

The REST API gives you a choice: service account per org (8 tokens) or per-user delegation (40 tokens). MCP enforces user-level identity. Neither path handles storage, rotation, or revocation for you. That's infrastructure you build or buy.

This is the same multi-tenant access control challenge that every B2B agent builder faces, regardless of the Salesforce surface they choose.

What You Own in Production

On the MCP Path

Salesforce manages hosting, scaling, and schema updates. You own: OAuth token storage per user per org; refresh handling against the org's session timeout policy (set Force relogin after to None for agent-facing ECAs or agents will hit 401s mid-session); API limit consumption (MCP tool calls count against the org's daily limit, same as REST calls); and IP allowlisting for cloud-hosted agent services hitting the MCP endpoint.

On the REST API Path

You own everything above, plus endpoint versioning (you pin an API version and migrate on your schedule), rate-limit handling per surface (REST, Bulk, and Streaming have different error and retry models), and adapter code for each API surface you use.

API Limits as a Production Constraint

Enterprise Edition defaults to 100K API calls per day. An agent serving 40 sales reps, querying pipeline before each meeting, triggering flows on close, and updating contact records burns through that faster than a traditional integration. Agentic workflows issue multiple sequential API calls per user action; the math changes quickly.

Monitor API usage from day one. Neither path exempts you from the limit.

Schema Drift and Versioning

MCP server schemas change when Salesforce updates the hosted server. You're consuming a managed contract but don't control the versioning cadence. The REST API is versioned explicitly; you pin a version and migrate when you choose. For deterministic production pipelines where an unexpected schema change is an incident, that distinction matters.

When to Use MCP, When to Use the API

Use Salesforce Hosted MCP When

• Your agent is user-facing and interactive: sales reps querying accounts or deal status through Claude or ChatGPT without leaving their AI assistant
• You're exposing Salesforce flows or Apex actions to non-developer users via natural language and don't want to build REST adapter code
• You want Salesforce's FLS and sharing rules to automatically constrain what the agent can do per user; the permission model is a feature, not overhead
• You're integrating with Data 360 or Tableau and want a consistent MCP interface rather than managing separate API clients per product

Use the Salesforce REST API (or Bulk / Metadata / Tooling) When

• Your agent runs on a background schedule without a user session; JWT Bearer auth is the right path, and MCP doesn't support it
• Your use case touches Bulk API (anything over tens of thousands of records), Metadata API (org config), or Tooling API (dependency analysis); these surfaces don't exist in the Hosted MCP server
• You need to serve multiple orgs from a service account rather than managing per-user OAuth grants across your tenant base
• You're building a deterministic pipeline where you control endpoint versioning and can't absorb unplanned schema changes from Salesforce

The Credential Problem Neither Path Solves

What Salesforce Gives You

Salesforce's per-user identity model is the right security posture. Every MCP tool call runs as the authenticated user; their FLS, sharing rules, and CRUD permissions apply. If a user can't edit an opportunity, the agent can't edit it either. That's what enterprise security auditors want to see.

But Salesforce enforces identity. It doesn't manage the credential lifecycle on your behalf.

What You Still Have to Build

In a multi-tenant B2B agent serving 40 sales reps across 8 enterprise orgs: 40 OAuth tokens to store encrypted, 40 access tokens to refresh proactively before the 2-hour session timeout, 40 tokens to revoke when a rep leaves their company. Multiply that across orgs. Add the service-account tokens if you're running background jobs on the REST API path.

The credential management problem is structurally identical whether you choose MCP or the REST API. The token type differs; the infrastructure required does not.

This is the same token refresh challenge that surfaces in every production agent architecture. Secure token management at scale requires dedicated infrastructure for storage, rotation, and revocation—none of which Salesforce provides out of the box.

Scalekit's Salesforce connector handles the OAuth flow, per-user token storage, and automatic refresh for both paths: so the MCP vs API decision doesn't change your credential infrastructure.

Which One to Build Against

For user-facing agents (the sales assistant that preps account reviews, the deal intelligence agent that surfaces opportunity data in a chatbot), Salesforce Hosted MCP is the right path. The permission model is already enterprise-grade. You don't build REST adapters. The FLS and sharing rules work in your favor.

For background agents (nightly pipeline syncs, bulk data operations, metadata management, scheduled reporting), use the REST API directly. JWT Bearer auth, Bulk API 2.0, and explicit versioning give you what headless execution requires.

Most production Salesforce agents will use both. The interactive assistant runs on MCP. The background pipeline runs on REST. The credential management problem is the same either way, and that's what needs production-grade infrastructure regardless of which path you're on.

The question of MCP vs APIs isn't about picking a winner. It's about understanding which surface fits which execution model—and building the identity layer that works across both.

Browse the Scalekit Salesforce connector: scalekit.com/agent-connector/salesforce