MCP for sales: connect your pipeline to AI tools

MCP, the Model Context Protocol, is an open standard that lets AI applications such as Claude Code and Cursor call tools in another service. For sales, it means asking your assistant to find accounts, review drafts and report results straight from your pipeline. It is safe only when the server enforces the rules itself: keys scoped to the job, approval kept separate from sending, and every send checked on the server, whatever the assistant asks for.

Sales work is spread across tabs: the prospect list, the inbox, the drafts, the calendar, the report you owe on Monday. MCP promises to put all of it behind one conversation. That is genuinely useful. It also hands an AI model the keys to a system that holds personal data and can send email, which is exactly the combination security researchers warn about.

This guide explains what MCP is in plain terms, what it changes for sales work, where the risks are, and how to connect a sales system to Claude Code or Cursor without giving away more than you mean to. We use Snaut's own MCP server as the worked example, including what it does not support yet.

What MCP is, in plain terms

Anthropic open-sourced the Model Context Protocol in November 2024, describing it as a new standard for connecting AI assistants to the systems where data lives. The problem it set out to solve was integration sprawl: every new data source required its own custom connector for every AI application.

The specification defines three roles. A host is the AI application you use, such as Claude Code or Cursor. A client is the connector inside the host. A server is the service that provides data and capabilities. They talk using JSON-RPC 2.0 messages. A server can offer three kinds of things:

The practical result is that any MCP host can use any MCP server. A sales system that exposes an MCP server becomes usable from whichever assistant you already work in, without a custom plugin for each.

The rights a sales system has to grant

MCP defines four primitives, and the split matters when you decide what an assistant may touch. Tools execute; resources supply context; prompts are templates a person invokes. A sales server that mixes all three carelessly gives an assistant more reach than any of the workflows above need.

MCP's documentation is explicit about that split: tools are model-controlled, resources are application-driven and give passive read-only access, and prompts are user-controlled, requiring explicit invocation rather than automatic triggering. The practical rule that follows is simple to state and easy to break: reading must never be able to cause a send. If an assistant can fetch a prospect's website as context and also hold a key with send rights, then a page containing instructions is one hop away from your outbox. That is the whole of the lethal trifecta in one sentence, and separating the primitives is how it is avoided in practice.

There is a second, quieter reason to keep resources read-only. Because the model chooses its tools and cannot choose which resources exist, an attacker who can manipulate a model gains the ability to call tools, not the ability to conjure context the application never offered. Fewer choices for the model is not a limitation of the design. It is the design.

What MCP changes for sales work

The value is not that an assistant can click buttons for you. It is that questions which used to need several tools and a spreadsheet become one request, answered from the source of truth rather than from a stale export:

For a founder or a small team, this matters because the assistant is already open all day. The pipeline stops being one more place to check and becomes something you can ask about in the middle of other work.

Why sales teams ask for this

The push for MCP in sales tools comes from a pattern of work rather than a fondness for protocols. A founder or a solo consultant does not spend an hour inside a pipeline tool. They spend the day in a browser, a document and a chat window, and the pipeline is something they check in the gaps. Every tool that requires switching to it competes with everything else open on the screen.

A protocol that lets the existing window ask the pipeline a question removes a step. The same argument applies inside larger teams, where an engineer may want to ask about a prospect without being given a seat in the sales tool, and a founder may want the weekly numbers without opening a dashboard. The value is not automation. It is access, in the place where the question already occurs.

The second reason is that MCP standardizes a job every integration used to redo. Before it, connecting an assistant to a sales system meant a bespoke plugin per assistant, each with its own authentication, its own idea of permissions and its own bugs. Anthropic, which introduced the protocol, describes it as an open standard that replaces fragmented integrations with a single protocol servers can implement once. Whether that holds depends on hosts adopting it consistently, which is no longer in doubt for the three covered below.

What has not changed is the harder half of the job. A connected assistant can query your pipeline faster, but it cannot decide who is worth contacting, or whether a claim is true, or when a message should go out. Those are the parts that determine whether outreach works, and they live in the product, not in the protocol. Connecting a vague process to an assistant produces faster vague outreach.

The risk: a sales agent has all three ingredients

In June 2025 the developer Simon Willison described what he called the lethal trifecta for AI agents: access to private data, exposure to untrusted content, and the ability to communicate externally. His warning is direct:

If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker.

