What is an MCP Connector and what can AI see in your data?

What is an MCP connector, and how is it different from an MCP server?

An MCP connector is the client side of an MCP connection: the piece inside the AI application that talks to one external system. An MCP server is the other half, built and hosted by the software vendor whose data it exposes. The Model Context Protocol is the open standard both ends follow. Four terms, three moving parts.

The specification is precise about this. It names

• Hosts as the AI applications that start a connection

• Clients as the connectors sitting within the host application

• Servers as the services that supply context and capabilities.

In everyday product language the word connector is used more loosely, usually for the whole connection a person switches on in their AI tool. Both usages are in circulation, which is why vendor documentation can be confusing to read. When you are assessing something, the distinction worth holding is who built and hosts the server, because that is where responsibility for access control sits.

Anthropic introduced MCP in November 2024, then donated it in December 2025 to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI. Anthropic's Chief Product Officer, Mike Krieger, framed that as keeping the standard open, neutral, and community-driven as it becomes critical infrastructure for AI, in the Linux Foundation announcement. For a buyer, the relevant part is that this is not one supplier's proprietary hook into your systems.

How does an MCP connector work?

A connector turns a question in a chat window into a real query against a live system. You ask something, the AI application calls the connector, the connector requests the data from the server inside your permissions, and the answer comes back into the conversation. Nothing is copied anywhere in advance, and no export is involved.

The specification defines three things a server can offer.

• Resources are context and data for the user or the model to read.

• Prompts are templated messages and workflows.

• Tools are functions the model can call to do something, which is the part that can change a record.

• There is also a client-side feature called elicitation, which lets a server ask the user for information it still needs before it proceeds. 

That is the mechanism behind a conversation that stops to ask you for the missing renewal date rather than guessing one.

The problem the standard solves is arithmetic: four AI tools and eight business systems once meant up to thirty-two custom integrations to build and maintain, where one standard means one server per system. By December 2025 there were more than 10,000 active public MCP servers, and the protocol had been adopted by ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code.

An MCP connector is not a data migration, and it does not replace system-to-system integration: if your finance platform needs third-party records synchronised into it nightly, that is still a job for no-code integration between your core systems. A connector gives one person's AI assistant a governed door into a system for the length of a conversation.

What does an MCP connector let an AI tool see and change?

A well-built connector inherits the permissions the person using it already holds, so it cannot open a record they could not open themselves. Write access is a separate matter and should be authorised explicitly, per application, rather than assumed. Not every connector behaves this way, which is exactly why the question is worth asking out loud.

The standard is unusually candid about where responsibility sits. Its security section sets out three principles for implementors:

• Users must consent to and understand data access and operations;

• Hosts must obtain explicit consent before exposing data to a server;

• Tools warrant caution because they represent arbitrary code execution, with tool descriptions treated as untrusted unless they come from a trusted server.

It then states, in as many words:

"MCP itself cannot enforce these security principles at the protocol level."

Consent flows, access controls, and data protection sit with whoever builds the server. Read that as a buying instruction. Safety comes from how a connector is built rather than from the standard alone, which means a connector built and hosted by the software vendor that owns the data is a materially different proposition from one somebody installs from a public registry and points at a database with a shared API key.

Two further things matter for regulated third-party data:

• The first is where the request is served: if you have data residency commitments, the endpoint your tenant connects to needs to match the region your data is hosted in.

• The second is the audit trail. When a record changes or a request is raised through a conversation, your system of record should show who did it and when, in the same place it shows every other change.

If you want the security details on how Gatekeeper handles this, it sits in our Security Center.

What should you ask before connecting an AI tool to your vendor and contract data?

Five questions will tell you most of what you need to know about any software vendor's MCP connector. Ask them before a pilot rather than after one. This is short due diligence rather than a security review, and any vendor who cannot answer all five quickly has told you something useful in itself.

Gartner's June 2025 forecast that more than 40% of agentic AI projects will be cancelled by the end of 2027 named escalating costs, unclear business value and inadequate risk controls as the causes. That covers agentic AI projects in general rather than connectors specifically, but two of those three are governance failures you can screen for in one meeting.

1. Which objects and fields does the connector expose? A precise list is a good sign. A vague answer usually means broad access, and broad access is what turns a useful tool into an incident.
2. Is it read-only, and if it can write, how is that authorised and by whom? Read and write should be separable. If write access arrives switched on by default, that is a design decision someone made for you.
3. Whose permissions apply, the user's or the connector's? The answer you want is the user's existing role. A connector with its own service account and broader rights widens access for everyone who uses it, and nobody in the business will see that happen.
4. Which regional endpoint serves our tenant? It should match where your data is hosted. If your vendor cannot answer this quickly, ask how they handle residency at all.
5. Can requests be raised through the connector, and where do they land? A request that becomes a governed record in your existing workflow is useful. A request that arrives as free text in somebody's inbox is a step backwards.
   
   

If your risk team wants the wider frame around AI access to regulated data, The Executive Guide to AI Risk Management covers the governance side in more depth.

Why does your data foundation decide the quality of the answer?

A connector exposes whatever data model sits behind it, so the answer quality is decided before the AI is involved. Where contracts, third-party risk findings, performance and spend live on one record, one question produces one complete answer. Where they are spread across a shared drive, a spreadsheet and an ERP, you get several fast partial answers and no way to reconcile them.

Take a question a procurement lead asks most quarters: which of our third parties are up for renewal in the next ninety days, and which of those have an open compliance issue or an unresolved certificate. Answering it needs contract end dates, an open compliance issue and spend history joined on the same third party. Now picture that with three separate connectors. One returns renewal dates from the contract repository. One returns risk assessments from a questionnaire tool. One returns spend from finance. Each answers in seconds, and nothing tells you that "Acme Ltd", "Acme Limited" and "ACME (UK)" are the same supplier, because no system was ever responsible for knowing that.

Point solutions can make each silo faster. Only a unified vendor and contract data foundation makes the answer whole, which is why vendor management software built on a single data model gives an AI assistant something four connectors cannot assemble after the fact.

"The connector is the door. The record behind it is the thing worth having."

What can you do with the Gatekeeper MCP?

The Gatekeeper MCP connects your Gatekeeper tenant to Claude, ChatGPT, Gemini or any other application that supports MCP, so you can read contract and third-party data, and create and update records, inside the permissions you already hold. Access follows your existing Gatekeeper role, so connecting an AI tool does not widen anyone's access.