Within about eighteen months, MCP went from a protocol nobody had heard of to something every outbound vendor announces. Salesforge has one. Lemlist has one and a CLI. Saleshandy has one. So does Outboundry.
Announcing an MCP server is easy. Building one that is safe to point at a live sales account is not, and the difference is almost entirely invisible from a feature page.
Here is what to actually check.
The questions that matter
1. How are permissions scoped?
The most important question, and the one most comparisons skip.
An MCP connection grants an AI assistant the ability to act on your account. The relevant detail is how finely you can limit what it may do.
Good: distinct scopes you approve individually (read leads, create campaigns, send messages, access the inbox) so you can grant read-only access while you learn what the assistant does with an instruction.
Poor: one permission covering everything, or an API key with full account access and no scope concept at all.
Ask: can I connect with read access only, and add send permissions later? If the answer is no, you are choosing between full trust on day one and not using it.
2. Is the connection scoped to a workspace?
Critical for agencies and anyone with client separation.
If one authorisation covers your whole account, an assistant working on Client A can act on Client B. If each connection is bound to a single workspace, it cannot.
Ask: does one connection cover everything, or one workspace?
3. OAuth or API key?
OAuth means the assistant never holds a credential, access is revocable in one click, and permissions are explicit at authorisation.
API keys are simpler and worse: a long-lived string with whatever permissions it was issued, frequently pasted into a config file.
Both have their place, key-based access matters for clients that do not support OAuth, but OAuth should be the default path, not the fallback.
4. Can you see and revoke what is connected?
A connection list showing which tool is connected, to which workspace, who authorised it, when it last ran and how many requests it has made.
Without this, you have granted access you cannot audit. On a team, somebody will connect something and forget, and in six months nobody will know what is talking to your account.
Ask: where do I see active connections, and how do I revoke one?
5. What can it actually do?
Now the feature question, and it is less important than the four above.
Useful shape: read leads and campaigns, run searches, score against an ICP, create and modify campaigns, read and draft inbox replies, pull analytics.
Worth noting: read-only MCP servers are common and much less useful. If the assistant can query but not act, you have a reporting interface rather than an operating one. That is worth something, just considerably less than it sounds.
6. Which clients does it support?
Claude, ChatGPT, Cursor, Claude Code, VS Code are the usual set. Most servers work with most clients because it is a protocol, but OAuth support varies by client and some vendors only document one.
7. What happens when it does not know what to do?
The same question that matters for any AI feature. Does the assistant ask before acting on something ambiguous, or does it pick an interpretation?
This is partly a function of the client rather than the server, but a well-designed server helps by returning clear errors and requiring explicit parameters rather than guessing.
8. Does the pricing change?
Some vendors meter MCP usage, some include it, some put it behind a higher tier. Lemlist lists MCP and CLI on its Email plan; Salesforge lists MCP and CLI on Growth rather than Pro.
Ask whether MCP calls consume the same credits as in-app actions, and whether it is tier-gated.
The comparison table nobody publishes
| Check | Why it matters |
|---|---|
| Granular scopes | Grant read-only first, add send later |
| Per-workspace binding | Agency client separation |
| OAuth as default | No long-lived credentials |
| Visible connection list | Auditable access |
| Write actions, not just read | Operating vs reporting |
| Multiple clients | Not locked to one assistant |
| Clear error returns | Fewer confident wrong actions |
| Pricing and tier | MCP behind a paywall is a different product |
Three of those eight are about permissions. That ratio reflects where the real differences are.
What a good first week looks like
Regardless of vendor, the sensible rollout:
Days 1–3: read-only. Grant the minimum scope. Ask it questions, campaign performance, lead counts, reply summaries. Learn how it interprets your phrasing.
Days 4–7: write, low stakes. Add campaign creation. Build lists and draft sequences, but do not enrol anyone or send anything.
Week 2: send, supervised. Add send permissions and ask explicitly for drafts rather than sends. Read what it produces.
Week 3 onward: promote specific task types to autonomous as you see them handled correctly.
The pattern mirrors reply agent guardrails, for the same reason: the cost of a mistake rises sharply once real prospects are involved.
Where MCP genuinely changes things
Worth being specific rather than enthusiastic.
Multi-step work collapses. “Find 50 fintech CFOs in the Netherlands, score them, enrol the ones above 70” is fifteen minutes of clicking or one sentence.
Software gets used more fully. Most teams use a fraction of their platform because the rest is behind menus nobody explored.
Reporting becomes conversational. “Which segment produced the most meetings last quarter, by channel” is a question rather than a dashboard-building exercise.
And what it does not change: judgement. The assistant will build any list you describe, including a bad one. What agentic outbound means covers the boundary.
The honest state of the category
Most sales MCP servers right now are thin. A handful of read endpoints, an API key, no workspace scoping, announced because the category expects it.
That will change, and the ones worth evaluating are the ones treating permissions as a product decision rather than a configuration detail. When you are granting an AI the ability to email your prospects, the scope model is the product.
The short version
Every outbound vendor has an MCP server now, and the feature lists look similar. The differences are in permissions: granular scopes you approve individually, binding to one workspace rather than the whole account, OAuth as the default, and a connection list you can audit and revoke from.
Check whether it can write or only read, a read-only server is a reporting interface, not an operating one.
Then roll out slowly: read-only for three days, write without sending for a week, supervised sending after that.
And remember the scope model is the product. Everything else is a feature list.
Next: connecting Outboundry to your assistant, or what agentic outbound actually means.
Frequently asked questions
What should you look for in a sales MCP server?
Granular permission scopes you approve individually, connections bound to a single workspace rather than the whole account, OAuth rather than API keys as the default, and a visible connection list you can audit and revoke from.
Are read-only MCP servers useful?
Somewhat. They give you conversational reporting, which has value, but they cannot build lists, create campaigns or draft replies. That is a reporting interface rather than an operating one.
Is it safe to connect an AI assistant to a sales account?
It depends on the scope model. Grant read-only access first, add write permissions once you have seen how the assistant interprets your instructions, and add send permissions last.
Do MCP calls cost extra?
It varies. Some vendors include MCP, some meter it like in-app actions, and some gate it behind a higher tier. Ask whether it consumes the same credits and which plan it requires.