Connectors, MCP and plugins explained: who builds the link, where the data lives, and can a custom MCP server stay private?

When I explain enterprise AI assistants to partners, three words keep getting mixed up: connector, MCP server and plugin. All three link an assistant to the systems a company already runs, all three can read data, and two of them can change data. So it is fair to ask whether they are the same thing with different labels.

They are not, and the differences matter as soon as security and networking teams join the conversation. A partner asked me a sharp version of the question recently: “Vendor-built connectors get private networking, perimeters and shared infrastructure. If I build my own MCP server, do I lose all that?” This post answers that question, from the fundamentals up.

In my earlier post, Plugins vs agents: what changed in August 2026, I explained skills, MCP servers, plugins and the Agent Plugins 1.0 standard. I won’t repeat that here. This post sits next to it and looks at the other side of the picture: how the assistant actually reaches your data, where that data lives, and which controls apply on the way.

What is the short answer?

A connector is an integration that a platform vendor builds and runs for you; an MCP server is an open, standard way to offer tools that anyone can build; a plugin is a package that carries skills and MCP settings into an AI tool. A connector and an MCP server can both read data and both take actions. A plugin carries neither data nor a network path; it carries instructions and settings.

The second distinction is about time. Ingestion copies data ahead of time, with its metadata and access controls, so answers are fast and permission-aware; federation and live MCP calls fetch at question time, so answers are fresher but slower.

And the partner’s question has a clear answer. As of November 2026, yes: in Gemini Enterprise a custom MCP server can sit on a private network with no public IP address, reached through an outbound gateway that places a network interface inside your own network, and it can work inside a security perimeter once an administrator allows it. What you do not get is everything else a vendor connector brings, such as background indexing with permissions and someone else maintaining the integration. The rest of this post explains why.

What does this look like in a library?

Start with something everyone has used: a public library.

Books on the library’s own shelves. The library bought them, catalogued them and attached a note to some saying who may borrow them (the reference room is staff only). When you ask for a book, the librarian checks the catalogue and the note, and hands it over in seconds. That is ingestion: the platform copied the content into its own index (the catalogue), together with its metadata (author, date, subject) and its access control list (who may borrow it).
The librarian phones another library. If the book isn’t on the shelf, the librarian rings the other library, waits while someone looks, and reads you the answer down the phone. That is federation, and it is also what a live MCP read looks like: nothing is copied, the answer is current, it takes longer, and the other library hears your question.
The reservation form. You fill in a form and hand it to the librarian, who reserves or orders a book for you. Nothing is looked up; something is changed. That is an action.
Two kinds of delivery. The library has a contract with a branded delivery service that uses the library’s own loading bay, security desk and van fleet. You could also hire your own courier. That is the difference between a vendor-built connector and a custom MCP server. Your courier can use the same back gate, but only if the library issues it a pass, and you pay the courier and fix its van.

Here is the timing catch, with small numbers. Suppose the catalogue is updated every three hours, at 09:00 and 12:00. A book is returned at 09:15. If you ask at 10:30, the catalogue still says “on loan” until the 12:00 update. Phoning the shelf directly would have told you it was back. That gap between when something changes and when the copy catches up is the price of ingestion’s speed.

The comparison stops working in one place: a real librarian checks your library card in person. In software, the “card” is a token that has to travel with every request, and getting that right is most of the security work later in this post.

Who is the running example?

Harbourside Insurance is a fictional mid-size home and motor insurer with around 1,200 staff. It is made up for this post, so every name and number below is illustrative. Harbourside wants its claims handlers to ask an AI assistant questions in plain English. It has six systems the assistant would need:

Claims manual and underwriting guidelines: about 40,000 pages in Confluence Cloud. Some pages are restricted to the fraud team.
Broker and customer records in Salesforce, the company’s customer relationship management (CRM) system.
IT and claims-operations tickets in Jira Cloud.
Claims analytics tables in BigQuery.
PolicyCore, a 15-year-old policy administration system in Harbourside’s own data centre, with no public API.
A flood-risk data service run by a third party, which only accepts calls from IP addresses on its allowlist.

One claims handler, Priya, will ask the same question all the way through: “Is policy HB-20391 covered for storm damage to a garden wall, and where is claim CL-88412 up to?”

What do the words actually mean?

What is a connector?

