Best MCP Server for Salesforce: Hosted MCP vs Unified API (2026)

If you are evaluating the best MCP server for Salesforce integration to power AI agents across your B2B SaaS customer base, the architectural choice comes down to one fundamental question: are you connecting to your own Salesforce org, or to your customers' orgs at scale?

Writing custom point-to-point API connectors and hand-rolled SOQL wrappers for your AI agents is a dead end. The Model Context Protocol (MCP) reached 97 million monthly SDK downloads by March 2026, establishing it as the de facto standard for AI agent tool integration. But standardizing the protocol does not solve the underlying infrastructure problem. The market has fractured, and the platform you pick determines whether your agents run autonomously against your customers' Salesforce instances—reading pipeline, writing opportunities, and executing workflows across hundreds of tenants—or stall out permanently at the enterprise security review.

This guide breaks down the architectural trade-offs of the three leading platforms in 2026: Salesforce's native Hosted MCP, third-party MCP gateways, and programmable Unified APIs. We examine how to handle the painful realities of Salesforce rate limits, and explain why dynamically generated tools have replaced hardcoded integration catalogs for B2B SaaS teams. If you want a broader framing across every major SaaS category first, our buyer's guide to MCP server platforms covers the wider landscape.

The Multi-Tenant Salesforce Problem for AI Agents

Connecting a single AI agent to a single Salesforce org for internal use is trivial. Connecting a multi-tenant SaaS application's AI agent to thousands of distinct customer Salesforce orgs is an engineering nightmare.

Three structural realities collide when you introduce autonomous AI agents into this mix:

• Every org is a unique snowflake of technical debt: Enterprise customers heavily modify their environments. Custom objects (Deal_Stage__c), custom fields (the infamous __c suffix), org-specific validation rules, record types, and sharing rules mean that the "contacts" object in Customer A's org is not the same shape as Customer B's. A tool hardcoded to POST /services/data/v60.0/sobjects/Contact will fail if the customer's org requires a custom Industry_Segment__c field to save a contact record.
• SOQL complexity is not standard SQL: Translating natural language into valid Salesforce Object Query Language (SOQL) requires deep context about the specific tenant's schema relationships. Filtering, searching (FIND {...} RETURNING), and joining across objects require constructing exact SOQL strings, not passing REST-style filters. AI agents that generate raw SOQL without strict schema boundaries will hallucinate field names half the time.
• Aggressive and unforgiving rate limiting: Salesforce restricts concurrent long-running API requests (lasting longer than 20 seconds) to a maximum of 25 for production orgs (and just 5 for developer orgs). Each individual API call is also capped at a 10-minute maximum execution time.

AI agents make this dramatically worse. They do not click through paginated UIs; they operate in loops and fire off dozens of parallel API requests to resolve a single user prompt. A single request like "summarize this account" can fan out into ten parallel tool calls: list contacts, list opportunities, list activities, get account, list cases, search notes. Multiply by every active session across every tenant, and the 25-concurrent ceiling starts looking like a strict design constraint, not an edge case.

Evaluating Salesforce's Native Hosted MCP Servers

In April 2026, Salesforce announced the general availability of Hosted MCP Servers, providing built-in platform capabilities to expose org logic directly to AI clients across every Enterprise Edition org and above. This is the biggest structural shift in the Salesforce integration landscape in a decade. For internal enterprise IT teams building agents exclusively for their own company, this is the optimal path.

One of the standout aspects of the GA release is how permissions are handled. Every MCP transaction runs with the authenticated user's identity, meaning existing CRUD, field-level security, and sharing rules all apply automatically. If an AI agent updates a record, the human user's name still appears in the audit trail. If their permissions don't allow an operation, neither does the agent. The agent connects directly to the Salesforce-hosted endpoint, guaranteeing that data never leaves the Salesforce trust boundary until the agent requests it.

That governance model is genuinely strong. However, look closer at the tool architecture: Salesforce provides a set of standard MCP servers that expose built-in platform and product capabilities. These servers are pre-configured by Salesforce and provide a fixed set of tools. Standard servers are disabled by default and can be enabled by an administrator, but their tool sets cannot be modified.

That is a great model when the AI client is Claude Desktop or ChatGPT connecting to your company's org. It is a fundamentally broken model for a B2B SaaS vendor whose product needs to programmatically provision MCP access for thousands of customer tenants.

The practical blockers for multi-tenant SaaS include:

• Requires Enterprise Edition or above: Any customer on Professional Edition or lower-tier plans is instantly locked out. Your SaaS product simply will not work for them.
• The External Client App Bottleneck: To connect an external AI agent, the SaaS vendor cannot simply provide a generic OAuth flow. Each customer's Salesforce administrator must manually navigate deep into Setup, create a new External Client App, configure specific OAuth policies and highly privileged scopes (api, refresh_token), generate client credentials to pass back to your app, and explicitly assign MCP tool permissions via Permission Sets. In a multi-tenant B2B environment, asking every customer to execute this manual configuration drops integration conversion rates to near zero.
• Human-in-the-loop by design: An MCP server hands your CRM to an AI inside a conversation you start. It's a doorway, not a worker. Nothing watches your pipeline for you, nothing fires when an opportunity changes stage, and nothing runs while the chat is closed. If your product runs autonomous background agents, this transport model does not fit.
• No programmatic provisioning: You cannot offer a frictionless, one-click "connect Salesforce" product-led growth (PLG) experience if every tenant has to hand-configure servers.