A sales agent combines all three by design. It holds private data: your pipeline, your contacts, your notes. It reads untrusted content: prospects' websites, job posts and, above all, inbound replies, which anyone can write. And it can communicate externally, because sending email is the point. Willison names MCP specifically, because it encourages people to mix tools from different sources, and he gives the example of an assistant with email access: an attacker can simply email the model and tell it what to do.

He is equally blunt about the fix: there is no reliable filter. He notes that guardrail products claiming to catch 95% of attacks would be a failing grade in web security, and he highlights a principle from research on securing agents: once an agent has ingested untrusted input, it must be constrained so that the input cannot trigger consequential actions. The OWASP guidance on prompt injection reaches similar conclusions: give the model the minimum privileges it needs and require a human to approve high-risk actions.

The MCP specification itself is clear that it cannot do this for you. It says the protocol enables arbitrary data access and code execution paths, that users must explicitly consent to data access and operations, and that MCP cannot enforce these principles at the protocol level. The responsibility sits with the people who build the hosts and servers, and with you when you connect them.

Six rules for connecting a sales system to an assistant

1. Scope the key to the job

A key that can read your pipeline should not automatically be able to send email. Cursor's documentation makes the same recommendation for every MCP server: use restricted API keys with minimal required permissions. If the assistant only writes your weekly report, give it a read-only key.

2. Keep approving and sending separate

An assistant that can approve a draft and send it in one step turns any mistake, or any successful injection, into an email. Two steps, each with its own permission, give you a place to stop.

3. Enforce rules on the server, not in the prompt

"Never email anyone who opted out" written in a prompt is a request. The same rule checked by the server before every send is a guarantee. A good MCP server applies the same checks whether a request comes from its own app, its API or an assistant, and refuses the request if they fail.

4. Treat outside content as data

Web pages and inbound replies should reach the model marked as untrusted, and the steps that read them should have no ability to send or change anything. That separation is what stops a malicious reply from becoming an instruction.

5. Rehearse before you act

Prefer servers that support dry runs, so the assistant can show what a call would do before it does it. Run any new workflow in a test mode before it touches real mail.

6. Log everything and keep keys revocable

Every call should leave an audit record, including the ones that were refused. Keys should be revocable instantly and shown only once at creation, so a leaked key can be killed without affecting anything else.

How Snaut's MCP server is built

Snaut's MCP server lives at https://app.trysnaut.com/mcp and uses the Streamable HTTP transport with a bearer API key. Here is how it applies the rules above, and where it falls short.

Every tool is an action from the same registry

Every capability in Snaut is defined once, as an action in a registry, and the app, the REST API and the MCP server all call the same actions. As of October 2026 there are more than 150. Because MCP tools are the same actions, an assistant cannot do anything the app could not, and nothing it does skips the checks the app applies. The server tells connecting assistants this in its instructions:

Approving a draft does not send it. send_approved and reply_to_thread never bypass the send gate, and a dry run sends nothing.

The send gate is the list of checks every email must pass, from a recently verified address and a footer with an opt-out to sending windows, volume caps and an explicit live-send setting. We describe it in our guide to cold email deliverability, and the checks on content in our article on AI sales emails that make things up.

Four scopes, granted separately

Scopes do not imply each other. A key with only the send scope cannot list drafts; it needs read as well. A call outside the key's scopes is refused with an insufficient_scope error and recorded in the audit log.

Keys you can contain

• Keys are created in Settings, under API keys, and the token is shown once. Snaut stores only a hash of it.
• Each key belongs to one workspace and cannot reach another, including other client workspaces in the same agency.
• Keys are test or live. A test key can send only through the sandbox mailbox, never through a real one.
• Each key is rate limited to 60 requests a minute, and a revoked key is rejected immediately.

Hints, dry runs and costs

Every tool carries the standard MCP hints for whether it only reads, whether it is destructive and whether it is safe to repeat, taken from the action's definition. Every tool also accepts a dry_run flag; with it set, nothing is saved or sent. Read tools cost no actions, and tools that do spend actions say so in their description. The specification warns that hosts should treat tool annotations as untrusted unless they come from a trusted server, which is one more reason the server, not the hint, is what enforces the rules.

Prompts and resources

The server also offers ready-made prompts and read-only resources:

Three resources are available to read: brain://workspace holds your offer, proof and constraints; agent://me holds your agent, its memory and your action balance; and play://{id} holds one play, including its autonomy and volume settings.

Fewer tools, less risk

More than 150 tools is a lot for a model to choose from. Adding ?tools= to the server address with a comma-separated list of tool names exposes only those tools. A reporting setup might expose only get_stats, list_replies and get_credit_balance, which keeps the model focused and limits what a confused or manipulated assistant could even attempt.

