Questions teams actually ask
Collected from security reviews, RevOps evaluations, and the first week of rollouts. Ordered roughly by how early they come up.
Is MCP a Claude feature or an open standard?
Open standard. Anthropic published it and Claude was the first widely used client, but the protocol is not Claude-specific and other clients implement it. A server you write for Claude works elsewhere without changes.
Practically, this means you are not choosing a vendor when you connect a server. You are choosing an interface.
Does connecting our CRM mean the model can delete records?
Only if the credential you issue allows it. MCP does not add permissions. It passes through whatever the token or OAuth grant carries, so a read-only integration user stays read-only.
The recommended sequence is read-only for two weeks, then write to notes and activities, then write to fields. Most teams never need the third step.
Where does our data go?
To the model, in the same way a pasted document does. The tool result becomes part of the conversation. The difference from pasting is auditability: the server logs what was requested and by whom, which is the part a security review actually cares about.
For a local stdio server, nothing leaves your machine except what the model reads in the response. For a hosted server, standard vendor data handling applies and should be reviewed like any other integration.
How many servers should one rep have attached?
Two to four. Beyond that, tool selection degrades: the model has more descriptions competing for the same request and starts calling the wrong one.
If different jobs need different servers, use separate projects or sessions rather than attaching everything permanently.
What does it cost?
The protocol is free. Costs come from three places: the Claude plan, the API or seat cost of the systems you connect, and credits on any data provider you attach.
The data layer is usually the only line item that scales with usage, because enrichment and research are metered per lookup. Budget it per rep per month rather than per team.
Can we build our own server instead of connecting a vendor's?
Yes, and for internal systems you should. An MCP server over your own database or internal API is a day of work with the SDK, and nobody else will build it for you.
The calculation is different for prospect data, where the work is not the server but the data behind it. That distinction is the subject of this build-versus-buy analysis.
Our reps are not technical. Is this realistic?
For hosted servers, yes. The rep clicks a connector and completes an OAuth screen, which is the same interaction as connecting a calendar app.
Local servers with JSON config should be handled centrally, by RevOps or IT, and pushed rather than asked for. Do not send a config file to a field team.
What does MCP not fix?
Bad data, undefined qualification criteria, and a broken process. The model reads what is there. If activity logging is inconsistent, the call brief inherits the inconsistency and states it confidently.
It also does not fix judgment. Access is not strategy. A rep who could not articulate why an account is a fit will not get that from a tool call.
Where should we start?
One server, one workflow, one week. Call prep is the usual first choice because the value is immediate and nothing writes anywhere. Then add the data layer, because that is the prompt that keeps failing for lack of access.
The rollout order at org level, including who owns credentials and how to review it after 30 days, is covered in Salesgear's guide to claude mcp for sales.
Still deciding?
The cheapest way to answer most of these is to attach one read-only server and run workflow number one before your next meeting. Ten minutes of setup answers more than a week of evaluation.