Salesforce Hosted MCP wins for internal enterprise deployments. It loses when you are the vendor selling a product on top of Salesforce.

The MCP Gateway Approach (Arcade, Composio, StackOne)

The friction of native Salesforce setup led to the rise of third-party MCP gateways. Platforms like Arcade.dev, Composio, and StackOne position themselves as the "MCP runtime for production AI agents," offering managed authentication and pre-built tool catalogs.

These platforms solve the provisioning problem by hosting an MCP endpoint on your behalf and handling OAuth centrally. They provide a centralized OAuth application, allowing your customers to connect their Salesforce accounts via a standard popup window. The gateway manages the refresh tokens, stores the credentials, and exposes an MCP server endpoint for your agent to consume. For a demo or a lightweight assistant that reads standard objects, this fast time-to-first-tool-call works.

The Fatal Flaw: Static Tool Catalogs

While gateways solve the authentication problem, they introduce a fatal flaw for enterprise SaaS: hardcoded tool catalogs cannot see custom objects.

When you use a standard MCP gateway, the platform typically provides a pre-built set of tools, such as salesforce_create_contact, salesforce_update_opportunity, or salesforce_search_accounts. These tools are backed by static JSON schemas that map to Salesforce's default standard objects.

The moment your customer connects an org with mandatory custom fields, the static tools break. When your customer's Salesforce admin created Renewal_Opportunity__c with required fields Contract_Value__c and Health_Score__c last quarter, your gateway's static tool catalog has no idea it exists. The API call will fail with a 400 Bad Request. The AI agent, lacking the schema context to fix the error, will either hallucinate a workaround or enter an infinite retry loop.

You now have three options:

1. Ask the vendor to add support (roadmap-dependent, taking weeks to months).
2. Fall back to a generic salesforce_execute_soql escape hatch. Effectively offloading the schema discovery and query building back to your LLM without strict boundaries is a massive security and reliability risk. It won't write valid SOQL reliably.
3. Fork the tool catalog and maintain it yourself, negating most of the reason you bought a gateway.

Furthermore, most gateways still require the customer to configure a Connected App with specific scopes before the connection works, meaning some admin friction remains. For a deeper dive into the limitations of static catalogs, review our analysis of Salesforce-specific MCP tooling.

The Unified API Approach: Dynamic Tool Generation

The most scalable architecture for B2B multi-tenant AI agents is a programmable Unified API with documentation-driven MCP tool generation. As we note in our MCP buyer's checklist for B2B SaaS, this is the architecture Truto employs, and it fundamentally solves the custom object problem without requiring manual Salesforce configuration.

The design principle is simple. Instead of shipping a static list of hardcoded Python or TypeScript logic for Salesforce tools, a true Unified API handles integration variability purely through data mapping. The platform maintains a canonical Salesforce integration definition, handles per-tenant OAuth token isolation, and generates one MCP server URL per connected account. Crucially, it derives tools on every tools/list call from the current integration definition, filtered by tenant, method type, and functional tag.

Zero Integration-Specific Code

In Truto, the mapping between a unified data model (e.g., "CRM Contacts") and Salesforce's specific API is defined using JSONata expressions stored as configuration data. All the Salesforce-specific behavior—PascalCase field mapping, SOQL WHERE clause construction, handling six different phone number field types (Phone, Fax, MobilePhone, HomePhone, OtherPhone, AssistantPhone), and custom field detection via the __c suffix—lives in these expressions.

For example, translating a unified query into SOQL dynamically incorporates the specific tenant's custom fields:

query_mapping: >-
  (
    $whereClause := query
      ? $convertQueryToSql(
        query.{
          "created_at": created_at,
          "updated_at": updated_at,
          "email_addresses": email_addresses ? $firstNonEmpty(email_addresses.email, email_addresses),
          "account": account.id,
          "name": $firstNonEmpty(name, first_name, last_name)
            ? { "LIKE": "%" & $firstNonEmpty(name, ...) & "%" },
        },
        ["created_at", "updated_at", "email_addresses", ...],
        {
          "created_at": "CreatedDate",
          "updated_at": "LastModifiedDate",
          "email_addresses": "Email",
          "account": "AccountId",
          "name": "Name",
        }
      );
    {
      "q": query.search_term
        ? "FIND {" & query.search_term & "} RETURNING Contact(Id, FirstName, ...)",
      "where": $whereClause ? "WHERE " & $whereClause,
    }
  )

And the conceptual sketch of the response mapping seamlessly absorbs the Salesforce quirks into a clean unified object:

response_mapping: >-
  response.{
    "id": Id,
    "first_name": FirstName,
    "last_name": LastName,
    "email_addresses": [{ "email": Email }],
    "custom_fields": $sift($, function($v, $k) { $k ~> /__c$/i })
  }

