What Is a Claude Connector, and How Is It Different From an MCP Server?

If you have opened Claude’s settings and found a section called Connectors, you have already met the Model Context Protocol without anyone using the name. “Connector” is the friendly word on the button. Underneath it is a published open standard, and once you know that, the rest of that settings screen stops being mysterious.

This page explains the vocabulary plainly, then shows you what to look at before you attach one to an account you care about. LinkedIn is the running example, because it involves a real account and real consequences, but the thinking applies to any connector.

What is a Claude connector?

A connector is an outside tool you attach to Claude so it can do something it cannot do by itself.

On its own, Claude can read what is in your conversation and write words back. It cannot look inside your files, check a live database, or publish anything anywhere. A connector changes that: it hands Claude a small, fixed list of tools — named actions like “search my documents” or “publish this post” — and Claude may call them while you chat.

Every connector has two halves, and it helps to hold them apart in your head:

• The capability half. The list of tools it offers. That list is fixed by whoever built the connector. Claude cannot invent a tool that is not on it.
• The permission half. Whether it is allowed to touch your account at the far end. That is usually a separate sign-in step, and it is the half most people click through without reading.

Are Claude connectors the same thing as MCP servers?

Yes, in the way that a website and a web server are the same thing described from two ends. The visitor says “website”. The person who built it says “server”. Neither is wrong.

MCP stands for Model Context Protocol — an open standard, published by Anthropic and now used by other AI apps too, that describes how an AI assistant and an outside tool should talk to each other. A program that speaks it is called an MCP server. When you add one to Claude, Claude calls it a connector. Same object, two audiences.

This matters for one practical reason. The useful writing is filed under “MCP server”, not “connector”. Searching the developer word gets you documentation; the friendly word mostly gets you marketing.

What is the difference between a built-in and a custom connector?

Claude ships with a set of built-in connectors for widely used services. You switch one on, sign in to that service, and it appears in your tool list. You never see a web address, because it is already built in and the integration was set up in advance.

A custom connector is one you add yourself by pasting in a web address. It is exactly the same technology; the only difference is that nobody put it on the shelf for you. Custom connectors are how you reach anything the built-in list does not cover — a tool your company runs internally, something a small builder published, or a service like Kalovio that connects Claude to your own LinkedIn account.

How do you add a custom connector by URL?

The flow is short. In Claude, open Settings → Connectors → Add custom connector, paste the server’s address, and confirm. Addresses usually end in /mcp — Kalovio’s, for instance, is https://kalovio.com/mcp. There is nothing to download and nothing to install on your computer. The tool runs on the builder’s own servers and Claude simply talks to it over the internet.

Then comes the part worth slowing down for. If the connector needs to act on an account of yours, it sends you to that service’s own sign-in page to ask permission. You approve there, on the real service’s domain, and come back. If a connector instead asks you to paste a password, an API key you did not knowingly create, or a session cookie copied out of your browser, that is a different and much weaker arrangement — we set out why in OAuth versus copied cookies.

What does the OAuth consent screen actually do?

OAuth is the open standard behind every “Continue with Google” or “Sign in with LinkedIn” button you have ever clicked. It exists to solve one problem: letting an app act for you without ever holding your password.

The consent screen is not a formality. Each step of it removes a specific risk.

• You type your password only into the real service. The connector never sees it and cannot store it.
• The screen names the permissions. Developers call these scopes — individually named powers. LinkedIn posting, for example, uses w_member_social, which permits publishing on your behalf and nothing else.
• What comes back is a limited key. Not your login — an access token, tied to that one app, that one account and those named scopes. It cannot be stretched to cover anything else, because the service refuses requests outside the list.
• The grant is recorded and reversible. The connection shows up in that service’s own settings, and you can withdraw it there whenever you like, without changing your password or disturbing your other devices.

So the consent screen is the honest inventory of what you are handing over. Read the list once. If a tool asks for far more than its job needs, that mismatch is the most useful warning sign you will ever get for free.

Can a connector do something you did not approve?

