How to Build an MCP Server for Salesforce

Salesforce is the system agents ask for first: sales, service, and success agents all need accounts, contacts, opportunities, and cases. It is also where a careless integration does the most damage, because opportunity data drives revenue reporting and customer records drive everything else. This playbook builds a thin, permissioned MCP server over the Salesforce API, from tool design to production. It applies the general method in how to build an MCP server and the controls in MCP security risks; the agent that will use it is described in how to build a Salesforce AI agent.

Step 1: What do agents need, rather than what Salesforce has?

List the agent tasks first: qualify an inbound lead, summarize an account before a call, log a meeting, create a case, check open cases for a customer, update a next step. Each task implies a small number of tools. Resist exposing every object and field; a server with eight precise tools is safer, faster, and easier to test than one with a generic query tool.

Agent task	Tools	Classification
Account summary	get_account, list_account_contacts, list_open_opportunities, list_open_cases	Read
Lead qualification	find_leads, get_lead, update_lead_qualification_fields	Read; reversible write
Meeting logging	log_activity, create_task	Reversible write
Case handling	create_case, add_case_comment, update_case_status	Reversible; status change gated for closure
Pipeline update	update_opportunity_next_step, update_opportunity_stage	Reversible; stage change consequential

Step 2: How should authentication and delegation work?

Salesforce enforces sharing rules and field-level security per user. To keep that enforcement, every tool call should carry the requesting user's context through OAuth, with the server holding its own integration identity for authentication to Salesforce. The effective permission is then the intersection of what the agent's role allows and what the user can see and do in Salesforce. A single integration user with broad permissions for all agents is the most common mistake in Salesforce integrations and defeats both Salesforce's model and your audit trail. The delegation pattern is described in the agent identity and access control whitepaper.

Step 3: Write precise schemas

Each tool gets a JSON schema with enumerated fields. update_opportunity_stage takes an opportunity identifier and a stage from the org's actual stage list; it does not take a free-form field map. Field lists in read tools are explicit, so the server never returns fields the agent's task does not need. Validation runs in the server: identifiers checked for format, enumerations enforced, string lengths limited, and dates parsed. Errors are returned in a consistent shape the model can act on.

Step 4: Implement thin tools over the REST API

The server translates tool calls into Salesforce REST API requests and shapes responses for the model: summarize where a raw object is large, include only requested fields, and label any free-text fields (notes, descriptions, email bodies) as untrusted content, because they can carry injected instructions. Business rules such as stage progression validation stay in Salesforce; the server does not reimplement them. Prefer targeted queries over broad ones and batch where the API allows it.

Step 5: Classify and permission every tool

Class	Tools	Principal	Gate
Read	Account, contact, opportunity, case reads	Read scope, user-delegated	None
Reversible write	Activity logging, tasks, case comments, next-step updates	Write scope on those objects, user-delegated	Sampling
Consequential write	Stage and amount changes, ownership, closure, deletion	Separate scope, withheld from most agents	Human approval at the gateway

Consequential tools exist as separate tools so they can be withheld from agents that do not need them. Design guidance is in how to design tool permissions for AI agents.

Step 6: How do you handle API limits?

Salesforce orgs have daily API request allocations. Cache reference data such as picklist values and stage lists; batch reads where possible; enforce per-agent rate limits and step budgets at the gateway; and monitor consumption against the org limit with alerts well before it is reached. A runaway agent must not be able to exhaust the org's quota for every other integration.

Step 7: Test against a sandbox

• Contract tests for every tool: valid input accepted, invalid rejected, response shape as declared.
• Permission tests: a user without access to a record cannot read it through the server.
• Abuse cases for writes: wrong identifiers, out-of-range values, repeated calls (idempotency).
• Injection tests: a case description containing instructions does not cause a consequential action without approval.
• End-state verification: after create_case, the case exists with the expected fields and nothing else changed.

Run these in CI against a Salesforce sandbox; never test against production. The evaluation discipline is described in AI regression testing.

Step 8: Publish and operate

Register the server with its owner, tools, classifications, and permitted agents; route it through the gateway; enable logging with the agent identity, delegated user, tool, and record identifiers; and set up monitoring on error rate, latency, and API consumption. Assign an on-call owner in the team that owns Salesforce. Version the server and pin the protocol libraries; Salesforce API versions change on their own schedule and the server's adapter should be tested against each.

Step 9: Roll out by agent

Connect the first agent with read tools only, instrument usage, then enable reversible writes with sampling, and finally consequential writes behind approval gates for agents whose specifications require them. Retire any bespoke Salesforce integrations as agents migrate, so the registry becomes the complete inventory.

What are the common mistakes?

1. One integration user for everything, bypassing Salesforce's security model.
2. A generic SOQL tool that cannot be permissioned.
3. Untrusted free text passed as instructions.
4. Testing against production.
5. Ignoring API limits until another integration fails.
6. Business rules reimplemented in the server.

How does FISTA Solutions help?

FISTA Solutions is an official Anthropic partner and builds Salesforce MCP servers and the agents that use them as part of its AI agents and AI enablement practices, with forward deployed engineers working alongside your Salesforce administrators on tool design, delegation, and permissions. FISTA has delivered 150+ projects for 50+ companies across 12+ countries.

To build your Salesforce server with us, message FISTA on WhatsApp, or read how to build a HubSpot AI agent for the equivalent on another CRM.