Simple definition first: a connector is a ready-made link between an AI platform and one other system, built and run by the platform vendor or one of its partners. You switch it on, sign in, and the assistant can use that system.

The more formal definition: a connector is a managed integration that authenticates to a source system, reads and sometimes writes its data through that system’s APIs, and presents the results to the assistant in a form it understands. Breaking that down:

Managed: the vendor writes the code, keeps up with the source system’s API changes and runs the infrastructure.
Authenticates: it holds or obtains credentials for the source system, often the signed-in user’s own OAuth token.
Reads and sometimes writes: which leads to the two kinds.

A data connector brings information in so the assistant can answer questions. An action connector lets the assistant change something in the source system: create a ticket, update a record, send a message. Many products do both from one connector.

At Harbourside, this is how it would work. The Salesforce connector, as a data connector, finds the broker record for policy HB-20391. As an action connector, it adds a note to that record saying the customer called about storm damage. Same system, same sign-in, one read and one write.

One warning about the word itself. “Connector” is overloaded. The MCP specification uses it for the client side of MCP (“Clients: Connectors within the host application”), and some AI apps call any MCP server you add a connector. In Gemini Enterprise, the documentation says “data store” can be used interchangeably with “connector” or “data connector”. When someone says connector, it is worth asking which one they mean.

What is the difference between ingestion and federation?

This is the most important distinction in the post, so here it is with both sides.

Ingestion (also called indexing) copies content from the source system into the platform’s own search index ahead of time, together with its metadata and its ACL. Scheduled sync jobs keep the copy up to date. At question time, the platform searches its own index and filters out anything the user may not see, before the model reads a word.

Federation copies nothing. At question time, the platform sends the user’s query to the source system’s own search, waits for results, and merges them with results from anywhere else.

Here is a worked example at Harbourside. The claims manual page “Garden walls and fences” is updated at 09:10 to say storm damage to walls is covered only if the wall was in good repair. The connector’s incremental sync last ran at 09:00 and runs every three hours. Priya asks at 10:30.

Ingested (index copy from 09:00)
  1. Search index for "garden wall storm damage"     -> old page version, ranked first
  2. Filter by Priya's groups (synced ACL)            -> allowed: claims-handlers
  3. Model writes answer from the 09:00 text          -> misses the new "good repair" rule

Federated (live)
  1. Send "garden wall storm damage" to Confluence    -> current page, 09:10 version
  2. Confluence checks Priya's own token              -> allowed
  3. Model writes answer from the current text        -> includes the "good repair" rule

The ingested path was faster and the index ranked results well, but it was 90 minutes behind. The federated path was current, but every question waited on Confluence. Who decided what Priya could see also differed: with ingestion, the platform enforced the ACL it had copied; with federation, the source system enforced its own permissions on Priya’s token.

What is an MCP server, and what are its tools?

MCP (Model Context Protocol) is an open protocol for connecting AI applications to tools and data. The current revision of the specification, dated 28 July 2026, describes three roles: a host (the AI application), a client inside the host, and a server that offers capabilities. Messages use JSON-RPC, a simple format for asking another program to run a named method.

An MCP server can offer three kinds of capability: resources (data for the user or model), prompts (templated messages) and tools (“functions for the AI model to execute”). Tools are the part that matters here. A tool has a name, a description and an input schema (the arguments it expects). A client discovers tools by sending tools/list and runs one by sending tools/call.

Because a tool is just a function, it can read or it can act. One MCP server can play both the data role and the action role that connectors split in two.

At Harbourside, this is how it would work. The integration team writes a small PolicyCore MCP server with three tools: get_policy, get_claim_status and add_claim_note. When Priya asks about her claim, the assistant sends:

{ "jsonrpc": "2.0", "id": 7, "method": "tools/call",
  "params": { "name": "get_claim_status", "arguments": { "claim_id": "CL-88412" } } }

and the server replies with something like:

{ "jsonrpc": "2.0", "id": 7,
  "result": { "content": [ { "type": "text",
    "text": "{\"claim_id\":\"CL-88412\",\"stage\":\"loss adjuster visit booked\",\"visit_date\":\"2026-11-12\"}" } ] } }

That status is live: PolicyCore answered at that moment, and nothing was copied anywhere beforehand.

