MCP Is Becoming the Connection Layer for AI Agents. Sales Needs One Too.

A founder tells an AI agent: find fifty potential distributors in Germany, check which ones fit our profile, and prepare a personalized outreach campaign for the ones worth talking to.

The reasoning is not the hard part. A current model can define the target profile, argue about which segments are attractive, draft the messages, and explain its reasoning step by step.

Then it stops. It cannot look up a company. It cannot check whether the same contact was emailed last month by someone else. It cannot read the CRM, draft into the sequencing tool, schedule the follow-ups, or record what it did. Every one of those steps requires a connection the agent does not have.

So the question stops being whether the model is smart enough, and becomes a question about plumbing. How does an agent discover what a system can do? How are the parameters defined? How does it receive a result? And how does a developer avoid building a different integration for every agent against every application?

Having access to a model is not the same as having access to the business systems needed to execute a task. The gap between those two things has a name, and it is where the next layer of the agent stack is being built.

1. What Is MCP?

The Model Context Protocol (MCP) is an open protocol that standardizes how an AI application connects to external tools, data sources, and services. It was created by Anthropic and later donated to the Linux Foundation's Agentic AI Foundation, which is part of why several competing vendors now ship support for it rather than treating it as one company's preference.

The architecture has three participants, and the distinction between them matters more than it first appears. The host is the AI application itself, such as an IDE, a coding agent, or a chat client. The client is a component inside the host that holds one dedicated connection to one server. The server is the program that exposes capabilities back to the client. The rule that makes this tractable is simple: the host creates one client per server, so an editor connected to a filesystem server, an issue tracker, and an internal API is running three clients at once, each with its own boundary.

Servers expose three kinds of primitive. Tools are executable operations a model can invoke, described with a JSON Schema so the parameters are unambiguous. Resources are read-only context the server makes available, such as a record, a file, or a summary. Prompts are reusable templates a server offers for structuring an interaction. Clients discover what is on offer at runtime rather than from a hardcoded list, which is why a server can add a capability without every client shipping a release.

Underneath, the protocol is JSON-RPC 2.0 for the data layer, and a transport layer that defines how messages actually travel. There are two standard transports. stdio runs the server as a child process and talks over standard input and output, which is why local servers typically serve exactly one client. Streamable HTTP carries requests over HTTP with optional streaming for responses, and it is what makes remote and multi-user deployment practical.

Two clarifications keep this from being oversold. MCP does not make a model more intelligent; it standardizes the plumbing around one that already is. And it is not the only way to connect an agent to software. Conventional APIs, native integrations, and other protocols all remain in use, and many production systems will use more than one. The current specification, revised on 28 July 2026, also moved the protocol core to a stateless design, which mostly matters to whoever operates the server rather than to the person writing the prompt.

2. Why Standardized Connectivity Matters

The default state without a shared protocol is a matrix of custom integrations. Every agent gets a connector to every system, written once and maintained forever.

That distinction compounds quickly. A business with eight systems and three AI applications has twenty-four integrations to build, secure, document, and keep current. Every one of them is a place where a schema drifts, a permission is too broad, or an error goes unhandled. A shared protocol does not make that work disappear, but it moves it from twenty-four places to eight, and it makes each connection reusable by anything that speaks the protocol.

It also changes who can build the agent. Without a standard, only the team that controls the business systems can realistically wire an agent to them. With one, a third-party agent developer can reach the same capability without asking for a bespoke integration, which is a real change in who gets to participate.

3. Why Sales Is a Particularly Important Use Case

Sales is an unusually demanding case for connectivity because a single workflow crosses many systems, each holding a different piece of the decision. Contact records sit in one place, company information in another, sending infrastructure in a third, the CRM in a fourth, campaign analytics in a fifth, and the calendar in a sixth.

An agent doing useful work needs to answer a chain of small questions before it acts. Who is this prospect? Which company do they work for? Does the company match the profile we sell to? Has anyone already contacted them? Did the last email get a reply? What is the appropriate next action? Each answer lives somewhere, and none of them is available to a model that has connections to nothing.

