AI Integration - MCP

Salesforce Hosted MCP Servers (Beta)

A practical guide for Salesforce admins, developers, and architects who want to understand what Salesforce MCP is, where Hosted MCP Servers fit, which features they expose, and how to roll them out with the right guardrails.

12 min read Published April 15, 2026 By Shivam Gupta
Shivam Gupta
Shivam Gupta Salesforce Architect and founder at pulsagi.com
AI and enterprise platform connectivity

Salesforce Hosted MCP Servers turn Salesforce data, automation, prompts, and product capabilities into governed tools that external AI clients can use through the open MCP standard.

Introduction

Salesforce Hosted MCP Servers are Salesforce's managed implementation of the Model Context Protocol, designed to let external AI clients interact with Salesforce using a standard, secure connector model instead of one-off custom integrations. In simple terms, Salesforce turns CRM data, automation, prompts, and selected product capabilities into MCP tools that clients such as Claude, ChatGPT, Cursor, and Postman can call.

This article is intentionally framed around Salesforce Hosted MCP Servers (Beta) because Salesforce Help currently documents the feature that way in the references provided. At the same time, Salesforce's developer documentation has expanded significantly, so teams should verify the exact release status and product availability in their own org before committing to production rollout. Salesforce also publishes a beta-to-GA transition guide, which is a strong signal that teams should confirm current server URLs and activation steps instead of reusing older beta client configurations blindly.

Practical framing: Salesforce Hosted MCP Servers are not "AI inside Salesforce." They are a governed interoperability layer that lets external AI systems use Salesforce capabilities without bypassing Salesforce security.

What is Salesforce MCP

MCP is an open standard for connecting AI applications to external systems. Salesforce's hosted implementation applies that standard to the Salesforce platform. Instead of building a custom REST wrapper for every AI client, you configure access once in Salesforce, authenticate users with OAuth, enable the right servers, and then let compatible clients connect through a standard MCP endpoint.

What it gives you

  • Per-user authentication instead of a shared service account model.
  • Runtime enforcement of object permissions, field-level security, and sharing rules.
  • Admin-managed server activation and server curation.
  • Support for both out-of-box Salesforce capabilities and your own custom tools.

What it replaces

  • Point-to-point AI integrations for each client.
  • Custom proxy layers that recreate auth and tool orchestration.
  • Loose, ungoverned API exposure through generic middleware.
  • Manual duplication of business logic outside the platform.

That is why Salesforce positions Hosted MCP Servers as a universal connector model. One org-side configuration can support multiple MCP-compatible clients, and the security context still stays aligned to the authenticated Salesforce user.

Why hosted MCP servers matter

The key architectural value is that Salesforce hosts the server layer itself. According to Salesforce's best-practice guidance, the hosted model handles authentication, authorization, and observability for you. That matters because the moment a team builds its own proxy around Salesforce APIs, it starts re-implementing security and telemetry in a place that is usually weaker than the platform it is trying to protect.

From an enterprise point of view, Hosted MCP Servers matter for four reasons:

  • Security alignment: every tool call runs as the authenticated user.
  • Operational simplicity: admins enable servers instead of engineering teams building separate integrations for each AI tool.
  • Reusability: existing Flows, Apex actions, Aura-enabled methods, Apex REST, prompts, and product APIs can be surfaced instead of rebuilt.
  • Governance: teams can start read-only, then add write or custom actions as confidence grows.

Feature map

Hosted MCP Servers are broader than simple record access. They cover standard CRM data operations, custom business logic, product APIs, analytics, and prompt assets. The cleanest way to understand the scope is to separate standard servers from custom servers.

Capability What it exposes Where it fits best
SObject Reads Read-only access, query, search, schema discovery, relationship traversal Low-risk copilots, account research, reporting summaries, read-only assistants
SObject Mutations Create and update operations without delete Record maintenance, guided agent actions, enrichment workflows
SObject Deletes Delete operations only Highly controlled cleanup workflows for trusted personas
SObject All Full CRUD, query, and search Broad operational agents where governance is already mature
Custom Servers Persona-specific bundles of standard tools plus custom tools under one server URL Enterprise deployment, least-privilege design, cleaner tool selection by AI clients
Invocable Apex Actions @InvocableMethod business logic exposed as MCP tools Complex orchestration, validation, callouts, multi-step server-side logic
Flows Autolaunched Flow automation exposed as MCP tools Admin-owned business automation, approval routing, record creation patterns
@AuraEnabled Methods Existing Lightning controller methods surfaced as tools Reusing logic already built for LWC or Aura-backed experiences
Apex REST Custom @RestResource endpoints mapped as tools Existing platform APIs that already model a business capability well
API Catalog Curated Salesforce REST and Connect API endpoints exposed without writing connector code Billing, CPQ, Field Service, and other product APIs beyond basic SObjects
Named Queries Tightly scoped data-returning tools with explicit field and object control Safer data retrieval when generic object access is too broad
Prompt Builder Templates Prompt Builder prompts surfaced as MCP prompts Standardized briefings, summaries, reconciliation prompts, curated prompt operations
Data 360 SQL access to unified Data 360 data Customer 360 analysis, segmentation, engagement insight, unified profile exploration
Tableau Next Semantic models, dashboards, KPIs, visual metadata, and analytics Q&A Governed analytics assistants, KPI explanations, natural-language business questions
Important design point: the standard servers are useful, but custom servers are the real enterprise lever. They let you compose the exact tool set for a specific persona instead of exposing a giant generic surface area.

Use cases