The key difference from a connector is who builds it. The protocol is open, so anyone can write a server: you, a partner, or the vendor of the source system. And the two are not rivals. In Gemini Enterprise, the Salesforce documentation says “Gemini Enterprise sends your search query directly to the Salesforce MCP server”, and the BigQuery federated data connector’s identifier is bigquery_mcp. A vendor connector can use MCP underneath; MCP is the wire, and the connector is the managed product built on it.

Where does a plugin fit?

A plugin is a folder that bundles skills (written instructions for a task) with MCP server settings, so both can be installed into an AI tool in one go. My plugins post covers the format in detail.

What matters here is what a plugin does not carry. It holds no data, no index, no network route and no credentials (the standard says secrets must not live in its configuration). At Harbourside, a claims-triage plugin could hold a skill with the five steps of a coverage check and an mcp.json pointing at the PolicyCore MCP server. Installing it teaches the assistant how to do the job and where the tools are. It does not make PolicyCore reachable from the internet, and it does not decide who may call it. Those problems are solved where the MCP server runs.

How do the pieces fit together?

four ways an AI assistant reaches a business system: an ingestion connector copies content, metadata and ACLs into an index ahead of time; a federated connector asks the source at question time; an action connector changes something in the source; an MCP server offers tools of either kind over one open protocol

Ingest, federate or call live: what do you trade?

Each approach wins on some dimensions and loses on others. Here are the five I walk through with partners, each on Harbourside.

Latency. An ingested index answers from inside the platform, so it is usually the quickest. Federation and live MCP calls add latency: a network round trip to the source system on every question, and they are only as fast as that system. If PolicyCore takes two seconds to answer, so does every question that needs it.
Freshness. Ingested data is as fresh as the last sync. Federation and live MCP calls are current to the second. A claim status that changes every hour belongs on the live side; a claims manual that changes a few times a month can be ingested.
Answer quality. An index built for search can rank results well across many sources. Gemini Enterprise’s own documentation puts it plainly: federation means “search quality might be lower”, while ingestion “can result in improved search quality” but “consumes more storage and time”.
Cost. Ingestion costs storage plus the work of the sync jobs, paid whether or not anyone asks. Federation and live calls cost nothing up front but hit the source system on every question, which can run into its API rate limits on a busy morning.
Permissions. Ingestion copies the ACLs and must keep them in step with the source. Federation and MCP leave the check to the source system, using the user’s own token. Both can be correct; they fail in different ways, as the “What can go wrong” section shows.

There is also a privacy point for federation. Gemini Enterprise’s documentation notes that with federated search, “your query string is sent to all enabled third-party search backends”, that it “might contain parts of the data in your search request and conversation history”, and that the third party “can link the query with your identity”. Ingestion sends nothing to the source at question time.

Here is a small timing example. These numbers are illustrative, chosen to show the shape of the trade-off, not measured from any product.

Ingested index      search own index 0.3 s  + model writes 1.5 s                    = 1.8 s
Federated search    source search    1.0 s  + model writes 1.5 s                    = 2.5 s
Live MCP tool       model plans      0.8 s  + tools/call 0.9 s + model writes 1.5 s = 3.2 s
Live MCP, 2 tools   0.8 + 0.9 + 0.8 + 0.9 + 1.5                                     = 4.9 s

The MCP row has an extra step because the model first has to decide which tool to call and with which arguments. With an index or federated search, the platform runs the search itself before the model writes.

one question, three ways, with illustrative timings: an ingested index answers fastest but only as fresh as its last sync; federation and live MCP calls are current to the second but add a network round trip, and MCP adds a planning step

So when does each one fail, and when does it win?

Ingestion fails when the data changes faster than the sync. If Harbourside ingested claim statuses on a three-hour schedule, Priya would tell a customer the adjuster had not been booked when it had. Ingestion wins for the claims manual: 40,000 pages, permission-sensitive, changing slowly, searched hundreds of times a day.
Federation fails when the source search is weak or slow, or when the query should not leave the company. Federation wins for Jira tickets the operations team updates all day.
Live MCP fails when a question needs a broad search across thousands of documents; a tool that returns one record at a time is the wrong shape. Live MCP wins for PolicyCore: precise lookups of one policy or one claim, and the ability to write a claim note.

How do you keep the path private and safe?

