Connect an AI Agent to Your CRM with MCP: Workflows and Checks
An AI agent can query your CRM, summarize deals and prepare tasks at an employee’s request. MCP integration needs a server that describes the available operations and connects them to the CRM. A platform may provide one; for a custom CRM, you can build it over the existing API.
September 24, 2026 Google announced MCP support in API Gateway: The gateway is able to expose REST API operations as agent tools. As of October 2, the feature is in Public Preview. This is one of the connection options that should be considered together with ready-made CRM connectors and your own adapter.
For the head of the sales department and the development team, the first question is what actions to assign to the agent and how to confirm their results. Start with one reading scenario, such as a summary of an employee's available deal. Then add changes with permission checking and confirmation of the specific operation. Below is the procedure for selecting connection and acceptance of such a pilot.
What MCP adds to your CRM API
B MCP architecture The AI application connects to the server via an MCP client. The server provides tools: functions with names, descriptions and parameters. For example, get_deal_summary can return a short transaction card, and create_followup_task — assign a task to the manager.
CRM operations are performed by its API or a separate business service behind the MCP server. Access rules, validation, and restrictions on changing data must be maintained there. The connection diagram for your own project looks like this:
- An employee asks a question or asks to perform an action in an AI application.
- The application receives a list of allowed tools and selects the appropriate one.
- The MCP server validates the request and contacts the CRM on behalf of a valid user or technical account.
- CRM checks access to the record and returns the result.
- The agent displays a response with a link to the card or suggests a specific change for confirmation.
If the CRM API is not yet documented, start with the contract: what entities exist, who owns the data, what errors are returned, and how replays are handled. These solutions are discussed in detail in the material about CRM and integration architecture.
Choose a connection method
The choice depends on the current CRM, infrastructure and composition of operations. Before developing, check if there is an official server for your system and if it covers the required scenario.
| Option | When to consider | What to check before choosing |
|---|---|---|
| Official MCP CRM server | The platform already offers the necessary tools | Availability in the account, employee rights, disconnecting the connection, list of actions |
| Application from the marketplace | The official script is not enough, the partner has a suitable connector | Service owner, data processing location, permissions, logging and support |
| Own MCP server on top of API | Do you have your own CRM or do you need narrow business operations? | API quality, authorization, test circuit, operation owner |
| API gateway with MCP support | The APIs are already managed through the gateway and there is a suitable contract | Client compatibility, product limitations, network access, and failure behavior |
For a single assistant with a small set of operations, a custom adapter may be simpler than implementing a separate API management platform. If the gateway is already in use, check its capabilities: repeating authorization and routing in another service unnecessarily is inconvenient for maintenance.
Make placement decisions based on the actual data path. Record where the MCP server and CRM are located, which vendor handles the request to the model, what fields the model receives, and how long the history is stored. A local adapter by itself does not mean that the data remains within the company.
Options for Bitrix24 and a custom REST API
By official Bitrix24 certificate, the external AI assistant can access CRM and other tools through the MCP server. The administrator enables the permission in the MCP settings; actions take into account the rights of the employee. OAuth and a token are provided for connection, the server address is https://mcp.bitrix24.tech/mcp/.
The certificate separately specifies access conditions: for the ru domain zone you need a BitrixGPT + Marketplace subscription, for other zones - a commercial tariff. Updates appear gradually. Before the pilot, check the conditions of your account and the support of the selected AI client: the presence of a server address does not confirm that all the necessary operations are available to your team.
For its own REST API, Google offers an option based on API Gateway. The configuration uses OpenAPI 3.x, and the gateway translates the MCP call into an HTTP request to the backend. As of the date of review, Preview does not support MCP resources and prompts, stdio transport, streaming or long tool calls. For a multi-step CRM operation, check in advance whether it fits within the capabilities of the gateway and client.
Both examples show connection methods. Acceptance of your integration should validate specific records, roles, and actions, regardless of the product selected.
Choose workflows for the first pilot
Select a task that the employee performs regularly and the result of which can be checked in CRM. The wording “sales assistant” is too broad to be acceptable. “Show overdue tasks for my open transactions” already sets clear boundaries.
| Scenario | Data and Actions | Verifiable result |
|---|---|---|
| Summary of one trade | Reading stage, owner and last allowed events | The information matches the card, there are no closed fields |
| List of deals without next step | Read limited list and related tasks | Each line has an ID, a reason for inclusion, and a link |
| Preparing the task after the conversation | Suggestion of title, date and contractor | The employee sees the parameters before recording, the task is created once |
| Draft letter to client | Read allowed context, generate text | The email is available for review and is not sent automatically |
For a pilot, one or two scenarios from the table are enough. It is better to add bulk updating of stages, mailing and deleting records after checking narrow operations: they have a different scale of possible error and different requirements for confirmation.
Separate current CRM data and process knowledge. The deal stage must be obtained from the CRM at the time of the request. The procedure for agreeing on a discount can be stored in the regulations and located through the RAG. For this part use checklist for preparing a knowledge base: The document version and rights to it must be known before responding.
Describe tools so the agent can select them correctly
MCP Specification provides a description of the tool and a diagram of the input parameters. The client receives the tools via tools/list, calls the selected one via tools/call. At the project level, it is important to make the purpose of each function unambiguous.
It is more convenient to design tools around user tasks: “get deal summary”, “suggest next task”, “add internal comment”. A generic function with an arbitrary API address and request body makes it difficult to both select an operation and check for valid actions.
Below is an example of a description of one tool for your own CRM. The name and fields are conditional; This is a contract scheme that will require a backend handler to work.
{
"name": "get_deal_summary",
"description": "Get the current stage, owner and next task for one deal accessible to the employee. Use for questions about a specific deal.",
"inputSchema": {
"type": "object",
"properties": {
"deal_id": {
"type": "string",
"minLength": 1,
"description": "CRM deal identifier"
}
},
"required": ["deal_id"],
"additionalProperties": false
}
}In this option, the model passes the transaction ID. The user, company, and set of rights are determined from the validated authorization context. The handler decides whether the record can be read and returns only the fields that match. A request for someone else's ID should result in a refusal without revealing the contents of the card.
For each tool, it is helpful to include examples of correct usage, an ambiguous request, acceptable failure, and expected response fields. If an employee asks “show Ivanov’s deal” and several cards are found, the agent should request clarification before acting.
Authorize changes in the CRM
In your own adapter, it is convenient to separate the preparation of changes from execution. First, the agent proposes a new task or stage. The interface shows the record, current and new values. After confirmation, the server re-checks the rights and status of the card and performs the agreed operation.
For example, the manager allowed the task to be set for transaction A. Between the proposal and confirmation, the card was transferred to another department. The handler must check the new state and fail if necessary. The old confirmation should not give access to the record after the rights have been changed.
For each operation, write down the rules:
- what fields are allowed to be changed;
- what transitions between stages are acceptable;
- who can confirm the action;
- how long the confirmation is valid;
- how the system recognizes the repetition of one request;
- what state to show if the result is unknown;
- How to cancel a change if the business process allows cancellation.
Implement protection against duplicates in the handler. If a task is recorded and the response is lost due to a network failure, a second request with the same operation ID should return the same result. Without this, repetition on the client's side may pose a second challenge.
Store tokens in the integration loop and exclude them from the text that the model receives. MCP Security Recommendations prohibit blindly accepting a token issued for another resource and passing it on without checking the destination. The authorization scheme between the client, MCP server and CRM must be designed explicitly.
For a wider outline with multiple tools, the guide to AI agent isolation, rights and emergency stop.
Test the integration before launch
Test actions in a test CRM with individual users and pre-prepared records. One administrator will not allow access control errors to be seen. You need at least two roles with different rights and cards available only to one of them.
| Test | Expected result |
|---|---|
| Employee requests an available deal | The response matches the CRM and contains a link to the entry |
| An employee requests a card from another department | The data is not disclosed, the reason for the refusal is clear |
| The name suits several transactions | The agent asks to clarify the card |
| The client comment contains the command to change rights | The comment remains data, the prohibited tool is not executed |
| Employee rejects task creation | New task does not appear |
| Confirmed request is repeated after timeout | One task is created, repetition returns its result |
| Rights change between offer and confirmation | The server rechecks access and blocks the invalid action |
| CRM is not available | The agent reports a failure and does not present the old result as current |
| Connection revoked | New requests to CRM do not go through |
For each test, save the input request, role, source card, actual response, and CRM state after execution. This makes it easier to separate the cause of an error from the quality of the text: a poor choice of tool, incorrect parameters, insufficient access checks, or an API failure require different fixes.
In the operation log, associate the user, the tool call, the permission check solution, and the ID of the changed entry. Limit access to the log and the composition of the stored fields: complete correspondence or a client card is not always needed for an investigation.
Prepare an implementation brief
The timeline and budget depend on the quality of the API, the number of scenarios, and operational requirements. Before the assessment, provide the team with a short description:
- What CRM is used, where is it located and is there a test circuit.
- Who will work with the agent and how the rights of employees differ.
- What specific operations are included in the first release.
- What fields can be passed to the model and what providers are allowed.
- What actions require confirmation and how repetition is processed.
- What examples of requests, refusals and errors are included in acceptance.
- Who is responsible for access, logging, support and disabling integration.
If you already have an API, you can start working by checking the selected script within implementation of AI in business processes. If the CRM is to be developed or significantly changed, the agent’s tools should be included in the contract when designing a CRM system.
After the pilot, evaluate the proportion of tasks completed correctly, the time to a verified result, the number of manual corrections and access errors. Expand the catalog of operations based on the results of these checks. The mere fact of connecting MCP does not indicate that the agent is helping employees.
FAQ
Can you connect a custom CRM without an existing MCP server?
Yes, via an adapter to its API or a gateway with suitable MCP support. If the CRM does not have a stable API, you will first need to create a limited business operations interface and define its owner.
Do you need to train the model on your entire customer database?
This is not required to obtain a current card through the tool. Data can be requested for an authorized operation at the time of request. The composition of the response and the transfer of fields to the model provider must be agreed upon separately.
Can you use MCP with Bitrix24?
There is such a connection in the official help. Check your account availability, subscription terms, admin permissions, and employee permissions. The set of operations and connection method also depend on the AI client.
When is conventional automation sufficient?
If an event always results in one known action, a CRM robot, webhook, or background handler will do. The agent is useful where you need to understand an employee's request, select data, and prepare a solution while keeping business rules validated outside the model.