What a custom MCP server does for your Salesforce data

AI assistants are only useful to a business when they can work with the business's own information. A general assistant can draft and summarise. It becomes valuable when it can look up an account, read the open cases and prepare the next step. That raises a question every leadership team should ask early: by what route does an AI assistant reach our customer data, and who controls that route?

A custom MCP server is one answer. This article explains what it is, why an organisation would want one in front of Salesforce, and what to decide before building it.

What the protocol is

The Model Context Protocol, or MCP, is an open standard for connecting AI assistants to tools and data. It defines a common way for an assistant to discover what a system offers and to ask that system to do something.

An MCP server is the piece that sits in front of a system and describes what is on offer: information the assistant may read and actions it may request. The assistant can use only what the server exposes. A custom server is one built for your organisation, so the list of what is exposed, and to whom, is yours to set.

For an executive, the useful comparison is a service counter. The assistant does not walk through the warehouse. It asks at the counter, and the counter decides what it may have.

Why put one in front of your customer data

Without a deliberate design, access tends to grow by accident. One team connects an assistant to a report export. Another builds a small integration for a single task. Each has its own credentials, its own rules and its own gaps. Nobody can state with confidence what AI tools can see.

A custom server replaces that with one governed route. Three things follow.

• Controlled scope. The assistant can reach the records and actions you have chosen, and nothing else.
• Permission-aware access. The server can be designed so that a request made on behalf of a person is limited to what that person is allowed to see and do.
• One place to govern. Rules, logging and changes are managed once, not separately in every integration.

Because the standard is open, the same server can serve more than one assistant. The investment is in the governed route, not in a single tool.

The question is not whether AI assistants will reach your customer data. It is whether they do so by a route you designed.

What to decide before building

The build is the smaller part of the work. The decisions come first.

1. Which data to expose. Start from a use case, not from the full data model. Name the objects and fields the task requires and leave the rest out.
2. Which actions to allow. Reading is lower risk than writing. Decide which updates an assistant may make directly, which need a person to confirm, and which stay out of scope.
3. Whose permissions apply. Decide whether the assistant acts with the permissions of the person using it or with those of a dedicated service identity, and why.
4. What is recorded. Agree what is logged for each request: who asked, what was read or changed, and when. Decide who reviews the log.
5. Who owns it. A named business owner for what is exposed, and a technical owner for how it runs. Changes to scope should need both.

Risks, and how to bound them

The risks are real and manageable. Each has a practical limit.

Exposing too much. A broad first version is the main danger. Keep the initial scope narrow and extend it on evidence.

Unintended actions. An assistant may request an action the user did not mean. Require confirmation for anything costly or hard to reverse, and keep bulk changes out of reach.

Misleading content. Text held in records can contain instructions that an assistant may follow as if they came from the user. Treat record content as data, not as direction, limit what a single request can do, and test for this before launch.

Drift. Scope grows one request at a time. A regular review of what is exposed, against what is used, keeps it in check.

How to tell whether it is working

A server that runs is not the same as one that delivers. We suggest measures in three groups.

• Use. How many people use assistants through it, for which tasks, and how often.
• Outcome. The business measure the use case was chosen for, such as time to prepare for a meeting or time to resolve a case, compared with a baseline taken beforehand.
• Control. Requests refused, actions confirmed or rejected by people, and exceptions found in log reviews. A control that never triggers deserves a second look.

It is also worth counting the ad hoc integrations retired. If the governed route is working, there should be fewer of the others.

We design and build custom MCP servers on this basis: the use case and the measure first, then the narrowest scope that serves them.