Before looking at any product, here are the five controls security teams usually ask about, in generic terms.

Private connectivity. The AI platform reaches your system without it having a public IP address. Typically the platform places a network interface inside your private network, or you connect over a private link.
A perimeter. A boundary around the platform’s APIs and your data, so data cannot be copied to a project or service outside it, even by someone holding valid credentials. On Google Cloud this is VPC Service Controls.
An egress allow-list. A list of destinations the platform may call out to. Anything not on the list is refused, which stops a tool from quietly sending data to an unknown server.
Two identities on every call. The service identity proves which platform is calling (for example a signed ID token for the platform’s own account). The user’s delegated token proves who is asking, so the source system can apply that person’s permissions. The MCP authorisation specification covers the second layer: a protected MCP server acts as an OAuth 2.1 “resource server”, and the client presents an access token on behalf of the user.
Certificate trust. The platform must trust the server’s TLS certificate. Internal systems often use certificates from a private certificate authority, which public clients do not trust by default.

This is exactly where vendor-built connectors have their head start. The vendor wires these controls once, for every customer. In Gemini Enterprise, for example, Google’s documentation notes that first-party connectors “communicate directly over internal Google APIs, so their endpoints are automatically permitted” when the connector is allowed, with no egress domains to add. The Salesforce connector offers a Google-managed OAuth option that installs a package from Salesforce AppExchange, so you don’t need to create your own client ID. With a custom MCP server, you wire each control yourself. The question is whether the platform lets you.

Which one do I use?

Here is the test I use, cheapest option first:

Is there a vendor-built connector for this system? Use it. Someone else maintains the integration, the authentication and the permission mapping.
Is the job a search across lots of content where permissions matter? Ingest it, through the vendor connector if it offers ingestion, or through a custom ingestion connector if not.
Must the answer be current to the minute? Federate, or offer a read tool on an MCP server.
Does the user need to change something? Use an action, from the connector if it has one, or a tool on your MCP server, and make sure it runs on the user’s token.
Only then, build a custom MCP server for systems no connector reaches, and put it on a private path from day one.
If the same know-how must work in several AI tools, package the skills and MCP settings as a plugin. If the logic itself is what you sell, keep it in your own agent, as the plugins post explains.

which do I use? seven common jobs, the pattern that fits each and why: ingest for permission-aware search over lots of content, federate or call live for data that changes by the minute, actions for changes, vendor connectors where they exist, custom MCP or a custom connector where they do not, and a plugin to carry know-how across AI tools

How does this map to Gemini Enterprise?

Everything in this section comes from Google’s public documentation and release notes, linked at the end, and is correct as of November 2026.

Data connectors. Gemini Enterprise calls each connected source a data store. Many third-party connectors let the administrator choose: the Confluence Cloud and Jira Cloud setup pages, for example, offer “Data ingestion or Federated search” as the connector mode. Ingested data stores run on sync schedules. Incremental syncs of added or updated content run every three hours by default, and the documentation notes that an incremental sync “does not sync identity data or deletions of entity data”. Those arrive with a full sync, which can be scheduled from every three hours to every seven days for content, and from every 30 minutes for identity data.

Data Cloud connectors. AlloyDB for PostgreSQL, BigQuery, Cloud SQL and Spanner can be connected in federated query mode, in Preview since 2 October 2026. The data stays where it is and is queried in place.

Action connectors. Actions are switched on per data store. The Salesforce data store, for example, offers actions such as Create Sobject Record and Update Sobject Record, and the documentation says to leave them unselected to keep the connector read-only.

Custom MCP server data stores. Generally available since 7 August 2026. The documentation’s own glossary helps: “In the Model Context Protocol (MCP) specification, capabilities are called tools. In Gemini Enterprise data stores, these tools are referred to as actions.” The requirements worth knowing early:

The server must use the Streamable HTTP transport; SSE is not supported.
Up to 100 actions can be enabled at a time.
Authentication is OAuth 2.0 (Gemini Enterprise is registered as an OAuth client of your identity provider) or none.
For a Cloud Run service on its default .run.app address, Gemini Enterprise sends two headers: X-Serverless-Authorization with “a Google-signed ID token that authenticates the Gemini Enterprise service agent”, and Authorization, which “preserves the user’s OAuth token intact”. That is the two-identity pattern from the previous section, built in. It does not apply to custom domains.
Creation is blocked by default by a managed organisation policy constraint that an Organization Policy Administrator must turn off.