Hosted MCP Servers become valuable when an AI client needs grounded access to Salesforce data or logic, but you still want the interaction to respect the platform's existing security model. Some of the strongest use cases are below.

Sales assistance

  • Read account, opportunity, and contact context before meetings.
  • Generate executive briefings using Prompt Builder templates.
  • Update next steps, create tasks, or log meeting notes through Flow or mutation tools.

Service and case operations

  • Summarize open cases and related customer history.
  • Trigger escalation flows or Apex actions.
  • Use product-specific APIs for service scheduling or downstream processes.

Analytics and business questions

  • Ask KPI questions against Tableau Next semantic models.
  • Query unified customer data in Data 360.
  • Explain what a metric means instead of just returning a number.

Operational automation

  • Run admin-maintained autolaunched flows for repeatable business steps.
  • Invoke Apex actions for complex validations or external callouts.
  • Use Named Queries for tightly scoped data retrieval patterns.

A good mental model is this: read-only assistants start with SObject Reads; guided copilots add Flow, Prompt Builder, or Named Query tools; and transactional agents add mutation or custom business actions only after governance is mature.

How admins can use it

Admins are central to Hosted MCP Server adoption because the feature is disabled by default and the first layer of control sits in Salesforce Setup. The admin responsibilities are not just technical enablement. They include scoping, persona design, and risk management.

1. Set up the org-side foundation

  • Create an External Client App. Salesforce explicitly requires External Client Apps for MCP connectivity; Connected Apps are not supported.
  • Configure the callback URL for the chosen client such as Claude, ChatGPT, Cursor, or Postman.
  • Grant the required OAuth scopes such as mcp_api and refresh_token.
  • Enable security settings like PKCE and JWT-based tokens for named users.
  • For scratch-org testing, remember that External Client Apps cannot be created directly in the scratch org Setup UI. Salesforce documents a package-from-dev-hub approach instead.

2. Activate only the servers you need

  • From Setup, enable the required MCP servers.
  • Start with read-only servers wherever possible.
  • Avoid enabling broad delete or full CRUD capabilities until there is a clear operational need.

3. Curate persona-specific custom servers

  • Create a sales-rep server, support-agent server, analyst server, or data-steward server instead of one giant generic server.
  • Combine only the tools a persona realistically needs.
  • Write tool names and descriptions clearly so AI clients can choose the right tool more reliably.

4. Test before broad rollout

  • Salesforce recommends Postman as a good first test client because it shows raw tool behavior without LLM interpretation.
  • Validate authentication, tool inputs, tool outputs, and permission behavior before handing the connection to business users.
Admin recommendation: do not think only in terms of "can the client connect?" Think in terms of "what exact tool plate should this persona receive?" That is the difference between a demo and a production design.

How developers can use it

For developers, Hosted MCP Servers are interesting because they create a low-friction path for turning existing Salesforce logic into AI-consumable tools. You do not need to build an entire agent framework inside Salesforce to participate.

Reuse existing business logic

  • Expose @InvocableMethod Apex for multi-step business actions.
  • Surface existing @AuraEnabled controller methods where that logic is already stable and useful.
  • Map existing Apex REST endpoints when the operation already has a strong API shape.

Choose the right implementation model

  • Use Flow when admins own the process and it changes frequently.
  • Use Invocable Apex when the action requires orchestration, branching, callouts, or complex validation.
  • Use API Catalog when Salesforce already has a suitable endpoint and you do not need custom code.

Developers should also treat MCP tool design as an API design discipline. A tool is not useful just because it exists. It must have:

  • Clear input and output shapes.
  • A narrow and well-described responsibility.
  • Predictable side effects.
  • Good naming so the AI client can pick it confidently.

Salesforce also recommends setting tool annotations thoughtfully for custom tools. Hints such as readOnlyHint, destructiveHint, and idempotentHint help well-behaved clients decide when a tool can run automatically and when they should require confirmation.

A few practical examples of where developers can add value quickly:

  • Create an invocable action that performs quote validation, pricing checks, and approval routing in one server-side action.
  • Expose an autolaunched flow that creates a case playbook from a template and sends notifications.
  • Publish a Named Query for a tightly scoped "account health summary" tool rather than allowing broad object exploration.
  • Map product APIs from API Catalog for Billing, CPQ, Field Service, or other specialized capabilities that should not be recreated in custom code.

Rollout guidance

If I were introducing this capability in a real enterprise org, I would avoid the temptation to begin with the most powerful server. A safer rollout model is:

  1. Start with SObject Reads for one low-risk persona.
  2. Add one or two custom read or guided-action tools such as a Flow, prompt template, or Named Query.
  3. Test with Postman first, then with the target AI client.
  4. Review where the AI client struggles with tool selection and tighten tool descriptions or scope.
  5. Add mutation capabilities only when the operational controls and human review path are clear.

This approach aligns well with Salesforce's own guidance around least privilege and server curation. It also reduces the common early mistake of exposing too many tools at once, which usually makes the AI client less reliable rather than more capable.

Recommendation

Salesforce Hosted MCP Servers are one of the most important platform moves for teams that want external AI clients to operate against Salesforce in a governed way. The real value is not the protocol by itself. The value is that Salesforce gives you a standard connection model, per-user authorization, reusable platform assets, and a path to persona-based tool curation.

Admins should treat Hosted MCP Servers as a governed access product, not just an integration toggle. Developers should treat MCP tools as well-designed business APIs for AI clients, not just as code exposure. Teams that follow that model will get much better outcomes than teams that simply turn on full CRUD and hope the client behaves well.

References