An AI assistant that can write a proposal does not necessarily know whether a customer has an active contract or which products are in stock. That information lives in a CRM, ERP or inventory system. MCP helps expose it to an AI application through defined interfaces. The central implementation decision is still what the assistant may read, what it may change and who approves the result.
What is MCP and how can a business use it?
Model Context Protocol is an open protocol connecting AI applications to servers that expose data and capabilities. The application acts as the host, while its MCP client connects to the relevant server. A server can provide tools for specific operations, resources to read and prompt templates for working with a model.
MCP standardises communication; it does not replace CRM business rules or automatically grant access to every record. Source documentation.
What changed in MCP in July 2026?
The specification released on 28 July 2026 introduced a stateless protocol core, changes to request routing, cacheable lists and stronger authorisation rules. For an implementation team, this means checking compatibility between the client, server and SDK. An example written for an older version should not be assumed to work unchanged.
Before starting a project, record the supported protocol versions and plan an upgrade test in a staging environment. Source documentation.
MCP or a conventional API integration?
If a paid order must always trigger a document and send data to a warehouse, a conventional API integration with an event queue may be simpler. The process follows a predefined path. MCP is worth considering when users ask varied questions and an assistant needs to select the right sources or operations across several systems.
Both approaches can coexist. An MCP server can use an existing API rather than access the database directly. The source system then remains responsible for order validation, permissions and consistent writes. The team does not have to recreate those rules in instructions given to the model.
Example: preparing a proposal using CRM and ERP data
Suppose a salesperson requests a draft proposal for a named customer. This is an illustrative design, not a deployment case study with claimed sales results. A first version can be limited to the following steps:
- The CRM returns the selected customer record and contact history the salesperson is permitted to access.
- The ERP provides current pricing and availability for the specified products. Each result includes its retrieval time.
- The assistant creates a draft with references to source records and marks missing information.
- The salesperson checks the line items, discount and terms. Saving or sending happens only after approval of the specific document.
The instruction “do not send without approval” should not be the only control. Separate the tool that creates a draft from the tool that sends it. The sending tool should require approval bound to the document content; changing the amount or recipient after approval should invalidate that approval.
How should permissions and data protection be designed?
For remote MCP over HTTP, the specification describes OAuth-based authorisation mechanisms. It also requires appropriate validation of tokens and their intended audience. A token meant for another service should not simply be passed through as a universal access key.
Authorisation details must match the protocol version and the way the server is exposed. Source documentation.
For a business implementation, we suggest reviewing six boundaries separately. These are design recommendations to adapt to the risk of the process:
- Identity: every operation is associated with a user or a clearly defined service account.
- Data scope: the server checks access to the specific organisation, record and field, rather than merely checking that someone is signed in.
- Writes: data-changing operations have separate permissions and validation in the source system.
- Retries: repeating a request must not create a second proposal or duplicate order.
- External content: the text of a message or document is data, not an instruction to grant additional permissions.
- Audit trail: record the operation identifier, result and time while limiting personal data in logs.
What should be tested before the assistant reaches the team?
A test showing that a proposal was successfully prepared is not enough. Check customers with similar names, denied record access, an unavailable ERP, stale pricing, withdrawn approval and attempts to send the same document twice. The assistant should clearly state what it could not verify rather than fill gaps with a plausible answer.
During the pilot, measure task completion time, the share of outputs requiring correction, rejected operations and cost per correctly completed workflow. Include the human effort needed to review results. A short response generation time does not automatically mean the team saves time overall.
Where should a business start with MCP integration?
Choose one frequent workflow, identify the data owner and begin with reads and drafts. Add write operations only after evaluating quality. Budget for API readiness, permissions, a test environment, error handling and maintenance as the protocol evolves. A ready-made MCP server may shorten setup, but it does not remove the need to review these elements.
Frequently asked questions
Does MCP replace a CRM API?
No. An MCP server can use an existing API and expose selected operations to an AI application. Business rules and access controls should still be enforced by the source system.
Does an MCP agent need write access?
No. The first stage can be limited to reading data and preparing drafts. Write access should be introduced separately after testing and defining how changes are approved.
What determines the cost of an MCP integration?
It depends on the number and quality of APIs, tool scope, permissions, required tests and maintenance. An estimate should cover a specific workflow and its exceptions, rather than just connecting a server.