Custom connectors. These are a different thing from custom MCP. A custom connector is your own ingestion pipeline: it fetches documents, metadata and permissions from a source, transforms them into the Discovery Engine document format with their ACLs, and syncs them into a data store on a schedule. Use it when a home-grown system needs permission-aware search over many documents.

Agent Registry. Since 25 June 2026 (generally available), an administrator can import MCP servers from Agent Registry into a Gemini Enterprise app, where they are added as connected data stores, and apply allow and deny egress policies to them through Agent Gateway (explained in the next section).

Citations for custom MCP. Since 16 October 2026 (generally available), you can make answers built from your MCP tools show source citation chips. Because every server returns its own JSON shape, you tell Gemini Enterprise where to find each result’s link, title, snippet and ID using JSON Pointer paths, through the v1 REST API only. For PolicyCore’s get_policy tool, the mapping would look roughly like this (the structure follows the documentation; the field names are Harbourside’s):

{ "get_policy": { "items": "/documents", "uri": "/url", "title": "/title",
                  "snippet": "/summary", "id": "/document_id" } }

Can a custom MCP server be as private as a vendor-built connector?

Yes for the network path and the perimeter; no for indexing and maintenance. Here is how the private path works, step by step.

Gemini Enterprise’s documentation starts from the default: “By default, Gemini Enterprise can’t access resources hosted inside private networks.” The fix is the Egress Agent Gateway, a regional gateway that governs outbound traffic from Gemini Enterprise. It reaches into your network through a Private Service Connect interface: a network interface that a Google-managed service places inside your VPC network, so the service can open connections into your network (the opposite direction to a normal Private Service Connect endpoint, where you call out to a service). The setup has three resources:

A network attachment in your VPC network, which tells Google which of your subnets the interface may use. The subnet must be in the region matching the app (us-central1 for global or us apps, europe-west1 for eu apps), at least a /28, with Private Google Access turned on.
An agent connectivity template that points at the network attachment and sets DNS peering for private names, the egress mode (PRIVATE_RANGES_ONLY, the default, or ALL_TRAFFIC) and, optionally, a tlsConfig that trusts your private certificate authority or a self-signed certificate.
An Agent Gateway that references the template. A Gemini Enterprise app binds to one egress gateway, and several apps can share it.

The documentation lists three uses: a private MCP server with no public IP address; “hybrid and multicloud connectivity” to servers on-premises or in other clouds through your network; and static IP egress to a public MCP server through Cloud NAT, so a third party can allowlist your addresses. This became generally available on 27 October 2026, in us-central1 and europe-west1.

the private path for a custom MCP server in Gemini Enterprise: the app sends query-time tool calls through the Egress Agent Gateway, which reaches your VPC network through a Private Service Connect interface; from there traffic can reach a private MCP server, an on-premises system over a hybrid link, or a public server through Cloud NAT; ingestion jobs, model calls and RAG retrieval do not go through the gateway

Inside a VPC Service Controls perimeter, Google’s documentation says you “must configure a VPC Service Controls perimeter” to properly secure an app and reduce the risk of data exfiltration. Once the perimeter is on, existing data stores keep working, but creating new ones is blocked until an administrator allows them in two managed constraints. For a custom MCP server, the documentation’s own example sets three things: turn off the “Disable custom MCP server connector for Gemini Enterprise” constraint, add custom_mcp to allowedDataSources in “Restrict allowed data sources for data connectors”, and add the server’s host name to allowedEgressFqdns in “Restrict egress domains for data connectors”. That last list is the generic egress allow-list from earlier, made concrete.

So what still differs from a vendor-built connector?