The framing that matters is this: the value of connectivity is not the number of systems an agent can reach. It is whether those connections make a coherent business workflow possible. Reaching twelve systems is not an achievement if the agent cannot decide what to do with what it found. Connecting the right capabilities to the right stage of a workflow is the whole job.

4. What Could an MCP Server for Sales Expose?

A sales MCP server would expose a deliberately chosen subset of capabilities. Illustrative tools might include `search_contacts`, `get_contact_details`, `get_company_profile`, `check_contact_history`, `create_draft_email`, `create_outreach_sequence`, `schedule_follow_up`, and `get_campaign_performance`. Illustrative resources might include account context, contact history, product information, campaign summaries, playbooks, and customer interaction records.

These are examples of the shape such a server could take. They are not a description of what any particular product exposes today, and the specific names would matter less than the design question behind them.

That question is one of abstraction level, and it has no universally correct answer.

A high-level tool like `prepare_outreach` can enforce the checks that a sales team actually cares about: suppression lists, recent contact history, sending caps, approval state. Granular tools give an agent more room to be useful and more room to be wrong. What the right balance is depends on the use case, the safety requirements, and how much the business trusts the agent to act unsupervised.

5. MCP Does Not Replace Skills

This is the point most likely to be misunderstood, so it is worth stating plainly. A connection layer and a skill set solve different problems, and the layers sit at different places.

A cold outreach skill might specify that the agent should research a prospect, check contact history, decide whether outreach is appropriate, draft a relevant message, and record the activity afterwards. A sales MCP server might expose the tools needed to fetch that contact history, retrieve company information, and prepare or submit an email. The skill supplies the task-oriented procedure. The connection layer makes the relevant capabilities reachable. The business system performs the operation. Remove the skill and you have a capable agent with no idea what a good outcome looks like. Remove the connection and you have a procedure that cannot act.

It is also worth being precise about a detail that is easy to misreport: MCP does not formally define the Skills layer. The protocol's own skills extension, accepted in September 2026, deliberately acts as a transport binding and leaves the file format to the separate agentskills.io standard, so there is one definition of what a skill is and more than one way to deliver it. The previous article in this series covered that distinction in more detail: why agents need specialized skills.

6. MCP Does Not Automatically Create an Autonomous Sales Agent

Connecting an application to a sales MCP server does not produce a reliable sales agent. It produces an application that can reach some capabilities. Everything that makes the difference sits on top of that connection.

• Clear objectives, so the agent knows when the job is done
• Domain skills that encode how the work is actually done
• Reliable data, since a confident answer built on bad records is worse than no answer
• Tool descriptions written for a model to read, not for a developer to skim
• Authentication and authorization scoped to the right principal
• Execution policies that separate reading from writing from sending
• Error handling and retry that do not duplicate a send
• State management that survives the agent losing its context
• Audit logs recording who acted, when, and through which connection
• Evaluation and monitoring, so quality is measured rather than assumed
• Human approval wherever the consequence is expensive to undo

The most common confusion is between technical capability and business authorization. An agent that can call a send tool is not thereby entitled to send every email without review. In a sales context that gap matters more than in most, because the failure modes are visible to the recipient: a duplicate send, a message to someone who asked to be removed, an offer made before anyone checked whether the company already has a supplier.

The practical controls are unglamorous. Least-privilege scopes, a permission boundary that separates reading contacts from sending to them, an approval step for consequential actions, suppression and consent checks on the recipient side, and a reliable record of what was sent. None of that is provided by the protocol. All of it is required.

7. MCP vs. Traditional API Integration

Traditional APIs remain essential, and MCP does not replace the underlying API or the business logic behind it. A company will typically use an API internally and expose selected capabilities through an MCP server that sits in front. The server becomes the interface between compatible AI applications and the capabilities it chooses to publish.

