MCP servers for sales:
what they can do as you.

What an MCP server actually is

An MCP server is a program that publishes a list of tools an assistant can call, plus the schema for calling each one. Model Context Protocol is the open standard Anthropic published on 25 November 2024. A sales MCP server publishes sales tools: search a database, read a CRM record, send a message.

That is the whole idea. The assistant asks the server "what can you do", gets back a list of named tools with typed inputs, and calls the ones it judges relevant. Nobody writes an integration per assistant, and nobody pastes CSVs between windows.

The protocol has moved quickly. Version identifiers are dates, and the current revision is 2026-07-28 (Model Context Protocol specification, versioning page, checked August 2026). If a comparison post you are reading describes the protocol as if it were still 2025, that is a useful signal about the rest of its facts.

Why sales is the hard case for MCP

Most MCP servers read. Sales servers act, and the act is public. A bad search costs nothing. A connection request sent to the wrong person is visible to that person, counts against a weekly ceiling you cannot raise, and cannot be unseen. That asymmetry, not tool count, should decide what you connect.

This is why the sales category diverges from the developer category. A file-system server that reads the wrong directory produces a wasted turn. A sequencing server that enrolls the wrong 200 people produces 200 real emails, a spike in complaints, and a domain reputation problem that takes weeks to unwind.

The specification is unusually direct about this. In the tools section it says that for trust and safety "there SHOULD always be a human in the loop with the ability to deny tool invocations", and asks applications to "present confirmation prompts to the user for operations". That sentence is doing more work in sales than in any other category, and not one of the ranked comparison pages quotes it.

What a sales MCP server actually exposes

Sales MCP servers expose tools in three tiers: reads that cost nothing, writes that change your own records, and outreach actions that change someone else's inbox. Almost every vendor comparison ranks servers by tool count. The tier a tool sits in matters more, because it decides what an approval step is for.

Read that table as a permissions design rather than a feature list. The first five rows are where an agent earns its keep and where mistakes are free. The last three are where an agent needs a person, every time, because there is no undo that reaches the other side.

The drafting row is the interesting one. It is a write, so it changes state, but the state it changes is yours. A server that can draft and cannot send gives you almost all of the leverage with none of the blast radius, which is why it belongs in the middle tier and why it is the right default posture for any assistant you have not yet learned to trust.

How to tell a read from an irreversible action before you connect

Every MCP tool can carry annotations that describe its behavior: readOnlyHint, destructiveHint, idempotentHint and openWorldHint. The defaults are pessimistic on purpose. A tool with no annotations is treated as one that writes, destroys, is not repeatable and reaches an open world. Read the defaults before you trust a manifest.

Those defaults are from the protocol schema for revision 2026-07-28. They mean that an unannotated tool is, by the protocol's own reckoning, a destructive open-world write. Vendors who have done the work annotate. Vendors who shipped an MCP wrapper over their REST API in an afternoon usually have not, and their manifest reads as maximally dangerous whether or not it is.

Then comes the catch, in the specification's own words: "For trust & safety and security, clients MUST consider tool annotations to be untrusted unless they come from trusted servers." The annotations are the server's self-description. A hostile or compromised server can label a send tool read-only. Annotations are a good filter, not a guarantee, and they are worth exactly as much as your trust in the publisher.

Practically, this means the check is: open the server's published tool list, sort it by tier using the table above, and confirm that the tools which act on the outside world are the ones you expected. If a server will not show you its tool list before you authorize it, that is your answer.

The security question: what the agent is allowed to do as you

An MCP grant is a standing permission. The right question is not whether the server is trustworthy but what the token can do, who it acts as, and what happens when a tool description or a returned record contains instructions. The specification and Microsoft's June 2026 guidance answer all three the same way: constrain the action, not just the identity.

Who the agent acts as. A server that connects with one shared service account gives every user of the assistant the union of everyone's permissions. A server that authorizes per user, and scopes the grant to that user's own entitlements, gives you an audit trail and a revocation story. Ask which one you are getting, because it decides what happens when someone leaves.

How wide the token is. The specification's security guidance names scope inflation as its own attack: a broad token means a "stolen broad token enables unrelated tool/resource access", and revoking it "disrupts all workflows". It asks for a minimal initial scope and incremental elevation when a privileged operation is first attempted. In sales terms, a connector that reads your CRM should not also hold your send permission by default.

Token passthrough. The same document is blunt about the anti-pattern where a server accepts a token it was not issued and forwards it downstream: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server." The reason matters to you even if the plumbing does not. When tokens are passed through, the downstream system's rate limits, request validation and audit logs stop reflecting who actually did the thing.

Instructions hidden in data. This is the one that catches sales teams, because sales tools return text written by strangers. Microsoft's security team put the mechanism plainly on 30 June 2026: "The MCP blends instructions (tool descriptions) with data, so a change to a tool's metadata can redirect the agent's behavior." Their guidance is to treat MCP servers as production dependencies, treat tool descriptions as system prompts, and apply "least agency, not just least privilege".

Least agency is the right frame for sales specifically. Your agent does not need the ability to send in order to be useful at finding, researching and drafting. Every one of those is a read or a private write. Handing over the send permission buys you a small amount of convenience, and it is the one permission a prospect can see you got wrong the moment it fires.