How Dynamic MCP Tool Generation Works End-to-End

Because this mapping is executed at runtime, adding support for a new object or method is a data change, not a code deploy. Custom object support becomes an integration-layer feature automatically exposed to the LLM.

When an MCP client connects to the Truto MCP server URL, the platform executes the following flow:

1. Authentication: The server validates the cryptographic token embedded in the URL against a low-latency key-value store, identifying the specific tenant's integrated account.
2. Documentation Fetch: The platform fetches the live documentation records for that specific integration, including any environment-level overrides.
3. Schema Building: Query and body schemas are extracted. For individual methods (like update), an id property is automatically injected. For list methods, pagination cursors are appended.
4. Tool Assembly: The tools are exposed to the LLM with highly descriptive snake_case names (e.g., update_a_salesforce_deal_by_id) and exact JSON schemas matching the tenant's actual data shape.

sequenceDiagram
    participant Agent as AI Agent
    participant MCP as Truto MCP Endpoint
    participant Auth as OAuth Token Vault
    participant UAPI as Unified API Layer
    participant SFDC as Salesforce (Tenant Org)

    Agent->>MCP: POST /mcp/:token (tools/list)
    Note over MCP: Generate tools from<br>integration + live docs
    MCP-->>Agent: List of dynamic tools<br>(incl. custom objects)
    Agent->>MCP: POST /mcp/:token (tools/call)
    MCP->>Auth: Get refreshed token for tenant
    Auth-->>MCP: Bearer token
    MCP->>UAPI: Proxy API Execution
    Note over UAPI: JSONata mapping<br>Dynamic resource resolution
    UAPI->>SFDC: SOQL Query / REST API
    SFDC-->>UAPI: Raw Salesforce Response (or 429)
    Note over UAPI: JSONata response mapping
    UAPI-->>MCP: Normalized JSON + Rate-limit Headers
    MCP-->>Agent: MCP JSON-RPC 2.0 Response

When the agent calls the tool, all arguments arrive as a single flat object. The MCP router splits them into query parameters and body parameters using the schemas' property keys, delegating execution to the proxy API handlers. This means the agent operates on the integration's native resources directly, with full support for custom objects. For teams focused on compliance, we cover the deeper security model in our guide on zero data retention MCP servers.

Handling Salesforce Rate Limits and HTTP 429s

Rate limits are where the architectural choice becomes a runtime correctness issue. As mentioned earlier, Salesforce restricts concurrent long-running requests to 25. Once this limit is reached, any API request coming to the Salesforce queue will be queued or rejected, causing integration failures.

One of the most dangerous architectural mistakes when building AI agents is relying on a black-box integration provider that silently swallows rate limit errors. Many legacy integration platforms attempt to be "helpful" by automatically retrying these requests under the hood, applying their own opaque exponential backoff. In an AI agent context, this is disastrous.

Hidden retries produce three critical failure modes:

• Runaway concurrency: If the gateway retries under the hood and the agent's framework retries on top, you multiply the effective request rate against the 25-request ceiling.
• Silent latency spikes: Tool calls that mysteriously take 40 seconds because the platform is waiting on internal backoff look like a broken, hallucinating agent to the user.
• Corrupted state on writes: Auto-retrying a write that already succeeded but timed out on the response is how you end up with duplicate opportunities and corrupted CRM data.

Transparent Rate Limit Passthrough

The correct behavior is to pass the upstream signal through. Truto takes a radically honest, transparent approach to rate limits. Truto does not retry, throttle, or absorb rate-limit errors internally.

When the upstream Salesforce API returns an HTTP 429 (or REQUEST_LIMIT_EXCEEDED on 403), Truto passes that error directly back to the caller immediately. More importantly, Truto normalizes the upstream rate limit information into standardized headers per the IETF specification:

• ratelimit-limit: The total request limit for the window.
• ratelimit-remaining: The number of requests left.
• ratelimit-reset: The timestamp when the limit resets.

By passing these headers through the MCP protocol, your agent's control loop—or the orchestration layer wrapping it—gains full visibility into the rate limit state. The agent can deliberately pause its own execution, inform the user ("Salesforce is currently processing too many requests, I will resume in 14 seconds"), and handle the backoff natively. This prevents opaque timeouts and keeps the agent deterministic under load.

Hosted MCP vs Unified API: The Final Verdict for 2026

As outlined in our decision matrix for enterprise AI agents, the decision reduces to two simple questions: whose org are you connecting to, and how complex is the schema?

If you are building an internal tool exclusively for your own company's Salesforce org, use Salesforce's native Hosted MCP. It is built directly into the platform, handles field-level security perfectly, and requires no third-party infrastructure.

If you are building a B2B SaaS product where AI agents must autonomously interact with hundreds of different customers' Salesforce instances, a Unified API with dynamic MCP tool generation is the only viable architecture. Static MCP gateways will fail the moment they encounter mandatory custom fields. By treating integration mapping as data rather than code, and dynamically generating tools from live schemas, Unified APIs ensure your agents can read, write, and reason about enterprise data without stalling out on schema validation errors.