The benefits of the protocol layer are real but bounded: reusable access patterns, runtime discovery, consistent shapes across systems, and a cleaner separation between agent developers and product teams. The limitations are equally real. Every server still has to be implemented, authenticated, authorized, mapped to the underlying data model, and maintained. Not every client supports the same capabilities, so behaviour varies by product and version. And compatibility does not guarantee quality: a perfectly well-connected agent can still run a campaign that makes no commercial sense.

8. What Could a SalesRuns MCP Architecture Look Like?

SalesRuns today is an AI sales execution platform covering contact management, email outreach, sales sequences, campaign operations, follow-up workflows, and sales analytics. That is the execution layer such an architecture would expose.

The strategic objective is narrow and concrete: to let an external AI agent use specialized sales capabilities without every agent developer rebuilding the same sales infrastructure. Potential capabilities along that path could include querying authorized contact data, preparing outreach drafts, inspecting campaign results, requesting a follow-up workflow, retrieving activity history, and initiating operations that have already been approved.

To be explicit: there is no production SalesRuns MCP server today and no announced direct integration with any AI agent. None of the capabilities above are shipped features. They are illustrative of the direction, and the layered diagram is a proposal rather than a description of a working stack.

The reason this direction is worth pursuing is structural rather than promotional. A general-purpose model can reason about sales indefinitely and still have nowhere to put the result. Reasoning does not provide a contact database, a sending path, workflow state, permission management, operational history, or performance feedback. Those require systems, and systems can be built once and used by many.

9. Agent-Compatible Access as a Distribution Channel

Traditionally, a user reaches a sales product by opening it, navigating its interface, and running the workflow by hand. In an agent-oriented arrangement, the user states an objective to an AI application, and that application reaches the underlying service through a compatible interface.

The defensible claim here is modest and still significant: agent-compatible access may become an additional distribution channel for business software, alongside web applications and APIs. It would not replace the interface. Most decisions in sales still need human judgment, and the dashboard remains the better place for them. What changes is that the product is no longer reachable only through its own front door.

For a vendor this is a genuine strategic question, because capability accessed through someone else's agent is a different distribution relationship than a seat. It also creates a design obligation: if a capability is going to be invoked by software rather than clicked by a person, it has to be described clearly enough to be called correctly, bounded clearly enough to be called safely, and stable enough that someone else's product does not break when it changes.

10. A Practical Sales Execution Scenario

Take the request from the opening: find fifty potential distributors in Germany and prepare a personalized outreach campaign. A workable end-to-end path looks like this.

The agent interprets the objective, a prospecting skill defines how to research and qualify, the connection layer makes company and contact data reachable, and the agent evaluates candidates against the profile. An outreach skill then prepares the message drafts. Before anything sends, the execution system checks contact history, consent and suppression lists, and sending constraints. Where approval is required, a person reviews the proposed campaign. The approved actions run, and everything is recorded so the next run knows more than this one.

Note where the judgement sits. The connection layer is plumbing. It is not the component deciding whether the campaign is commercially sound or legally permissible, and it should not be. That judgement belongs to the skills that encode the procedure and to the execution system that enforces the rules.

11. The Emerging Agentic Software Stack

Pulling the threads together, the emerging stack has a handful of layers that keep getting confused because they are usually described in the same diagram. Models provide reasoning and generation. Skills provide reusable task procedures and domain knowledge. Protocols and tools make external capabilities reachable. Business systems hold the data and perform the operations. Policies and permissions decide what is allowed. Feedback loops let a team evaluate and improve results.

In real implementations these layers overlap and blur, and this is a conceptual framework rather than an industry standard. The value of drawing the lines is diagnostic. When a project stalls, the question it usually needs to ask is which layer is actually missing: a better model, a written skill, a connection, a working system, a permission rule, or a way to measure the outcome. Each has a different owner and a different fix, and conflating them is how teams end up rewriting prompts instead of writing skills, or buying an agent platform when the real gap was an integration.

Sales is a good test of the whole stack because a meaningful outcome rarely lives inside one system. It requires coordination across data, communication, workflow state, and delivery infrastructure, with permission boundaries intact throughout.