What is MCP, and why does it matter for sales tools?

The Model Context Protocol (MCP) is an open standard for connecting AI apps such as Claude and ChatGPT to outside tools and data. Model Context Protocol for sales means one AI assistant can read your CRM, find a call transcript, or ask your phone system to place a call through one standard connection, while each tool keeps control of what it allows.

MCP in plain words

The MCP documentation compares it to a USB-C port: one standard plug between AI apps and the systems they work with. Anthropic introduced MCP on 25 Nov 2024 to replace one-off integrations, where every new data source needed its own custom connection (Anthropic). On 9 Dec 2025, Anthropic donated MCP to the Agentic AI Foundation, a fund under the Linux Foundation co-founded with Block and OpenAI. At that point it counted more than 10,000 active public MCP servers, and named ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code among the products that support MCP (Anthropic).

The architecture overview uses a few terms that are worth learning once:

Term	What it is	Sales example
Host	The AI app a person uses	A rep’s AI assistant
Client	The connection the host opens to one server; one client per server	The assistant’s link to the CRM
Server	A program that offers context and actions to clients	A CRM’s or a phone system’s MCP server
Tool	An action the model can call	Log a call, book a callback, place a call
Resource	Data the app can read for context	An account record, a call transcript
Prompt	A reusable template	“Prepare a brief before this call”

Servers can run on the same computer as the app, or remotely over HTTP. For remote servers, MCP recommends OAuth to get sign-in tokens. As of October 2026, the current version of the specification is dated 28 Jul 2026.

What MCP changes for CRMs and phone tools

Before MCP, each AI app needed its own integration with each sales tool. With MCP, a CRM or a phone system publishes one server, and any app that supports MCP can use it. The app asks the server which tools it has (tools/list), the model picks one based on its description, and the app calls it (tools/call).

For a sales team, the useful jobs fall into a few groups, and they do not carry the same risk:

Job	Example tools	Risk	Who should approve
Prepare	Read the account, earlier calls and open deals	Low: read-only	No one, if access matches the user’s own
Log	Write the call outcome and next step to the CRM	Medium: changes records	The rep, before it is saved
Schedule	Book a callback or a follow-up task	Medium	The rep, or a rule that keeps it inside calling hours
Act	Place a call, or add contacts to a call list	High: reaches a person	A person on your team, every time or above a set size

The gain is less switching between tools. A rep can ask for a brief before a block of calls, and the assistant pulls the account, the last conversation and the open opportunity from two servers. The risk is that a model is now one tool call away from writing to your CRM or ringing a customer’s phone.

What MCP does not do on its own

MCP defines how apps and servers talk. It does not decide what an agent is allowed to do, and the protocol documents say it does not dictate how AI apps use language models. Nothing in MCP knows your calling hours, your do-not-call list or a contact’s consent. Those rules have to live in the server that does the work.

The tools specification sets a baseline:

• There should always be a human in the loop who can deny a tool call. Apps should show which tools the model can use, show when a tool runs, and ask for confirmation.
• Servers must validate every input, enforce access controls, rate-limit tool calls and clean up their outputs.
• Clients should confirm sensitive operations with the user, show the inputs before calling, set timeouts, and log tool use for audit.
• Annotations that describe how a tool behaves are untrusted unless they come from a server you trust.

For the full set of rules a calling agent needs, see guardrails for AI agents that place phone calls. For logging outcomes, see how AI agents can log calls in your CRM.

Questions to ask before you connect a sales tool

1. How do agents sign in? Prefer OAuth scoped to one workspace and one user over shared API keys pasted into a prompt.
2. Which tools are exposed? Start with read-only tools. Add write tools one at a time.
3. What needs a person’s approval? At least calls placed by an agent and bulk changes to lists.
4. Which rules does the server enforce? Calling hours in the contact’s time zone, your do-not-call list, and consent, checked by the server on every request.
5. What is logged? Every action should name the agent, the person who connected it, and anyone who approved.
6. How is untrusted text handled? Transcripts and emails can contain instructions. The server should mark them as content, not commands.

If the agent’s call uses an AI voice, consent comes first. Since FCC 24-17 (Feb 2024), the FCC treats AI-generated voices as artificial voices under the TCPA, so these calls need the person’s prior express consent, and prior express written consent for telemarketing (FCC 24-17). Reps make cold calls; AI agents call people who agreed to it. See AI voice agent consent rules.

How DialSavvy handles this

The DialSavvy MCP server is coming to the Command plan and Enterprise. As planned on the MCP page, it will let agents in Claude, ChatGPT, Agentforce or your own code place calls, read outcomes and fetch transcripts, with OAuth sign-in scoped to one workspace. Every request will get the same checks as a rep’s call, and AI calls and bulk adds will wait for a person on your team. Tool names may change before launch. Live today: webhooks on every plan, and compliance checks before every rep call, for calling hours in the contact’s time zone and your do-not-call list.

Pick one read-only job, such as a pre-call brief from your CRM, and try it with one rep before you connect any tool that writes or dials. To talk through agent access to your phone lines, book a demo.