Put the idea to work

Less searching.
More conversations.

Tell Vera who you want to reach. Review the first message. Take it from there.

Ask Vera to find leads

What the comparison posts get wrong

The popular roundups agree on structure and disagree on facts. On the single most consequential question, whether a server can write, they contradict each other and the vendor's own documentation. Two of the pages ranking in August 2026 call the HubSpot MCP server read-only. HubSpot's developer documentation says otherwise.

Specifically: Crustdata's roundup (3 August 2026) describes the HubSpot MCP server as offering "read-only access" with write capabilities planned, and Merge's overview lists it as read-only. HubSpot's own MCP page, checked in October 2026, documents read and write access across CRM objects (contacts, companies, deals, tickets, products, line items, quotes in beta and more) plus engagements such as calls, emails, meetings, notes and tasks, and now also landing pages, blog posts, campaigns and marketing email drafts, with user and account data read-only. It also documents OAuth with PKCE, scopes set by the server's tools and what each user grants at install, and actions limited to that user's existing HubSpot permissions.

One of those is right. The point is not to score a vendor, it is that the capability that determines your blast radius was stale or wrong on widely read pages, and no reader could tell without going to the source. Three rules follow.

Check capability at the vendor's docs, never at a listicle. Server capabilities in this category changed materially inside a single quarter. A roundup is a starting index, not a fact.

Distrust tool counts as a ranking signal. Roundups routinely lead with how many tools a server exposes, and some of the largest advertise well over a hundred. A large tool list burns context before your first question and makes tool selection harder, which several of the same posts admit further down when they advise connecting two or three servers at most. Coverage of the job you actually do beats raw count.

Ask what the server does when it cannot do something. A server that returns a clear typed error lets the model recover. A server that returns a wall of raw API JSON poisons the rest of the conversation. This never appears in the comparisons and it is the difference between a connector you keep and one you disable in week two.

What this looks like for LinkedIn outreach

LinkedIn is the sharpest version of the problem, because the account doing the sending is a person and the platform limits are real. BeReach's connector exposes 27 tools to Claude, ChatGPT or any MCP client. Ten are read-only. Five are marked as hard to reverse, and every one of those five touches an invitation, a message, or the send schedule.

The split is deliberate and maps onto the tiers above. Finding people, reading profiles and companies, pulling the engagement on a post, checking contacts and workspace state: all reads, and a bad one costs nothing but a wasted call. Drafting a message: a private write, visible only to you until you choose to send it. Sending an invitation, sending a message, scheduling or approving a batch: the five, each one a real action taken as you.

Permissions are scoped to one chosen account per workspace, never a shared login across users, the same distinction the security section above draws between per-user authorization and a pooled service account. It is least agency expressed as product design rather than as a policy document. The mechanics of the connector are covered in LinkedIn MCP server for Claude.

Approval is not decoration here. Every message is approved by a human before it goes out, which is the same control the specification asks for and the same one Microsoft's action-guardrail layer describes. If you want the argument for why the assistant should stop at the draft rather than the send, Claude for sales walks through where the model's judgment ends.

Server-side pacing is the second half of it, because an agent that can send is an agent that can send too fast. Invitations are paced rather than capped, at least 3 minutes apart, with LinkedIn's weekly limit as the stop, and profile visits never exceed 120 per hour, a ceiling no plan lifts. Profile visits and messages start at 300 and 70 per day respectively at base, scaled by a workspace multiplier, so those two are floors of a policy rather than fixed numbers. That is how sending is paced. The pacing runs on the server, which means it applies to a tool call from an assistant exactly as it applies to a click in the app.

And keeping a person in front of the send is not just about pacing. Across 48 workspaces and 42,236 connections, BeReach's own 2026 study found a mean response rate of 15.7% but a median of 4.5%, with 68.3% of responses being explicit disinterest. Volume without judgment is not a strategy, it is a slower way to get ignored. The full distribution is in what teams actually get from LinkedIn outreach.

A sales MCP stack you can defend

Connect the fewest servers that cover the job, grant the narrowest account each one needs, and put a human approval in front of anything that leaves your systems. Everything else is tuning. The list below is the order that survives an audit, and it takes about twenty minutes to work through.

Before you authorize anything:

1. Write down the job. "Research 20 accounts and draft first touches" is a job. "Sales" is not. The job tells you which two servers you need.
2. Read the manifest before you authorize. Sort the tool list into read, write and outreach. If anything in the outreach tier surprises you, stop.
3. Start read-only. Run the workflow for a week with no send permission granted. Most of the value shows up here, and you learn where the model is weak while the cost of being wrong is zero.
4. Grant per user, never per company. One shared service account means one revocation problem and no audit trail.

Once it is running:

5. Keep approval on every outbound action. Batch approval of drafts is fine. Unattended sending is not, and the specification agrees.
6. Add the third server only when the first two are boring. Every extra server spends context and makes tool selection worse before it makes anything better.
7. Re-check capabilities quarterly. This category changed materially in a single quarter, and your risk model is built on last quarter's manifest.

If you want to try the read tier first, the free LinkedIn people search runs the same public lookups the read-only tools call, right in your browser.

Frequently asked questions