Connect Claude Code

Claude Code adds remote servers with its mcp add command. Its documentation recommends the HTTP transport and notes that the SSE transport is deprecated. Create a key in Snaut, put it in an environment variable, and run:

export SNAUT_API_KEY="sk_live_..."

claude mcp add --transport http snaut https://app.trysnaut.com/mcp \
  --header "Authorization: Bearer $SNAUT_API_KEY"

Your shell expands the variable when you run the command, so the key is written into your local Claude Code configuration. That is fine for the default local scope, which stays private to you. To share the setup with a team, use a project-scoped .mcp.json instead. Claude Code expands environment variables in remote server URLs and headers, so the file can be committed while each person keeps the key in their own environment:

{
  "mcpServers": {
    "snaut": {
      "type": "http",
      "url": "https://app.trysnaut.com/mcp",
      "headers": {
        "Authorization": "Bearer ${SNAUT_API_KEY}"
      }
    }
  }
}

Claude Code asks for approval before using project-scoped servers from .mcp.json in interactive sessions, and its documentation adds a warning worth repeating: verify you trust each server before connecting it, because servers that fetch external content can expose you to prompt injection.

Connect Cursor

Cursor reads MCP servers from a file named mcp.json: ~/.cursor/mcp.json for every project, or .cursor/mcp.json inside one project. It resolves environment variables written as ${env:NAME} in a remote server's url and headers, so the key can stay out of the file:

{
  "mcpServers": {
    "snaut": {
      "url": "https://app.trysnaut.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:SNAUT_API_KEY}"
      }
    }
  }
}

By default, Cursor asks for approval before it uses an MCP tool and lets you inspect the arguments first. For tools that send or approve, keep it that way.

ChatGPT and other assistants

ChatGPT is not supported today. OpenAI's documentation says that for an authenticated MCP server, you are expected to implement an OAuth 2.1 flow that conforms to the MCP authorization specification. Snaut's server authenticates with API keys and does not offer OAuth yet, so we do not support connecting it to ChatGPT. We will say so on this page when that changes.

Other assistants may be able to connect if they support remote Streamable HTTP servers with a custom authorization header. We document Claude Code and Cursor because their setup is described in their own documentation, linked in the sources below.

Five workflows worth starting with

1. Morning review. Run the review-drafts prompt with a key that has read and send. Read each draft with its sources, approve the ones you would sign, and send only when you say so.
2. Weekly report. Use a read-only key filtered to get_stats, list_replies and get_credit_balance, and run the daily-report prompt on Monday.
3. Market analysis. Run analyze-my-market with your website, then pick the segment you want; the assistant opens a draft play and stops.
4. Finding customers. Run find-customers with one buyer sentence and review the companies, signals and dates before anything is drafted.
5. Debugging a blocked email. Ask why a draft cannot send; check_send lists each rule and whether it passed.

Notice that none of these give the assistant a path from reading untrusted content to sending mail without you in between. That is deliberate. What the agent does on its own, without you or an assistant asking, is set separately by each play's autonomy level in the app, and every send still passes the same gate. We explain how to choose a level of autonomy in our buyer's guide to AI SDRs.

What not to do

• Do not give an admin key to a general-purpose assistant. Nothing in daily sales work needs it.
• Do not connect a sales server with send rights alongside another server that reads your email or the web, unless you understand the combination. That is the lethal trifecta assembled by hand.
• Do not commit keys to a repository. Use environment variables as shown above.
• Do not set your assistant to run send or approve tools without asking. Approval prompts are a feature.
• Do not use a live key to test a workflow. Test keys exist so that experiments go to the sandbox mailbox.
• Do not expose every tool when you need three. Use the tools filter.

Honest limits

MCP is young, and so is our server. Authentication is by API key only; OAuth is not available yet, which is also why ChatGPT cannot connect. The tool set is large, so filtering matters. The protocol itself is still evolving, and hosts differ in which features they support. And no server design removes the underlying risk Willison describes when you combine your own tools freely; it can only make sure that its own part of the chain refuses unsafe actions.

What MCP does not change is the job itself. An assistant connected to your pipeline still needs a clear profile of who to contact and why, which we cover in how to define an ideal customer profile an agent can use, and the loop from finding a company to an approved draft is described in how an AI agent finds customers.

Server behavior, scopes, limits and prompt names describe Snaut's production MCP server as of October 2026. Client setup follows the Claude Code and Cursor documentation as of the same date; check their pages for changes.