What is an MCP connector?
Model Context Protocol is a plain way for an AI assistant to call the tools a piece of software already has, instead of you copying that software's data into a chat window by hand. Here is what it actually means for someone running a CRM, not building one.
The problem it replaces
Before a connector, using an AI assistant with your CRM looked like this: open the CRM, find the contact, copy the timeline, paste it into ChatGPT or Claude, ask your question, read the answer, then go back to the CRM and do whatever it suggested by hand. It works, but every step is a place where you lose a detail, run out of patience, or just do not bother.
A Model Context Protocol connector removes the copy-paste in the middle. The assistant is given a defined set of tools, things like “search contacts”, “get a contact’s timeline”, or “create a task”, and it calls them directly while you are talking to it. You still ask the question in plain English. The assistant fetches the real data itself instead of you fetching it for it.
What MCP actually is
MCP is a protocol, not a product. It defines how an AI assistant discovers what tools a server offers, what arguments each tool takes, and how results come back. Anthropic published it as an open standard, and it has since been adopted well beyond Claude: ChatGPT can act as an MCP client too, which is why the same connector works for both rather than needing a separate integration for each assistant.
Think of it as the same idea as a REST API, aimed specifically at language models instead of at other programs. A tool has a name, a description of what it does, and a schema for its inputs, so the assistant can read that description and decide when to use it, the same way a new hire reads a runbook before touching a system.
Why calling a tool beats pasting into a prompt
Pasting data into a chat has three problems a connector does not have. First, it is stale the moment you paste it: the assistant is reasoning about a snapshot, and if a colleague updates the deal five minutes later, the assistant never finds out. A tool call fetches live data, every time.
Second, a pasted timeline is however much fits in the message and however much you remembered to include. A tool can be told to fetch exactly what is needed: the last fifty communications on this one contact, not the whole account history. Third, and this is the one people underrate, a pasted answer has nowhere to go. If the assistant drafts a follow-up email after reading a pasted timeline, you still have to copy that draft back into the CRM yourself. A connector with a write tool can save the draft directly, which is the difference between an assistant that advises and one that actually gets something done.
What OAuth is buying you
The connector in agentlyleads is protected by OAuth 2.1, the same family of login flow you use when a website offers “continue with Google”. You approve the connection once, in your own browser, on your own CRM login. What the assistant receives afterward is a token scoped to your workspace, with an expiry, not your password and not a permanent key.
That matters for two practical reasons. You can revoke a token without changing your password, the same way you can sign an app out of your Google account without resetting it. And the token only ever works against the one workspace you approved it for, which is what stops it becoming a skeleton key if it ever leaked.
Why a scoped connector beats an API key in a prompt
The alternative people reach for is an API key, generated once and pasted into a system prompt or a config file so the assistant can call the CRM’s REST API directly. That key usually does not expire, is not tied to a specific login, and grants whatever the key’s permissions say, which is often broader than the one task at hand. If it ends up in a shared prompt, a logged conversation, or a config file someone commits by mistake, it stays valid until a human notices and rotates it.
A connector scoped to one workspace behaves differently on every one of those points. The assistant authenticates as a specific user in a specific workspace, every tool call runs with that user’s permissions, and revoking access is one click rather than a key rotation across every place the old one was pasted. It is the difference between handing someone your house key and buzzing them in yourself.
What this looks like inside agentlyleads
agentlyleads runs its connector at /api/mcp, described in full on the connector page. Reads are open to anything your account can already see: search contacts, pull a timeline, list what is due today. Writes, like logging a conversation or creating a task, are confirmation-gated, and an outbound email is always saved as a draft rather than sent. There are no delete tools at all. If you want the step-by-step of connecting it and what to actually ask once it is wired up, that is the next post: how to run your CRM from ChatGPT. For short definitions of MCP and the other terms in this piece, see the CRM and MCP glossary.
Common questions
- Is MCP the same thing as a chatbot plugin?
- Not quite. A plugin usually ties one assistant to one product. MCP is a protocol, so the same connector works with any assistant that speaks it, which today includes both Claude and ChatGPT. You build the connector once.
- Does connecting MCP give the assistant my password?
- No. OAuth issues the assistant a token scoped to your workspace, not your login. You can see what was approved and revoke it, and the assistant never sees the credential you use to sign in yourself.
- Can the assistant delete my data through MCP?
- In agentlyleads's connector, no. There are read tools and confirmation-gated write tools, but no delete tools at all, so the worst a mistaken instruction can do is create or change a record you then have to fix.