Who builds and maintains it. You write the server, patch it, scale it and keep its tool descriptions clear. The vendor does that for its connectors.
Authentication. You register Gemini Enterprise as an OAuth client of your identity provider and decide how the server checks tokens. Vendor connectors often offer a managed sign-in.
No background indexing. A custom MCP server is called live at question time. If you need permission-aware search over many documents, you need ingestion: a vendor connector that ingests, or a custom connector.
What the gateway covers. The documentation is precise: Agent Gateway governs egress “exclusively for outbound query-time tool execution to custom MCP servers, action connectors, and agents. It doesn’t proxy generative model inference calls, knowledge data store retrieval (RAG), built-in assistant tools, or connector ingestion jobs. Inbound traffic into Gemini Enterprise isn’t supported.”
Regions and limits. The egress gateway is in us-central1 and europe-west1 only; Streamable HTTP only; up to 100 enabled actions.
Encryption keys. Be careful here. Gemini Enterprise’s CMEK page covers apps, data connectors and end-user data, and warns that anything created before the key is registered “will remain unprotected”. It does not mention custom MCP data stores by name. With MCP and federation, the source data stays in your system, under its own encryption; what lands in Gemini Enterprise is what its keys can protect; the Data Cloud connectors page says this explicitly, listing “query results returned to the agent and stored in conversations”. Check coverage for your configuration before promising anything.

How would Harbourside wire it up?

Here is how Harbourside would map its six systems, using the decision guide above.

System                        Pattern                         Why
Claims manual (Confluence)    Vendor connector, ingestion     40,000 pages, ACLs matter, changes slowly
Broker records (Salesforce)   Vendor connector, federated     live records; create-note action on user's token
Ops tickets (Jira)            Vendor connector, federated     updated all day; read plus create-issue action
Claims analytics (BigQuery)   Data Cloud connector, federated data stays in BigQuery; Preview, so pilot only
PolicyCore (own data centre)  Custom MCP, private path        no connector, no public API; live lookups and notes
Flood-risk service (3rd pty)  Custom MCP, Cloud NAT egress    provider allowlists Harbourside's static IPs

For PolicyCore, the MCP server runs on an internal address in Harbourside’s VPC network in europe-west1, matching the eu app and the gateway region. It reaches PolicyCore in the data centre over its existing Cloud Interconnect link (a dedicated private connection between the data centre and Google Cloud). Its certificate comes from Harbourside’s private certificate authority, trusted through the connectivity template’s tlsConfig. The administrator adds custom_mcp and the server’s host name to the two constraints, because the project sits inside a VPC Service Controls perimeter.

Now Priya’s question, end to end (timings illustrative):

Priya: "Is policy HB-20391 covered for storm damage to a garden wall,
        and where is claim CL-88412 up to?"

1. Search ingested claims manual          "garden walls" page, filtered by Priya's ACL     0.3 s
2. Model plans                            needs policy terms and claim status               0.8 s
3. tools/call get_policy(HB-20391)        gateway -> PSC interface -> MCP -> PolicyCore     0.9 s
4. tools/call get_claim_status(CL-88412)  same private path                                 0.9 s
5. Model writes the answer                cites the manual page and the policy schedule     1.5 s
                                                                               total about 4.4 s

Steps 3 and 4 run on Priya’s token, so PolicyCore only returns policies she is allowed to see. Step 1 is the only one that could be stale, and only for the claims manual, which is why the manual was the right thing to ingest.

What do people get wrong?

“MCP replaces connectors.” It doesn’t. MCP is a protocol; a connector is a managed product. Vendor connectors can and do use MCP underneath, as the Salesforce and BigQuery examples show. What MCP changes is that you can build your own when no connector exists.
“A custom MCP server can’t be private.” As of 27 October 2026 it can, through the Egress Agent Gateway and a Private Service Connect interface, including on-premises systems over hybrid links.
“Federated means less secure.” Federation keeps the data in the source and lets the source enforce its own permissions on the user’s token, which many security teams prefer. Its real costs are speed, ranking quality and the fact that query text reaches the third party.
“Ingested means up to date.” Ingested means as fresh as the last sync, and deletions and permission changes may wait for a full sync.
“Installing a plugin connects the assistant to my data.” A plugin tells the assistant how to work and which MCP server to call. Reaching that server, and deciding who may call it, happen elsewhere.

My view: start every system with the question “ingest or live?” before “connector or MCP?” The first question decides speed, freshness and permissions; the second mostly decides who maintains the code. For most enterprises the answer is a mix: vendor connectors with ingestion for documents, federation and actions for busy SaaS systems, and a small number of custom MCP servers on a private path for the systems only they own.

