A business owner asks an AI agent: find fifty potential distributors in Germany for our product, prepare a personalized outreach campaign, and show me the drafts before sending.
The agent has to do a lot before anything goes out. Understand the target profile. Search for relevant companies and contacts. Retrieve the company information it can legitimately access. Judge whether each prospect matches the criteria. Check existing contact records and suppression lists. Prepare drafts. Create the sequence. Present the campaign for review. Then execute only what was authorized, record what happened, and report the results.
Nobody in that sequence doubts the model can write a good email. The question is whether the sales system provides the right capabilities for the agent to get from the owner's intent to a finished, auditable outcome.
That is a product-design question, not a protocol question. The protocol standardizes the connection. Somebody still has to decide what the other end of that connection actually offers.
1. Design From Business Intent, Not API Endpoints
There are two broad ways to build a sales MCP server, and the difference shows up long before anyone writes code.
| Approach A: API mirroring | Approach B: business capability | |
|---|---|---|
| What is exposed | Every underlying operation, one at a time | A smaller set of operations organized around sales tasks |
| Agent's job | Assemble low-level calls, infer rules, track state | Follow a procedure the surface already supports |
| Flexibility | High; anything the API can do is reachable | Bounded by what the surface was designed for |
| Validation | Distributed across every caller | Centralized where the rules live |
| Failure mode | A bad sequence produces real damage | A missing capability blocks the workflow visibly |
Approach A is tempting because it is mechanical. Expose `get_record`, `update_record`, `create_email`, `send_email`, `get_campaign`, `update_campaign_status`, and the agent can theoretically do anything the product can do. In practice the agent has to infer the business rules that live inside the application: that a contact should not be created twice, that a suppression list must be checked before sending, that a campaign cannot start while another is running. Every agent developer rediscovers those rules independently, and most of them get at least one wrong. Approach B exposes operations like search and qualify prospects, inspect contact history, prepare an outreach campaign, validate a campaign before sending, request approval, and retrieve performance. The validation is written once, where the data and the rules live.
The trade-off is real and the right answer is not always the higher level of abstraction. Low-level tools give flexibility and composability. Higher-level tools simplify common workflows and centralize validation. Tools that are too high-level start hiding decisions that matter, which makes them hard to trust and hard to correct. The goal is not to make everything high-level. It is to pick the right abstraction per task, and to be honest about which one you picked.
2. Six Core Sales MCP Capability Groups
The grouping below is a way to think about coverage. It is not a protocol requirement and not a recommendation to implement all of it at once.
Group 1: Contact and company discovery. `search_contacts`, `get_contact`, `search_companies`, `get_company_profile`, `find_related_contacts`. The purpose is to let an agent find relevant prospects and retrieve information it is authorized to see. The design questions are less about endpoints and more about discipline: structured search criteria rather than free text, explicit pagination and result limits, clear provenance for what was retrieved, defined behaviour when data is missing or a name matches two records, and duplicate prevention when the agent wants to create something.
Group 2: Qualification and context. `evaluate_prospect_fit`, `get_contact_history`, `get_company_context`, `check_suppression_status`. The purpose is to give the agent enough to make a better decision before it acts. Two rules matter here. Qualification criteria should be explicit and configurable rather than baked into a prompt. And the system should not imply it knows facts that are not in its data: where a judgement is produced by a model, it should be labelled as model-derived rather than presented as verified.
Group 3: Outreach preparation. `create_email_draft`, `prepare_outreach_campaign`, `create_sequence_draft`, `preview_campaign`. Drafting and sending are separate operations for a reason: the agent needs to be able to build a campaign, inspect who is in it and what it says, and hand it to a human before anything leaves the building.
Group 4: Campaign execution. `validate_campaign`, `request_campaign_approval`, `start_approved_campaign`, `pause_campaign`, `get_campaign_status`. The purpose is controlled execution rather than unrestricted access to a send function. Validation before sending, explicit approval states, sending limits, recipient suppression, idempotency keys so a retry does not double-send, defined state transitions, and pause and recovery. The platform, not the model, enforces the constraints that are not optional.
Group 5: Reply and activity handling. `get_recent_replies`, `classify_reply`, `record_sales_activity`, `get_interaction_history`. The purpose is conversation context and a place to write down what happened. Classification should distinguish what the message actually said from what someone inferred about it, and important classifications should be auditable and correctable rather than final.
Group 6: Performance and reporting. `get_campaign_summary`, `get_delivery_metrics`, `get_reply_metrics`, `get_sales_activity_report`. The purpose is for the agent to inspect results and report them. This group carries a discipline of its own: requested actions, successfully executed actions, delivery events, replies, qualified opportunities, and actual revenue are different numbers. An email sent is not a delivery, a delivery is not a reply, and a reply is not a sale. Only report what the system can actually observe.
3. Read, Prepare, Execute
If only one design principle survives from this article, it should be this one: separate reading, preparing, and executing into distinct permission levels.
| Stage | What it allows | Examples |
|---|---|---|
| Read | Retrieve authorized data | Search contacts, read campaign status, retrieve interaction history |
| Prepare | Create drafts or proposed changes with no external side effect | Draft an email, prepare a campaign, propose a sequence |
| Execute | Initiate an external action | Send an email, start an approved campaign, modify a live sequence |
The reason this matters is that the permissions an agent needs are not uniform. An agent might be fully authorized to research a prospect and not authorized to send that prospect anything. It might be allowed to build a campaign draft and still require a person to approve the launch. It might be able to read campaign performance and not change campaign settings.
It is worth saying clearly what this is not. This three-stage model is a product-design recommendation for sales execution, not a requirement of MCP. The protocol does not mandate it, and an implementation that grants everything at once is not protocol-invalid. It is just a much worse idea for systems where the consequence of a wrong action is a message a real person receives.
One clarification keeps this from being read as the whole answer. The three-stage model governs what an agent is allowed to do. It does not decide what the agent should do. That procedure comes from the skill layer, which specifies the order of work and the reasoning at each step. A permission boundary without a procedure produces an agent that is safe and useless; a procedure without a boundary produces one that is useful until it is not. The previous article in this series covers that half of the design: why agents need specialized skills.
4. Tool Schemas Are Part of the Product Experience
A tool description and its parameter schema are not implementation trivia. They are the interface. They decide whether the agent picks the right operation, sends valid inputs, understands the result, and knows how to recover when something goes wrong. A badly described tool is a badly designed feature, regardless of how well the backend works.
| Element | What it must make clear |
|---|---|
| Purpose | What the tool does, and when to use it rather than something similar |
| Parameters | Required versus optional, permitted values, and the meaning of each |
| Output | The shape of a successful result, so the agent can act on it |
| Errors | Which failures are recoverable and what they mean |
| Side effects | Whether the call changes anything outside the system |
| Permissions | What authorization the call requires |
A conceptual example. `prepare_outreach_campaign` might take target audience criteria, a campaign objective, product or offer context, language, sending constraints, and a requested draft count. It might return a campaign draft ID, a recipient count, validation warnings, a list of missing information, and an approval status. Those outputs are structured on purpose: a field called `validation_warnings` is something an agent can branch on, while a paragraph of prose is something it can only summarize. This is illustrative rather than a finalized schema.
Predictable structured outputs are easier for an agent to interpret than free text alone, and they are also much easier to test. If the contract is a shape, you can assert on it. If the contract is a paragraph, you can only read it.
5. Long-Running Workflow State
Sales work does not fit in a single tool call. Research takes a while. Approval waits on a human. A campaign runs for weeks. Results accumulate. An agent that has to infer campaign state from what it remembered of the conversation is an agent that will eventually be wrong.
The system of record should expose authoritative state, and it should be durable. A sensible state model includes draft, validating, awaiting approval, approved, running, paused, completed, failed, and cancelled. The exact set depends on the product, but the properties do not: durable identifiers so a workflow can be referred to later, clear status retrieval, resumable operations, defined retry rules, idempotency keys so a retry cannot duplicate a send, audit records, and recovery from partial failure without leaving a half-sent campaign behind.
The test is simple. If the agent loses its context and reconnects tomorrow, can it ask the system what is happening and get an answer it can rely on? If the answer is no, the state lives in the wrong place.
Two cases deserve more attention than they usually get. A timeout is ambiguous by nature: the request may have been processed, may have failed, or may still be in flight, and the agent has no way to tell from its own context. The system should answer that question authoritatively rather than leaving the agent to guess, because a guessed retry on an ambiguous send is how duplicate messages happen. A partial failure is the harder case, where some recipients were processed and others were not. Without durable state, recovery means starting over, which for outreach means re-contacting people who were already contacted.
6. Errors Should Be Designed for Agents
An error is part of the interface, not a failure of it. What the agent does next depends almost entirely on what the error told it.
| Failure | What the agent needs to know |
|---|---|
| Missing required information | Which field is missing, and whether it can be supplied |
| Ambiguous contact match | That the match is not unique, and which candidates exist |
| Recipient on a suppression list | That this recipient is blocked, and that retrying will not help |
| Approval required | That the operation is valid but not authorized to run yet |
| Rate limit exceeded | That the action succeeded up to a limit, and when to continue |
| Campaign already running | That the state conflicts, and what the current state is |
| Temporary provider failure | That no side effect occurred and retrying is appropriate |
| Operation not permitted | That this is a permission failure, not a transient one |
Every error should answer four questions: what failed, whether any side effect occurred, whether retrying is appropriate, and what information or permission is needed next. Temporary failures and permanent validation failures should be distinguishable, because they call for opposite responses. And internal detail should be minimized: an agent does not need a stack trace, and a stack trace may leak something a customer should not see.
The reason error contracts matter more than they look is that a poorly described failure pushes the agent toward guessing. If a rate limit and a permission denial look the same from the outside, the agent will retry a denial and give up on a limit, which is backwards. If an ambiguous contact match returns a single result, the agent will act on it as though it were unique. If a validation failure returns a stack trace, the agent will try to fix the wrong thing. Each of those produces a tool call that is wrong in a way nobody notices until it reaches a recipient, which is why the error surface deserves the same design attention as the tool surface.
7. Security and Governance Must Be Enforced Below the Model
This is the section most likely to be treated as a formality and most likely to be the reason a deployment gets shut down. The controls that matter are the ones that hold when the model does something nobody expected.
The specific risks in this architecture are documented rather than theoretical. The confused deputy problem arises when a proxy server holds broad credentials and executes actions on a user's behalf, so anything that can influence the agent inherits the server's full reach. The published mitigation is scoped, per-user authorization with least privilege, enforced at a point the individual server cannot bypass. Prompt injection is the case where content retrieved from a contact record, a company website, or an email is treated as an instruction; the recommended mitigation is human approval for sensitive actions and treating retrieved content as untrusted data rather than instructions. Tool poisoning and rug pulls are handled with version pinning, change notifications, and signed servers.
- Authentication of the connecting client, with real OAuth for anything network-reachable rather than credentials from a config file
- User and workspace authorization, so one tenant's agent cannot reach another tenant's contacts
- Least-privilege access at the tool level, not just at the server level
- Data minimization, so a tool returns what the task needs and no more
- Audit logging that records who acted, through which connection, and when
- Rate limiting and quotas that hold regardless of how many agents are calling
- Secrets managed centrally, never embedded in tool descriptions
- Confirmation requirements for consequential actions, especially anything that reaches a recipient
- Protection against instruction injection carried in retrieved content
For outreach specifically, there are obligations that are not optional in practice: suppression lists, unsubscribe status, applicable privacy rules, and the sending policies of the provider being used. What those obligations are depends on jurisdiction, message type, and context, so this is an area to design constraints for rather than to state assurances about.
The principle underneath all of it: the model should not be the sole enforcement mechanism for security-critical rules. The execution service has to validate permissions and constraints independently. A model can be persuaded. A permission check cannot.
8. MCP Is Not the Entire Sales Platform
The protocol standardizes the connection and interaction layer. It does not provide a contact database, email delivery infrastructure, campaign scheduling, workflow persistence, business logic, compliance enforcement, or reliable analytics. Those have to exist somewhere, and they are the part that is hard.
This is the strategically important point for any vendor in this space. A thin protocol wrapper is easy to build and easy to copy. Durable sales execution requires real infrastructure behind the interface: data integrity, delivery paths that survive reputation problems, workflow state that survives restarts, permission enforcement that survives a bad prompt. The interface is what an agent sees. The infrastructure is what a customer actually depends on.
9. A Focused First SalesRuns Tool Surface
A first version should not try to expose every operation. A narrow surface that completes real workflows end to end is worth more than a large surface with half-implemented capabilities, because a gap that blocks a workflow is visible and fixable while a gap that silently produces a wrong action is neither.
| Stage | Illustrative tools |
|---|---|
| Discovery | `search_contacts`, `get_contact_history` |
| Preparation | `create_email_draft`, `prepare_outreach_campaign` |
| Validation and approval | `validate_campaign`, `request_campaign_approval` |
| Execution and control | `start_approved_campaign`, `pause_campaign`, `get_campaign_status` |
| Measurement | `get_campaign_summary` |
That set supports a complete path: search authorized contacts, prepare a campaign draft, validate recipients and content, request approval, start the approved campaign, then retrieve status and results. Each step is checkable, and the workflow either completes or stops visibly.
To be explicit about what exists: there is no production SalesRuns MCP server today. SalesRuns currently covers contact management, email outreach, sales sequences, campaign operations, follow-up workflows, and sales analytics. Everything above is a product-design recommendation and a direction, not a list of available tools.
10. How to Evaluate the Interface
A tool surface should be judged on whether it completes workflows, not on how many tools it has. Useful dimensions include task completion, tool selection accuracy, schema reliability, execution reliability, safety, recovery, observability, and latency and cost.
| Dimension | The question it answers |
|---|---|
| Task completion | Can the agent finish the intended workflow? |
| Tool selection | Does it pick the right operation rather than a plausible one? |
| Schema reliability | Are inputs and outputs consistently valid? |
| Execution reliability | Do actions complete as expected? |
| Safety | Are unauthorized or invalid actions blocked? |
| Recovery | Does a failure avoid duplicating an action? |
| Observability | Can a person reconstruct what happened? |
| Latency and cost | Can the task complete within reasonable limits? |
Test complete workflows rather than isolated tool calls. A good test is whether an agent can prepare a campaign for review and then correctly stop. The test passes when the draft exists, the validation warnings are accurate, and no email was sent. It fails the moment an unauthorized message leaves, regardless of how good the draft was. That asymmetry is the point: in this domain the interesting failures are the ones a tool-by-tool test never sees.
None of these dimensions needs a benchmark to be useful. The simplest version is a fixed set of workflows that a team runs after every change to the tool surface, with a pass condition that includes the absence of unauthorized actions. A second useful discipline is to record every case where the agent selected a plausible tool instead of the correct one, since those cases are the clearest signal that a description is ambiguous. Neither requires inventing a number. Both turn a vague question about quality into something a team can actually look at.
11. Strategic Implications for SalesRuns
The same product can serve two audiences. Human users operating a sales automation application, and compatible AI agents accessing authorized capabilities through a programmatic interface. Those are complementary rather than competing, and the second is how a product's value extends beyond its own screen.
What is hard to reproduce is not the interface. It is the substance behind it: sales-specific business operations, reusable execution workflows, reliable campaign state, delivery infrastructure, controlled permissions, activity history, operational analytics, and skills that guide an agent through those operations. Any of those can be described in a tool schema. Only a real system can deliver them.
An agent interface is not a replacement for the underlying product. It is another way to reach it, and it is worth building only if the product underneath is worth reaching.
What tools should an AI sales agent have?
Capabilities that cover a complete workflow rather than isolated operations: discovery, qualification and context, outreach preparation, controlled campaign execution, reply and activity handling, and performance reporting. The specific list depends on the product, but the coverage should let an agent move from intent to a recorded outcome.
What should a Sales MCP server expose?
A deliberately chosen set of business capabilities rather than a mirror of every internal API. Search and qualification, draft preparation, validation and approval, controlled execution, status retrieval, and reporting. Each tool should be described well enough for an agent to select it correctly and interpret its output.
How should MCP tools be designed?
Around business intent. Each tool should state its purpose, required and optional parameters with permitted values, expected output shape, possible errors, whether it causes external side effects, and what permission it needs. Structured outputs are easier for an agent to act on and far easier to test than free-text responses.
Why should read and write permissions be separated?
Because the permissions a task needs are rarely the same throughout it. An agent may be fully authorized to research a prospect and not authorized to send anything. Separating read, prepare, and execute means a mistake in research stays a research mistake rather than becoming a message a real person receives.
How can an AI agent send email safely?
Through a path that separates preparation from execution and enforces the rules below the model: validation of recipients and content, suppression and consent checks, approval where required, sending limits, idempotency keys so a retry cannot double-send, and an audit record. The system, not the model, is what makes the send safe.
What is the difference between an MCP server and a sales API?
An API is a programmatic interface to a specific system, usually written for deterministic code. An MCP server is designed for an AI application choosing capabilities at runtime, with runtime discovery and tool semantics. A sales MCP server typically wraps existing business logic rather than replacing it.
How can MCP support end-to-end sales workflows?
By exposing capabilities that compose into a workflow and keeping authoritative state in the system of record. Research, preparation, approval, execution, and measurement then become checkable stages with durable identifiers, instead of a chain of tool calls the agent has to track in its own context.
Should an MCP server expose every internal operation?
Usually not. Exposing everything forces every agent to infer the business rules and track workflow state itself, and each one gets something wrong. A smaller surface built around meaningful tasks lets validation live in one place. The trade-off is flexibility, so the abstraction level should be chosen per task.
Does MCP define the read, prepare, execute model?
No. MCP is a protocol for connecting an AI application to external capabilities. The three-stage permission model is a product-design recommendation for sales execution, not a protocol requirement. An implementation could grant everything at once and still be protocol-valid, just far less safe.
Who is responsible for security in an agent-accessible sales platform?
The execution service. The model must not be the only enforcement mechanism, because a model can be influenced by content it reads. Authentication, per-user and per-workspace authorization, least-privilege tool scopes, audit logging, rate limits, and confirmation for consequential actions all have to be enforced independently of the model.
What is the confused deputy problem in MCP?
It is the situation where a server holds broad credentials and acts on a user's behalf, so anything that can influence the agent inherits the server's full reach. The documented mitigation is scoped, per-user authorization with least privilege, enforced at a point the individual server cannot bypass.
Does SalesRuns currently offer an MCP server?
No. SalesRuns today covers contact management, email outreach, sequences, campaign operations, follow-up workflows, and sales analytics. Exposing those capabilities to AI agents through a compatible interface is a direction the product is being built toward, not an available feature.