TL;DR: The Model Context Protocol (MCP) is an open standard that lets an AI agent call the tools of another product, such as your outbound platform, through one shared menu of actions. The menu decides what the agent can do, so the person who controls the menu controls the risk. Learn to read that menu before you let any agent near a live campaign.
#What you will learn
- The one-sentence answer
- Why sales teams suddenly hear about MCP
- The menu analogy
- What happens during one MCP request
- Tools, resources and prompts
- What MCP looks like in an outbound platform
- MCP, a CLI and an API compared
- What MCP does not do
- Five questions to ask before you connect an agent
- How to try MCP safely this week
- Frequently asked questions
- Conclusion
#The one-sentence answer
The Model Context Protocol (MCP) is an open standard that gives AI applications one common way to connect to outside systems, so a single agent can read and act inside many products without a custom build for each.
Anthropic introduced it on November 25, 2024, describing it as "a new standard for connecting AI assistants to the systems where data lives". The official documentation compares it to a USB-C port for AI applications.
That comparison is accurate and still too vague for a sales leader. A USB-C port tells you the plug fits. It does not tell you what the device on the other end is allowed to do once it is plugged in.
This post fills that gap. You will learn how MCP works in terms a revenue team can use, what it can and cannot do inside an outbound stack, and which questions to ask before an agent gets a connection to your campaigns.
Our angle is narrow on purpose. We treat MCP as a menu of actions and argue that the menu, not the model, is where outbound risk lives.
#Why sales teams suddenly hear about MCP
A year ago MCP was a developer topic. Today it appears in vendor pitches, in your RevOps lead's Slack, and in demos where someone types a sentence and a campaign report appears.
The adoption numbers explain the noise. In December 2025 the protocol's lead maintainer, David Soria Parra, wrote that MCP had passed 97 million monthly SDK downloads and 10,000 active servers, with first-class client support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and Visual Studio Code.
The same post announced that Anthropic was donating MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. The Anthropic announcement lists Google, Microsoft, Amazon Web Services, Cloudflare and Bloomberg as supporters.
"The Linux Foundation provides a neutral home and infrastructure that allows maintainers to operate independently, and will not dictate the technical direction of MCP."
David Soria Parra, Lead Maintainer, Model Context Protocol, December 9, 2025 (source)
For a sales team the practical meaning is simple. The protocol will not vanish when one vendor changes strategy, and the tools you connect today will probably still speak the same language next year.
That stability is also why the risk deserves attention now. A standard that works everywhere lets an agent reach everything you connect, and outbound is a field where one wrong action reaches thousands of inboxes.
If you are still deciding how much autonomy an agent should have at all, read our comparison of AI-assisted and autonomous outbound first. MCP does not answer that question. It only decides how the agent plugs in.
#The menu analogy: who writes, orders and approves
Picture a restaurant. The kitchen can cook hundreds of things, but the diner can only order what is printed on the menu.
In MCP the server is the kitchen, the client is the diner's table, and the tool list is the menu. The AI model is the diner who reads the menu and decides what to order.
Three people matter in that picture. The vendor writes the menu, your admin decides which menu you receive, and the model chooses items from it during a conversation.
The vendor decides what exists. A good vendor prints dishes such as "show campaign progress" and leaves off dishes such as "delete every contact".
Your admin decides what you can see. In a well-built system the menu is different for each tenant and each grant, so a junior marketer's agent and an owner's agent do not see the same list.
The model decides what to order, and this is the part people fear. The model reads the menu text, reads your request, and picks the item that seems to fit.
That last step is why the wording of the menu matters. A tool described as "pause all sending" will be used when the model thinks you want sending paused.
Here is the first rule worth tattooing on your process: the menu is the permission system. If an action is not on the menu, the agent cannot take it, however clever the prompt.
Compare that with giving an agent a login to your app. A login exposes every button. A menu exposes only the buttons someone chose to print.
This is why the guide for which tools an agent should get is the most practical companion to this explainer. It sorts a typical outbound menu into tiers by blast radius.
#What happens during one MCP request
You do not need to read the specification, but one walkthrough makes the whole idea concrete. Suppose you type "How is the Q4 founders campaign doing?" into Claude Code.
First, your client connects to the server at start-up and asks for the tool list. The server answers with a list of tool names, plain-English descriptions and the fields each tool accepts.
Second, the model reads that list alongside your question. It sees a tool for campaign progress and a tool for campaign analytics, and it picks one.
Third, the client asks you for permission to call the tool, depending on your settings. Claude Code, for example, asks the first time a server's tool is called and labels the call with the server name, which is how you confirm the answer came from the connected product and not from the model's memory.
Fourth, the server runs the request using your identity and returns the data. The model then writes the answer in ordinary language.
sequenceDiagram participant You as You participant Client as AI client participant Model as AI model participant Server as MCP server You->>Client: Ask about a campaign Client->>Server: Request the tool list Server-->>Client: Tool names and descriptions Client->>Model: Question plus tool list Model-->>Client: Choose a tool and fill in fields Client->>You: Ask permission to call it You-->>Client: Approve Client->>Server: Call the tool Server-->>Client: Data from your account Client->>Model: Result Model-->>You: Answer in plain language
Notice where each decision sits. The vendor controlled the list, you controlled the approval, and the model controlled only the choice among approved options.
The protocol also lets a server announce that its tool list changed. Claude Code supports these list_changed notifications and refreshes a server's tools automatically when one arrives.
That convenience has a cost we cover in our post on MCP security for outbound. A menu that can change while you work is a menu you need to watch.
#Tools, resources and prompts: the three things a server offers
An MCP server can offer three kinds of things, and sales readers meet them in this order of frequency.
A tool is an action. "Get campaign analytics" and "add a domain to the blocked list" are tools, and the model decides when to call them.
A resource is read-only context that the client can load, such as a document or a record. Think of it as a page the diner is allowed to look at.
A prompt is a saved instruction template that the server offers, such as a weekly report outline. You pick it, the way you would pick a macro in a spreadsheet.
Most outbound conversations only involve tools. That is where the money and the risk sit.
Tools also come in two flavors that matter more than any technical detail. Some only read, and some write.
A read tool cannot damage anything. The worst outcome is that the model misreads the numbers and gives you a wrong summary, which you can check.
A write tool changes state. It might edit a sequence step, add a contact to a list or block a domain, and a wrong call changes what real prospects receive.
The protocol lets servers describe a tool's behavior with hints, for example whether it is read-only or destructive. Treat those hints as labels written by the vendor, not as guarantees enforced by the protocol.
So the first skill a sales leader needs is sorting a vendor's tool list into read and write. The second skill is asking what each write tool can touch.
#What MCP looks like in an outbound platform
Abstract talk only goes so far, so here is a concrete case. FirstSales exposes a product MCP server over streamable HTTP at https://api.app.firstsales.io/mcp.
Access uses OAuth with PKCE, which means you sign in as yourself and approve the connection. The package that ships with the FirstSales CLI states that Developer API keys and dashboard cookies are not accepted by the product MCP server.
The tool list is per tenant and per grant. We confirmed the following tools in one connected session on October 8, 2026, and your list may differ, so the live tools/list response is always the authority.
| Job | Tools seen in the session | Type |
|---|---|---|
| See campaigns | campaigns_list, campaigns_get | Read |
| Watch performance | campaign_analytics_get, campaign_progress_get, campaign_events_list | Read |
| Read sequence steps | campaign_workflow_get | Read |
| Edit sequence steps | campaign_workflow_update | Write |
| Look up accounts | companies_list, companies_get, deals_list, deals_get, pipelines_get, activities_list | Read |
| Check the team | team_members_list | Read |
| Check credits | billing_credit_balance_get, billing_credit_history_list, billing_usage_get | Read |
| Add people | contacts_create, list_membership_update | Write |
| Protect the list | blocked_domains_list, blocked_domains_add | Read, write |
Two things stand out. Most of the menu reads, and the writes are narrow.
The second thing is an omission. We did not confirm any tool that creates a campaign through MCP, and we do not claim one exists.
If you want a campaign, you create it with the command line using firstsales campaigns create, then use MCP to edit its steps and watch its numbers. The walkthroughs in our setup guide for Claude Code show that split in practice.
The shipped product skill also tells agents to switch to the CLI or the Developer API when a desired action is mutating, destructive, billing-related or approval-backed, instead of assuming MCP supports it. That instruction is a good template for your own team policy.
Notice what is missing from the list above: nothing sends an email by itself. The sending engine, the schedule and the safety checks live in the platform, and the agent works on the instructions that feed them.
That design choice matters for deliverability. Google asks bulk senders to keep their user-reported spam rate below 0.1% and never reach 0.3%, and an agent with a "send now" button can burn through that margin in an afternoon.
#MCP, a CLI and an API compared
Sales teams usually meet three ways to let software act on their behalf. Each suits a different job, and mixing them up causes most early mistakes.
An API is the raw contract between systems. It is the most flexible and the least forgiving, and it needs a developer.
A command-line interface (CLI) wraps the API in commands you type or an agent runs in a terminal. It offers guardrails such as dry runs and confirmation flags.
MCP wraps a chosen slice of actions into a menu an AI model can discover on its own. It trades breadth for guidance.
| Question | API | CLI | MCP |
|---|---|---|---|
| Who uses it? | Developers | Operators and coding agents | AI assistants |
| Does the agent discover actions itself? | ✗ | ✗ | ✓ |
| Works in scripts and cron jobs? | ✓ | ✓ | ✗ |
| Built-in confirmation for destructive steps? | ✗ | ✓ | Depends on the client |
| Menu can differ per user? | ✓ | ✓ | ✓ |
| Can create a campaign on FirstSales? | ✓ | ✓ | ✗ |
| Best first use | Custom builds | Setup, imports, launches | Reading, watching, editing |
The FirstSales CLI, installed with npm i -g @firstsales.io/cli, offers a --dry-run preview and a --confirm guard for destructive commands such as contacts delete. Its README states that destructive commands stop unless --confirm is present.
That guard is one reason we point beginners to the CLI for risky steps and to MCP for conversation. Our post on which interface fits which job goes deeper.
Teams that live in a terminal will also like the pattern in running outbound from the terminal. It treats the CLI as the stable base and MCP as the chat layer on top.
#What MCP does not do
Hype around the protocol hides several limits. Knowing them saves you a bad purchase decision.
MCP does not make an agent smarter. The model's judgment is unchanged, and a model that writes weak emails will write weak emails with better data.
MCP does not enforce your policy. If the menu contains a tool that edits live sequence steps, the protocol will happily let a confused model call it.
MCP does not authenticate people by itself. The server has to check who is asking, and that is why the OAuth grant matters.
MCP does not stop prompt injection. OWASP lists Excessive Agency as a top risk for language model applications and traces it to excessive functionality, excessive permissions or excessive autonomy, whatever triggers the bad output.
Independent developer and writer Simon Willison named the sharpest version of this danger in June 2025.
"If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker."
Simon Willison, "The lethal trifecta for AI agents," June 16, 2025 (source)
His three features are access to private data, exposure to untrusted content and the ability to communicate externally. An outbound agent that reads inbound replies, holds your prospect list and can send email touches all three.
You do not need to abandon agents because of that. You need a menu that keeps the three apart, which is the theme of our guide to guardrails for email-sending agents.
Finally, MCP does not replace your deliverability work. The SPF, DKIM and DMARC setup still has to be right, and the warm-up still has to happen, no matter how tidy the chat window looks.
#Five questions to ask before you connect an agent
Use these questions in a vendor call or an internal review. Each one maps to a failure we see in the field and in the research.
1. Can I see the full tool list before I connect? The answer should be yes, and the list should come from the live server, not a marketing page. In the FirstSales package the live tools/list call is named as the authority.
2. Which tools write, and what exactly can each write touch? "Update workflow" is a broad phrase. Ask whether it edits one step or the whole sequence, and whether it can touch a running campaign.
3. How does the menu change, and who tells me? A server can change its tool descriptions after you approve it. Invariant Labs documented this as an MCP rug pull, where a server changes a tool description after the client has already approved it.
4. What identity does the agent act as? The best answer is "you, with your permissions, through OAuth." The weakest answer is a shared admin key pasted into a config file.
5. Where is the audit trail? After a mistake you need to know which tool was called, when, with which fields. If the vendor cannot show that, treat every write as unreviewable.
Add a sixth question for your own team: who is allowed to connect an agent in the first place? Treat it like handing out a company card.
If the list of questions feels long, remember the cost side. The FTC's CAN-SPAM guide notes that each separate email in violation is subject to penalties of up to $53,088, and the law makes no exception for business-to-business email.
A bad agent action is rarely one email. It is usually a batch, so the arithmetic escalates quickly.
For the legal side of that exposure, our explainer on whether cold email is legal in 2026 is the place to start.
#How to try MCP safely this week
You can learn more in one hour with a real connection than in a week of reading. Follow a sequence that starts with reading and earns trust before it allows writing.
First, pick a workspace that does not hold your best list. A small test workspace is ideal, and a paused campaign inside it is better.
Second, install the CLI and verify who you are. The package's recommended agent loop starts with firstsales whoami --json, followed by reading state, planning the smallest mutation, and verifying the result afterward.
Third, run firstsales doctor --pretty to check the setup, then connect the MCP server in your client and read the tool list out loud with a colleague. Ask the agent to list the tools it sees, and compare that against what you expected.
Fourth, ask read-only questions for a few days. Request campaign progress, recent events and analytics, and verify two or three numbers against the app by eye.
Fifth, allow one narrow write. Editing a draft step in a paused campaign is a good first one, because the change cannot reach a prospect until you start the campaign.
Sixth, before you ever start a live campaign, run the readiness and test-send checks. The product's safety lines are plain: run campaigns readiness and campaigns send-test-email before campaigns start.
Two more habits are non-negotiable. Never paste an API key into a prompt, because a prompt is stored, logged and shown to the model.
Create keys with api-keys create and the least access that does the job, and remember that delete commands such as contacts delete cannot be undone.
For the full pre-launch routine, see our walkthrough of the campaign readiness check and the guide to sending a test email from Claude Code first.
#Where MCP fits in the bigger stack
MCP sits in the middle of an outbound system. Data and knowledge feed the agent from below, and sending infrastructure carries the result out from above.
We describe that arrangement as five layers in the five layers of an AI outbound agent stack. MCP belongs to the tools layer, and it shares that layer with the CLI and the API.
Seeing it that way prevents a common purchasing error. Buyers ask which model is best and forget to ask which tools the model gets.
It also explains why tool count matters. Anthropic's engineering team reported that tool definitions can be heavy, noting that 50-plus MCP tools consumed about 72,000 tokens before any work began, and that tool definitions had reached 134,000 tokens at Anthropic before optimization.
A bigger menu is not a better menu. Our post on why 100 MCP tools make an agent worse lays out the evidence and the fix.
The practical conclusion for a sales team is to connect fewer things, with narrower grants, and to keep a human at the points where an action cannot be undone.
If you want the human-review side of that conversation, the posts on human-in-the-loop cold email and unsupervised AI outbound show where teams place those checkpoints.
#Reading a tool description like a buyer
Every tool on a menu has a short description, and that text is read by the model, not by you. Learning to read it is the cheapest security skill a sales leader can pick up.
A good description says what the tool does, what it needs and what it returns. "Returns the open, reply and bounce counts for one campaign over a date range" is a good description.
A weak description is vague or promotional. "Manages your campaigns intelligently" tells the model nothing, and it invites the model to guess.
Check three things in each description. Does it name the object it touches, does it name the limits, and does it say whether it changes anything.
Then check the field names. A tool that accepts a free-text field the model can fill with anything deserves more suspicion than a tool that accepts a campaign ID and a date.
The OWASP MCP security cheat sheet recommends treating the entire tool schema as a potential injection surface, not only the description field.
For a non-technical reader the translation is easy. Ask your admin or vendor to export the tool list and read it like a contract, line by line.
Keep the export. A saved copy lets you compare next month's list against this month's, which is the simplest defense against a silent change.
#A week-one plan for a small outbound team
This is an illustration, not a customer story. It shows how a team of three might sequence the steps above, and the days are a suggestion you can compress or stretch.
On day one, the admin connects the MCP server to a test workspace and exports the tool list. Everyone on the team reads it together and marks each tool read or write.
On day two, each person asks five read-only questions about a paused or finished campaign. The goal is to learn what a good answer looks like, and to spot the first wrong one.
On day three, the team compares three numbers from the agent with the same numbers in the app. If they match, trust grows a little. If they do not, the team writes down why before moving on.
On day four, one person edits a single step in a paused campaign through the agent. A second person reviews the change in the app before anything is started.
On day five, the team runs the readiness check and sends a test email to an inbox they own. They only discuss starting the campaign after both pass.
Then they write a one-page policy. It names who can connect agents, which tools are allowed, which actions always go through the CLI, and who approves a start.
That policy is the real deliverable of week one. The agent is replaceable, but the habits are not.
#Plain-language glossary
Keep this list for the next time a vendor uses a word you do not recognize.
Agent: software that uses a language model to decide which steps to take toward a goal. Anthropic describes agents as systems where the model directs its own process and tool usage.
Client: the app you chat with, which connects to MCP servers on your behalf.
Server: the program in front of a product that publishes its tools to clients.
Tool: one action on the menu, with a name, a description and a set of fields.
Grant: the permission you give when you approve a connection. On FirstSales the tool list depends on the grant.
OAuth: the sign-in flow where you approve access without sharing a password. The product MCP server uses it with PKCE.
Dry run: a preview of a command that makes no change. The CLI offers --dry-run, which prints the method, URL and redacted headers without a network call.
Prompt injection: hidden instructions inside content the model reads, such as an email reply, that try to steer it.
Rug pull: a server changing a tool after you approved it.
With those terms you can follow almost any MCP conversation. You can also ask sharper questions than most buyers do.
#Frequently asked questions
#What is MCP in simple terms?
MCP is an open standard that lets an AI assistant connect to another product through a menu of actions. The assistant reads the menu, picks an action and the product carries it out.
#Who created MCP?
Anthropic created it, and the company says it was built by David Soria Parra and Justin Spahr-Summers. Anthropic open-sourced the protocol on November 25, 2024.
#Who governs MCP today?
Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation in December 2025. The maintainers who stewarded it before the move still make the technical decisions.
#Is MCP only for developers?
No. Developers build the servers, but sales and revenue teams use them through chat clients. You need to understand the menu and the permissions, not the code.
#What does MCP stand for?
It stands for Model Context Protocol. The name refers to giving a model the context and tools it needs from outside systems.
#Is MCP the same as an API?
No. An API is the raw contract between systems, while MCP packages a chosen set of actions into a menu that an AI model can discover and call on its own.
#What is an MCP server?
An MCP server is a program that exposes a product's actions and data to AI clients. In outbound, the server sits in front of your platform and decides what an agent can see and change.
#What is an MCP client?
The client is the AI application you talk to, such as Claude Code. It connects to servers, shows the model their tools and asks you to approve calls.
#What is a tool in MCP?
A tool is a single action a server offers, such as getting campaign analytics. The model decides when to call it based on the tool's description and your request.
#Can MCP send emails by itself?
That depends on the tools a vendor chooses to publish. On FirstSales the tools we confirmed read data or edit steps, and none of them is a send button.
#Can MCP create a campaign on FirstSales?
We did not confirm a tool that creates a campaign through MCP. Create campaigns with firstsales campaigns create, then use MCP to edit and watch them.
#Is MCP safe for outbound sales?
It is as safe as the menu and the approvals around it. Keep write tools narrow, require approval for them, and keep a human at every irreversible step.
#What is the biggest MCP risk for a sales team?
The biggest risk is excessive agency: an agent with too many tools, too many permissions or too much autonomy. OWASP names those three as the root causes of that vulnerability.
#What is a rug pull in MCP?
A rug pull is when a server changes a tool's description after you approved it. Invariant Labs described it as a way to change agent behavior without any new approval.
#How do I see which tools an MCP server offers?
Your client shows the list when you connect, and the server returns it from a tools/list call. For FirstSales, that live response is the authority for your tenant and grant.
#Do I need Claude Code to use MCP?
No. Many clients support MCP, including ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and Visual Studio Code according to the MCP maintainers. This series uses Claude Code for its examples.
#How is MCP access authenticated on FirstSales?
It uses OAuth with PKCE, so you sign in and approve the connection. The shipped skill states that Developer API keys and dashboard cookies are not accepted by the product MCP server.
#Does MCP replace the CLI?
No. The CLI suits setup, imports, launches and scripts, and it has built-in guards like --dry-run and --confirm. MCP suits reading, watching and editing through conversation.
#How many MCP tools should one agent get?
Fewer than you think. Anthropic reports that tool definitions can consume tens of thousands of tokens and that selection accuracy drops as libraries grow, so grant only what a job needs.
#Where should a sales team start with MCP?
Start with read-only questions in a test workspace. Add one narrow write in a paused campaign, and run campaigns readiness and campaigns send-test-email before any campaigns start.
#Conclusion
MCP gives an AI agent one standard way to reach your outbound platform, and the tool list is the permission system. Whoever writes, approves and watches that list decides how much damage a confused or manipulated agent can do.
Remember five points. The menu is the permission system, reads are cheap and writes are expensive, tool lists can change after approval, fewer tools make better agents, and no protocol removes the need for a human at irreversible steps.
Your next step is concrete. Install the CLI, connect a test workspace, read the live tool list with a colleague, and sort every tool into read or write before you ask the agent for anything.
When you are ready to go further, start with which tools an agent should get, then read MCP security for outbound. If you want to see the platform behind the menu, explore how FirstSales runs AI-assisted outbound with human review.