What is an enterprise connector?
An enterprise connector is a pre-built link between a platform and a source system. It stores the access credentials. It translates the source's structure into a form the platform understands. It keeps both systems in sync. It adds no capability the source system lacks.
That last point matters because connector marketing often implies otherwise. A connector is a thin adapter over an existing interface, so if the source API cannot tell you when a record was deleted, neither can the connector. The integration standardises access to a system's capabilities rather than extending them.
Three jobs, and the third is where connectors differ most from each other.
- Authentication. Holding credentials, refreshing tokens, and ideally carrying the requesting person's identity through rather than reading everything as one service account.
- Schema mapping. Translating the source's field names, types and relationships into the platform's model. This is where the ambiguity that later confuses an agent gets locked in, and it is rarely revisited.
- Synchronisation. Keeping the platform's view current, whether by full reload, incremental change capture, or event-driven updates. The difference between those three is most of the difference between a capable connector and a nominal one.
Why is the connector count a poor buying signal?
Because it measures the vendor's catalogue rather than your integration. Most organizations draw the large majority of agent-relevant data from a handful of systems, so what matters is whether those specific sources are handled well. A long list of shallow implementations is worth less than a short list that covers your estate properly.
The figure persists because it is easy to state and hard to dispute. It is also close to unfalsifiable: nobody audits whether every entry in a catalogue supports incremental sync, deletion propagation and permission capture, and in practice a good many do not.
- Breadth and depth are independent. Adding a connector that reads a system's primary object is a small piece of work. Handling its deletions, its permission model, its rate limits and its schema changes is most of the work, and a count does not distinguish the two.
- Your list is short. A handful of sources usually account for nearly everything an agent needs. Whether those specific ones are supported well is a different question from how many exist in total.
- A count is a roadmap statement. It tells you where a vendor has invested breadth, which is genuinely useful information about the vendor. It is not information about whether your integration will work.
What actually distinguishes a good connector?
Five properties, none of which appears in a catalogue listing. Whether it syncs incrementally, whether deletions propagate, whether it captures the source's permission model, whether it survives a schema change, and whether its actual freshness matches the decisions being made on it.
Put these in a proof of concept rather than in a requirements document, because the measured answer often differs from the documented one.
| Property | What to ask | What breaks without it |
|---|---|---|
| Incremental | Does it fetch only what changed, and how does it know? | Full reloads too expensive to run often, so freshness degrades quietly |
| Deletion | When a record is deleted at source, what happens here, and how fast? | Your platform retains content the source removed. The most consequential gap |
| Permissions | Does it capture who could see each record, or read everything as one account? | Retrieval can return records the requester was never entitled to see |
| Schema drift | What happens when the source adds, renames or retypes a field? | Silent failure, or a stopped pipeline nobody notices for a week |
| Freshness | What is the measured lag, at your volume, not the advertised one? | Decisions made on a view of the world that is hours old without saying so |
The permissions row is the one most often deferred and the one that ages worst. A connector reading everything under a single service account produces a platform where access control has to be reapplied afterwards by filtering, which works until the filter logic changes. Capturing the source's permission model at read time means the constraint travels with the record, which is the argument set out at agent identity.
What changes when an agent reads through one?
The tolerance for every one of those gaps drops sharply, because an agent acts on what it reads rather than presenting it to somebody who might notice. A stale record on a dashboard is a person seeing an old number. The same record reaching an agent is an action taken on a fact that expired.
The connector does not change. What changes is the consequence of its shortcomings, and the deletion gap is the clearest example.
- Deletion becomes a compliance question rather than a freshness one. Content deleted at source and retained in your index is content you are still processing. An agent acting on it produces a decision based on a record somebody asked you to remove.
- Permissions become enforcement rather than presentation. A dashboard filters what it shows. An agent retrieves what it can reach, then acts. If the connector never captured who could see a record, retrieval has no basis to exclude it.
- Freshness becomes decision latency. A person reading a four-hour-old figure often knows it is four hours old. An agent has no such intuition, so lag has to be recorded as data rather than assumed as context.
- Schema drift becomes silent wrongness. A renamed field that breaks a dashboard is visible. A renamed field that quietly returns nulls produces confident answers built on absent data.
The upstream framing for all four is covered at data ingestion, which treats the connector boundary as a trust boundary: what you fail to capture there is unrecoverable afterwards. And whether the fields coming through mean the same thing across systems is the separate question handled at data intelligence.
How do connectors relate to MCP?
They sit on opposite sides of the platform. A connector brings a source system's data into the platform. The Model Context Protocol standardises how an agent reaches a tool. One is source to platform, the other is agent to tool, and conflating them is common.
The confusion is understandable because both are described as integrations and both reduce bespoke engineering. The distinction matters when you are deciding what to build.
| Layer | What it standardises, and what it does not |
|---|---|
| Enterprise connector | How a platform reads a source system: credentials, schema, sync. It says nothing about how an agent then reaches that data, and it is usually vendor-specific rather than an open standard |
| Model Context Protocol | How an agent discovers and calls a tool or reads a resource, as an open standard. It says nothing about how the data got into the system behind that tool. See MCP |
Both are thin adapters over existing APIs, which is the property they genuinely share. Neither adds capability the underlying system lacks, and neither resolves whether the data means what an agent will assume it means.
One practical consequence. An MCP server exposing a poorly built connector inherits every one of that connector's gaps, and adds a trust decision on top of them, because a tool description is text a model reads as instruction. Standardising the agent-facing interface does not improve what is behind it.
How should you evaluate the connectors?
Evaluate connectors on your own systems in a proof of concept. Do not judge them by a vendor's list or demo. Pick the few sources your live use cases read. Then test how each connector handles them under real conditions. Score each one against the five properties your team has defined. This narrow test predicts production far better than a long catalogue does.
Five steps, and the first one eliminates most of the work.
-
List the sources that actually matter
Usually far fewer than the requirements document suggests. Which systems do your live or imminent use cases read? Everything else is optionality you are paying to evaluate.
-
Delete a record and time the propagation
The highest-value test on this page and it takes minutes. Delete a test record at source, then check whether and when it disappears from the platform's view. If the answer is never, you have found the thing that matters most before signing anything.
-
Check whether permissions came through
Query as two users with different entitlements and see whether the results differ. If they do not, the connector read everything as one account and your access control is a filter applied afterwards.
-
Rename a field and see what happens
Schema drift is inevitable and the failure mode is what matters. A connector that stops loudly is manageable. One that returns nulls silently produces confident answers built on absent data.
-
Measure the actual lag under load
At your volume rather than in a demo dataset, and record the number. An agent needs freshness expressed as data it can reason about, not as an assumption somebody made during procurement.
One note on how to read vendor answers. A vendor who tells you their connector does not propagate deletions on a particular source is giving you accurate information about a real API limitation, and that is more useful than one who says every connector supports everything. The specific answer is the signal. The catalogue size is not.