# Zoho CRM MCP server for our sales team: two paths

> A Zoho CRM MCP server for our sales team can mean two different things. Here is what changes underneath, and what a rep sees in ChatGPT or Claude.

**TL;DR** Asking for a Zoho CRM MCP server for our sales team is two questions: a server that speaks MCP, and the rules around who may call it. Elaichi covers the second half either way. Check its connector catalog first, and if the CRM is not there, an Org Owner or Org Admin on Gold can add the remote MCP server as the organization's own connector. Reps then use one address, sign in as themselves, and every call that runs lands in one audit log.

## That query is two questions stacked

A sales manager searches for "zoho crm mcp server for our sales team", and the results are repositories plus a vendor page or two. That answers the plumbing half. The other half is who on the team may call it, as whom, and what you can show an access reviewer three months later.

MCP is the protocol an AI client uses to find and run tools on a server. One app's server governs one app. A sales team running a CRM, a help desk and a calendar has three servers, fifteen sign-ins, and no shared record of what ran. A repository list does not touch that part.

What Zoho itself publishes is a question for Zoho's own documentation, read with the date of the check written down. The rest of this post is the part that holds either way. If the broader question is how any CRM reaches an assistant without engineering work, [start with the CRM walkthrough](/blog/connect-ai-to-crm/).

## What a Zoho CRM MCP server for our sales team has to do

Four things have to hold before the tool list matters.

**It has to be reachable.** Elaichi accepts a remote MCP server that speaks MCP over Streamable HTTP on public HTTPS. A server that only runs on a laptop, or that sits behind an internal hostname or an IP literal, cannot be added as a connector.

**It has to act as each rep.** If the CRM's own roles are meant to apply, each call has to carry that rep's own sign-in at the CRM.

**It has to be narrowed.** A sales role usually wants reads and a few writes. Nothing in a server's own tool list does that narrowing for you.

**It has to be logged in one place.** One log per server is not one log for the team.

The server's author decides the first point. The other three are what a control plane does, and they work the same whether the server came from the vendor, from a repository, or from a connector Elaichi wrote itself.

## Two ways Elaichi carries a CRM like this

Either the connector is already in Elaichi's catalog, or your organization adds the remote server as its own connector.