One honest gap: the private path covers query-time tool calls only. Ingestion jobs, model calls and RAG retrieval take other routes, so a security review has to look at each path separately, and a custom MCP server still gives you no permission-aware index. If you need both private networking and ingested, ACL-aware search over a home-grown system, you are building a custom connector as well, and that is real work.

What can go wrong?

Stale permissions. Someone leaves the fraud team at 09:05, but the identity sync runs at 09:30. Until then, the ingested index still treats them as a member. Set identity syncs as frequent as your risk needs.
Deleted content lingers. Incremental syncs don’t pick up deletions; a withdrawn guideline can keep appearing until the next full sync.
Region mismatch. The gateway, the connectivity template and the subnet must all be in us-central1 or europe-west1, matching the app. The MCP server itself can live elsewhere, as long as your VPC network can route to it.
Creation blocked, nobody knows why. Custom MCP is off by default, and a VPC Service Controls perimeter blocks new data stores until both constraints list the data source and its domains.
Certificate errors. Without the gateway, the server needs a certificate from a publicly trusted authority. With it, a private CA works only if the tlsConfig trusts it.
Too many tools. A server with 250 tools exceeds the 100 enabled actions, and vague tool descriptions make the model pick the wrong one. Fewer, clearly described tools work better.
Assuming the gateway sees everything. It governs outbound tool calls only. Ingestion and model traffic need their own review.
Custom domain on Cloud Run. The service-agent ID token is sent only to the default .run.app address, so a custom domain needs another way to authenticate the caller.

What did we learn?

A connector is a vendor-built, managed integration; an MCP server is an open way to offer tools that anyone can build; a plugin packages skills and MCP settings and carries no data or network path.
Ingestion copies content, metadata and ACLs ahead of time, giving fast, well-ranked, permission-aware answers that are only as fresh as the last sync; federation and live MCP calls are current but slower and depend on the source system.
Connectors and MCP are not rivals: connectors can be built on MCP, and both can read data and take actions.
Vendor connectors start with private connectivity, perimeter rules and managed sign-in already wired; with a custom MCP server you wire those controls yourself.
In Gemini Enterprise, a custom MCP server can be private through the Egress Agent Gateway and a Private Service Connect interface, and can run inside a VPC Service Controls perimeter once the constraints allow it, but the gateway covers only query-time tool calls.
Decide per system: “ingest or live?” first, then “vendor connector or custom?”.

What comes next?

The private path solves the network half of the problem; the identity half deserves its own post. In Production-ready agents, Part 7: Who is asking? Identity for agents I go deeper into how the user’s token and the service’s identity travel with each call. For how identity providers and sync schedules interact with Gemini Enterprise connectors, see Forward deployed engineering, Part 5: Enterprise integrations, APIs, connectors and identity.

Sources

Model Context Protocol specification, revision 2026-07-28 (hosts, clients, servers; resources, prompts, tools)
MCP specification: tools (tools/list, tools/call)
MCP specification: authorization (MCP server as an OAuth 2.1 resource server)
Agent Plugins: compatible clients
Gemini Enterprise: introduction to connectors and data stores (federation vs ingestion, sync schedules, federated query privacy note)
Gemini Enterprise: set up a Confluence Cloud data store and Jira Cloud data store (connector modes, actions)
Gemini Enterprise: set up a Salesforce data store (Salesforce MCP server, actions, managed OAuth)
Gemini Enterprise: secure Data Cloud connectors (federated query mode, bigquery_mcp, first-party endpoints)
Gemini Enterprise: manage actions
Gemini Enterprise: custom connectors overview (fetch, transform, sync with ACLs)
Gemini Enterprise: set up your custom MCP server data store
Gemini Enterprise: prerequisites for a custom MCP server data store with VPC connectivity (Egress Agent Gateway, Private Service Connect interface, Cloud NAT, what the gateway does not proxy)
Gemini Enterprise: override the organization policy for Custom MCP data stores
Gemini Enterprise: import MCP servers from Agent Registry
Gemini Enterprise: configure citations for custom MCP data stores
Gemini Enterprise: secure your app with VPC Service Controls
Gemini Enterprise: customer-managed encryption keys
Gemini Enterprise release notes (dates for custom MCP, Agent Registry import, citations, VPC connectivity, Data Cloud federated query mode)
Agent Gateway overview
About Private Service Connect interfaces

Opinions are my own. Every fact in this post comes from the public documentation linked above.