What are MCP connectors?

The word arrived with Claude and spread from there. If you use ChatGPT, Cursor or Codex you have probably seen the same thing called an MCP server; if you use Claude you have seen it called a connector. They are the same thing, and the vocabulary split is worth knowing before you go looking for one.

The short definition

An MCP server is a program that exposes data or actions to an AI client as a set of named tools. An MCP connector is one authorised account behind such a server — your Google Ads login, your Stripe key, your Search Console property.

The distinction matters because the relationship is one-to-many. One server can carry many connectors, and how many it carries turns out to decide what you can usefully ask it.

MCP stands for Model Context Protocol: an open specification for how a client and a server describe themselves to each other. The practical effect is that the model reads what the tools are at runtime, rather than someone writing an integration in advance.

How it differs from an API integration

Underneath, almost every MCP server calls an ordinary API. The difference is who reads the documentation.

	API integration	MCP connector
Who reads the docs	A developer, in advance	The model, at runtime
What gets written	Code that calls specific endpoints	Nothing — the server describes its own tools
Who decides what to call	The code, on a fixed path	The model, per question
What changes when the question changes	Someone edits the code	Nothing
Where credentials live	Your codebase or secret store	The server

That last row is the one to think about. An MCP server holds a credential and acts on your behalf, which is a real grant of access and worth evaluating properly — we wrote separately about what makes one safe to connect.

Why the connector count decides what you can ask

Most MCP servers are published by the company whose product they cover, which means most carry exactly one account. That is a perfectly good arrangement for questions about that account.

It stops working at the first question that crosses a boundary, and in marketing most of them do:

• What did this campaign cost, and what did the customers it brought in actually pay? — the spend is in an ad platform, the revenue is in a store or a subscription platform.
• Which channel brings traffic that converts rather than traffic that bounces? — analytics on one side, orders on the other.
• Are the installs we paid for still subscribed three months later? — attribution on one side, subscription revenue on the other.

A server that sees one account can answer half of each of these. The half is not useful.

The obvious workaround is to add four single-account servers to the same client and let the model call each in turn. This does something, but the client is then doing the joining itself — from whatever fits in its context, without knowing that one system’s “conversion” and another’s “purchase” are the same event, and paying for the whole round trip in tokens each time you ask.

Holding the accounts behind one server moves that work to where the definitions are known. That is the entire design argument for a multi-account server, and it is the reason ours exists.

The vocabulary, since it is genuinely confusing

• Connector — Anthropic’s product name. If you are in Claude, this is the word in the settings screen.
• MCP server — what everyone else calls it, including Anthropic in its developer documentation.
• Remote MCP server — one that runs on someone else’s infrastructure and is reached over HTTP. Nothing to install.
• Local MCP server — one your client starts as a process on your own machine. The credential stays with you; so does keeping it running.
• Tool — one callable operation the server exposes. The set of tools is the whole of what a server can do.

Where to start

If you need one account, the vendor’s own server is usually the shortest path, and we keep a list of which vendors publish one — including for accounts we support ourselves, because pretending otherwise would be obvious and pointless.

If the question you keep failing to answer is one that spans two accounts, that is the case for a server that carries several. Ours carries a catalogue across ads, analytics, ecommerce, subscriptions and CRM, and every connector page says whether it works today, because a list that quietly includes things you cannot connect is worse than a shorter list.