Elaichi authors and runs most of the 650+ connectors in its catalog itself. For the rest, the native MCP connectors, the vendor builds and runs its own MCP server, and Elaichi handles sign-in, access and audit in front of it. The catalog changes with every connector sync, so start from [Elaichi's Zoho CRM page](/connectors/zohocrm/), or [browse the whole catalog](/connectors/), rather than trusting a figure in a blog post. The reasoning behind fronting a vendor's own server is set out in [the case for governing vendor MCP servers](/blog/vendor-mcp-servers-through-elaichi/).

If the CRM is not in the catalog, an Org Owner or Org Admin adds the remote server from Connectors, New connector, Add remote MCP server. That needs the connector:create permission and the custom connectors feature, which the Gold plan includes. The server URL must be https and cannot be changed afterward, so a different server means a new connector. One organization can own up to 25 remote MCP connectors, and each connection can carry up to 500 tools.

Elaichi never hands its own MCP access token to that server. An OAuth server behind a remote MCP connector only ever sees a token its own authorization server issued.

## What changes in the model once the server sits behind one address

Elaichi serves MCP at one endpoint, https://api.elaichi.ai/mcp, and that is the same string for every organization. Which organization, which person and which tools a client reaches comes from the OAuth grant behind its token, not from the URL. A grant is the approval one person gives one named client on Elaichi's consent screen.

Four things change underneath:

1. **A connection replaces a pasted key.** Each rep's CRM account becomes one connection row, and the secrets sit in a separate credential service, encrypted at rest with AES-256-GCM. The AI client holds only an Elaichi token.
2. **Tools are discovered per connection.** For a remote MCP connector, Elaichi asks the server what it offers using that connection's own credential, because two reps' accounts can see different tools. Under the default policy a newly seen tool is usable at once; under the review policy it waits for someone who can manage the connector.
3. **Every call passes a restriction check first.** A restriction is a rule on a role or on one member that allows or blocks whole connectors and single tools. For a remote MCP connector, a rule names the tool by the upstream server's own tool name.
4. **Every call that reaches execution writes an audit row**, with the person, the connector, the connection and the MCP client that made it.

One structural difference is worth holding onto. For a catalog connector, Elaichi is itself the MCP server the client calls. For a remote MCP connector, Elaichi sits in front of the vendor's server. Either way, a call a client makes straight to that vendor's server, outside Elaichi, is not governed by Elaichi.

## What a rep sees in the client

One connector, added once. To an MCP client, Elaichi is a single server named Elaichi for the whole organization, not one per app. Each rep signs in through a browser and approves their own grant; the client-side steps are in [the ChatGPT setup walkthrough](/blog/connect-elaichi-to-chatgpt/).

Their tool list does not name the CRM. In Elaichi, connected tools are never listed one by one, however few there are. The model finds a tool with search_tools and runs it with execute_tool, and each tool's description opens with its tier: read-only, writes, or deletes.

That has a consequence to raise before a security review. No tool in Elaichi's list names a connected app, so a client-side control that gates individual tool names can only act on execute_tool as a whole. Per-app and per-tool control is set in Elaichi instead, which is the subject of [choosing between a tool-level and an app-level block](/blog/per-tool-vs-per-app-restrictions/).

The client's own prompts still sit on top of all this. In a Claude conversation, the plus button's Connectors item shows a toggle for each configured connector that turns it on or off for that conversation ([support.claude.com](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp), checked October 2026). For write or modify actions, ChatGPT may ask for confirmation, depending on app permissions and the action's context ([help.openai.com](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt), checked October 2026). Cursor asks for approval before using MCP tools by default, and supports OAuth for MCP servers that require it ([cursor.com](https://cursor.com/docs/mcp), checked October 2026).

## Giving each rep their own CRM login

An AI client acting with an employee's permissions means an MCP client signed in with that employee's own grant, running tools on that employee's own connections. Each rep connects the CRM with their own sign-in, so the CRM's own roles decide what comes back. The same shape, worked through for a different CRM, is in [the Salesforce per-rep playbook](/blog/sales-team-chatgpt-salesforce-accounts/).

A connection shared with the team does the opposite. Every call through it runs on the account it was connected with, whoever is calling. That is the right shape for one fixed permission set and the wrong shape for per-rep visibility.

## What to switch off before the first rep connects

Consent is not where a CRM becomes read-only. The "Run your connected tools" checkbox covers every tier of connected tool, deletes included. "Delete data and remove access" covers Elaichi's own deletes, not the app's.

There are two ways to hold a sales role to reads. Write block rules on that role for the write and delete tools. Or build a toolbox of read tools, a named list of tools pinned to particular connected accounts, and have each rep choose only that toolbox at consent.

Three traps live in the rule model. A block beats an allow inside a layer. An allow rule that names nothing blocks every connector and tool for its target. A layer with only block rules leaves every write it did not name reachable. Once a role carries any allow rule, it also needs allow rules for the other apps that role uses, which is why [the governance use case](/use-cases/governance/) starts from the role rather than the app.

Timing matters when you are testing. A role, team membership or restriction change reaches every surface within about two minutes. Revoking a grant, removing or suspending a member, revoking a share and disconnecting an account all take effect on the next call. The wider model is laid out in [the governance guide](/blog/mcp-governance/).

## What the audit log shows, and what it leaves out

Each connected-tool call that runs, fails or is refused at execution writes one row. It records the person, the tool's advertised and catalog names, the connector, the connection the call actually reached, the tool's classification, how approval was given, the surface, the MCP client, the outcome, and what the call touched.

It does not record argument values, with one exception: the single path argument that names the object is kept as the target id. It records neither argument names nor an argument count.

Calls refused before execution write nothing. A tool a restriction withholds, a missing scope, an unknown tool name and a rate limit all leave no row.

The client name is only as good as the client. Elaichi can verify seven clients from their registered redirect addresses; a client that registers only loopback addresses shows the name it gave itself. Elaichi keeps 90 days of audit history, and export to your own Datadog comes with the Black plan, which is launching soon. For what a reviewer will ask of these rows, see [what an audit log has to capture](/blog/what-an-ai-audit-log-must-capture/).

## When one rep and one server is the right answer

If one person wants the CRM in their own assistant, a control plane is machinery they do not need. The vendor's own server plus that person's own sign-in is fewer moving parts and no second vendor to buy. The case for one governed address starts when several people need several apps under one set of rules and one log, which is the line drawn in [when a gateway is premature](/blog/when-you-dont-need-an-mcp-gateway/).

Two limits hold whichever path you take. Prompt injection is not something Elaichi defends against, and no server in this position could: the person's prompt never reaches it, so there is nothing to judge a call against. That defense belongs to the client, and [the risk list](/blog/mcp-security-risks/) covers the rest. And for a native MCP connector, the vendor builds, runs and fixes its own tools, so reports about those tools go to the vendor's support contact. Pricing for the plan that carries custom connectors is on [the pricing page](/pricing/).

## FAQ

### Does Elaichi have a connector for Zoho CRM?

Elaichi's connector catalog changes with every connector sync, so check elaichi.ai/connectors/ for the app you need rather than relying on a figure in an article. If an app is not in the catalog, an Org Owner or Org Admin can add its remote MCP server as the organization's own connector, which needs the connector:create permission and the custom connectors feature included in the Gold plan.

### Can a CRM be made read-only for a sales team in ChatGPT or Claude?

Not through the consent screen. In Elaichi, the "Run your connected tools" checkbox covers every tier of connected tool, writes and deletes included, and "Delete data and remove access" only covers Elaichi's own deletes. To hold a role to reads, write block rules on that role for the write and delete tools, or build a toolbox of read tools and have each person pick only that toolbox at consent.

### Does every sales rep need their own CRM sign-in?

They do if the CRM's own roles are meant to apply. In Elaichi, every call through a connection runs on the account that connection was made with, whoever is calling, so a connection shared with a team acts as its owner in the app. For per-person visibility, each person connects the app with their own sign-in and runs tools on their own connections.

### How quickly does a restriction change reach an AI client?

A role, team membership or restriction change in Elaichi reaches every surface within about two minutes. Some changes are faster: revoking a client's grant, removing or suspending a member, revoking a share and disconnecting an account all take effect on the client's next call.

### What does Elaichi's audit log record for a CRM call made from an AI client?

One row per connected-tool call that reaches execution, holding the person, the tool's advertised and catalog names, the connector, the connection the call reached, the tool's classification, how approval was given, the surface, the MCP client, the outcome and what the call touched. Argument values are not recorded, apart from the single path argument that names the object, which is kept as the target id. Elaichi keeps 90 days of audit history.

## Read next

- [Linear MCP server for our engineering team](/blog/linear-mcp-server-for-our-engineering-team/) — A Linear MCP server for our engineering team changes whose account each call runs as, which tools stay on, and what the audit log keeps.
- [GitHub MCP server for a company with SSO](/blog/github-mcp-server-for-a-company-with-sso/) — A GitHub MCP server for a company with SSO has two sign-ins to settle: your identity provider, and whose GitHub account the tool call actually runs as.
- [Outreach MCP access for sales team in Cursor](/blog/sales-team-cursor-outreach-sequences/) — Outreach MCP access for sales team work in Cursor: allow sequence reads, block bulk enrollment and mailbox sends, and freeze the sequence owner.