Custom MCP Servers

Salesforce ships various standard MCP servers bundling out-of-box capabilities oriented around discrete product areas. To combine MCP tools from different servers to accomplish broader workflows, administrators can create and curate custom MCP servers. Combining the tools needed by a given persona into a single server URL also simplifies interactions with MCP clients, since MCP clients would only need a single URL representing all the tools across Salesforce.

Additionally, custom servers provide a means to surface custom tools backed by your own Apex code, Flows, or APIs, since standard servers are immutable.

MCP clients have practical limits on how many tools they can work with effectively. Beyond a few dozen tools, an AI client struggles to select the right one for a given task. You can't serve every dish from the buffet on a single plate — it doesn't fit, and it's not useful.

Curating focused, persona-specific servers produces better agent behavior and aligns with how Salesforce already works: admins compose Lightning pages from multiple sources — tabs, components, contributed by different teams and ISVs — to give a sales rep or marketer the specific experience they need. Custom MCP servers work the same way for AI-assisted workflows.

Think of every available MCP tool across the Salesforce platform as a buffet. Salesforce product teams contribute standard tools to that buffet — SObject access, Data 360 queries, Tableau analytics, and more. Internal developers and ISVs add their own dishes: custom Apex Actions, Flows, and REST APIs.

An MCP Server is the plate curated for a given persona. When an admin configures a custom server in Setup, they're choosing what to put on that plate — picking from everything available on the buffet and composing it into a focused set of tools for a specific team or agent workflow.

One team might get a plate with read-only CRM tools and nothing else. Another gets write access plus a custom Flow for a more powerful workflow agent. Same buffet, different plates.

This separation is what makes the model flexible: contributors (Salesforce, ISVs, internal developers) don't need to know how and when customers will use their tools, and customers don't need to build from scratch. They assemble from what's available.

Standard servers are pre-configured by Salesforce. They expose a fixed set of tools from a single product area — for example, the SObject servers expose platform record operations, and the Data 360 server exposes SQL queries. Standard servers are disabled by default and can be enabled by an admin, but their contents are not editable.

Custom servers are admin-configured. They can:

  • Combine tools from multiple standard servers under a single URL — for example, pairing SObject read tools with a Tableau Next analytics tool for a reporting persona
  • Include custom tools backed by Apex Invocable Actions, @AuraEnabled methods, Apex REST endpoints, Flows, or API Catalog endpoints unique to your org
  • Be scoped to a specific persona — a sales rep server, a support agent server, a data hygiene server — each with a different mix of capabilities
  • Be deployed via Metadata API between sandboxes and production.

The URL for a custom server is unique to that configuration, so different teams can be pointed at different servers with different tool sets — without requiring multiple OAuth apps or separate Salesforce orgs.

Custom servers are the only way to surface tools that don't exist in any standard server. These tools are backed by logic you've already built in Salesforce:

Autolaunched Flows can be exposed as MCP tools. Reuse declarative automation you've already built in Flow Builder — multi-step processes, conditional branching, callouts to external systems — without writing integration code. See Flows for configuration requirements.

Apex classes annotated with @InvocableMethod become custom tools. Use these for business logic that goes beyond what Flows can express: complex calculations, custom integrations, or performance-sensitive operations. See Invocable Actions for requirements. Learn more about @InvocableMethod.

Apex methods annotated with @AuraEnabled can be exposed as custom tools. If your org already uses these methods as Lightning component controllers, they can also serve as agent-accessible tools with no additional code. Learn more about @AuraEnabled.

Custom Apex REST endpoints (classes annotated with @RestResource) can be mapped as custom tools. Use these when you have existing custom REST APIs on the platform that agents should be able to invoke. Learn more about Apex REST.

REST API endpoints registered in the Salesforce API Catalog can be mapped to custom tools, including standard platform APIs and a growing subset of product-specific Connect APIs. Not all Connect API endpoints are in the catalog at GA — coverage is expanding over time. Learn more about Connect REST API. See API Catalog.

Custom servers are configured in Salesforce Setup: Integration → Salesforce MCP Servers. No code is required to configure the server itself. For step-by-step instructions, refer to the section of Help & Training that covers custom server configuration through the API Catalog.

The tool name and description you provide for each custom tool are as important as the backing implementation. Clear, specific descriptions help AI clients select the right tool at the right time. See Best Practices for guidance on writing effective tool descriptions.

Sales rep server — Combine SObject read/write tools with a custom Flow that logs meeting notes as Activities, and an Apex Action that enriches a Lead from an external data source.

Data hygiene server — Combine SObject query tools (to identify duplicates) with delete tools (to remove them) and a Flow that runs deduplication logic. Point this server at a dedicated user profile that only data stewards can authenticate as.

Reporting server — Combine soqlQuery from the SObject reads server with Tableau Next analytics tools and a Data 360 SQL tool. Give this plate to reporting personas who need broad read access but no write operations.

ISV managed packages cannot yet include MCP server configurations directly. However, ISVs can make their capabilities available for MCP by including Apex classes annotated with @InvocableMethod, @AuraEnabled, or @RestResource, or by including Autolaunched Flows in their package. Once installed, a subscriber administrator can configure a custom server in their org and add those packaged actions as tools.

This means ISVs designing new capabilities should consider adding these Apex annotations to their code and ensuring Flows are Autolaunched — these patterns expose the capability to MCP without requiring any additional integration surface.