Not silently, and three separate limits stack up to make that true.

The tool list is fixed and visible. A connector declares its tools up front. Claude cannot conjure an extra one, and you can see which tool was called in the conversation as it happens.

Scopes cap what those tools can reach. A posting connector holding a posting-only permission cannot read your private messages even if its code tried. The far service enforces that limit at its end — it does not depend on the connector’s good manners.

A careful connector adds its own confirm step. This is the one that deals with the real modern hazard: prompt injection — hidden instructions buried in a web page or a document that the model reads, written to make it act. Kalovio’s answer is a two-step gate. Publishing, scheduling, queueing and deleting all return a preview first, together with a signed token covering the exact content. Nothing happens until a second call arrives carrying your confirmation and a matching token. Text smuggled in from a web page cannot produce that confirmation, so it cannot produce a post.

The honest caveat is that not every connector works this way. It is a choice the builder makes, so it is a fair thing to ask about.

How do you judge whether a connector is safe?

You do not need to read anyone’s code. Six questions get you most of the way.

• Where does signing in happen? On the real service’s own page, or in a box inside the tool? Only the first is OAuth.
• Can it name its permissions? A tool built on a documented interface will state its scope without hedging. Vague claims of being an “official integration”, with no scope named anywhere, are an assertion rather than evidence.
• Does the grant appear in your account settings? If it does, you can withdraw it in one click. If nothing appears, ask yourself how you would ever turn it off.
• What does it do before it acts? Anything that publishes, sends or deletes should show you the exact content and wait. A tool that acts on the first request is trusting the model more than you probably want it to.
• Are the limits written down anywhere? A tool that publishes an honest list of what it cannot do is usually describing the rest accurately too. A page with no limits section at all is a sales page.
• Who is behind the address? A named person or company, a privacy policy, a support address that works. These are low bars, and a surprising number of things fail them.

What does this look like for a real LinkedIn connector?

Kalovio is a worked example of every idea above. It is a hosted MCP server — a custom connector you add by URL — that lets you run your own LinkedIn account in conversation: write, publish, schedule, post images or a PDF carousel, keep drafts, keep a posting queue.

Mapped onto the checklist: sign-in happens on LinkedIn’s own consent page; the scope is w_member_social, published openly; the grant appears in your LinkedIn settings and you can revoke it there; publishing and deleting go through the two-step confirm gate; and your LinkedIn token is encrypted on the backend, never handed to the assistant and never written to a log. Nothing is scraped — no cookies, no browser automation, no borrowed session.

The limits are just as much a part of the picture. It cannot read posts that were not created through it, because LinkedIn keeps that permission closed to self-serve apps. Tokens run out after about sixty days, so you reconnect. There are no engagement statistics, only link-click counts, which are not the same thing. It cannot send messages, send connection requests, or gather leads. Multi-image carousels and PDF document posts go through LinkedIn’s newer versioned interface, which may be product-gated for a self-serve app — a refusal is reported clearly, so try it on your own account rather than assuming it works for everyone — and document posts cannot be scheduled yet, only published immediately.

Do connectors work the same way in ChatGPT?

The standard is the same; the doors are different. In Claude, custom connectors are available on the free plan. In ChatGPT the equivalent sits behind Developer Mode, which needs a paid plan, works on the web only, and has to be switched on for each conversation through the tools menu. Connecting something in ChatGPT also does not carry across to Codex — each app connects and signs in on its own.

One shared limitation catches people out. Neither Claude nor ChatGPT can hand a connector a picture you attached to the chat. Attachments go to the model, not to the tool. Tools that work with images therefore give you an upload link or upload panel of their own, and that is a limit of the platforms rather than of any one connector.

The short version

A connector is an MCP server wearing a friendlier name. Built-in ones were approved for you; custom ones you add yourself by pasting a URL. The consent screen is the real contract, so read the permissions it lists. And before you attach anything to an account that matters, ask three things: where sign-in happens, what the tool can reach, and what it does before it acts. Those answers separate a well-built connector from one to leave alone.