Connector counts are easy to compare, which is why vendors publish them. GoSearch supports more than 100 connectors, but that number only tells you which apps can be searched, not what a search will return. That comes down to how each app connects. Google Drive has a shared connector and a private one. Notion has those two plus an MCP connector. Salesforce has indexed, federated, and MCP connectors. Same app, different wiring, different results.
If you’re evaluating an enterprise search platform or tracking down a document that won’t show up, start with connector type. It determines whether a file appears, how fast, and who can see it.
Indexed Connectors: A Pre-Processed Copy
An indexed connector makes a copy of your data, processes it, and stores it in the search platform’s environment. This is how the AI enterprise search category started, and it’s still how several vendors operate.
Indexing is fast at query time because the work happens ahead of the query. The trade-off is freshness. Every index refreshes on a schedule, and a schedule means a delay.
An index works like a printed phone book: quick to flip through, but missing anyone who moved in after it went to print.
GoSearch runs a partial re-index every five minutes, which picks up changes to existing resources: edits to document bodies, permission changes, metadata updates. Net-new resources work differently. A document created after the last full re-index isn’t in the index yet, and partial re-indexes skip it. It shows up in search after the next full re-index.
So when a brand-new doc isn’t searchable, that’s usually not a bug. That’s the re-index cycle.
GoSearch indexes up, not down
The other half of the indexing conversation is permissions. Some platforms index everything they can reach and then hand the customer an access control list to maintain. That works until access changes. Remove someone from a shared folder, and search can keep showing them its files until someone updates the list by hand. That’s how sensitive data ends up in front of people who shouldn’t see it.
GoSearch takes a narrower approach and indexes at the lowest permission level. If a resource is available to everyone in the organization, it goes in the shared index. If it isn’t, it doesn’t.
For example, an admin might find certain Google Drive files through a private connector but not the shared one. The admin thinks the folder is shared with the whole company, but only a few people have access. The connector is doing its job. The sharing setting isn’t what the admin expected.
Knowing how the connector works makes this a two-minute check instead of an escalated support ticket.
The Vendor Risk in an Index-First Architecture
Indexing carries a second risk that has nothing to do with freshness: you don’t control the APIs your index depends on.
Slack, which Salesforce owns, is a recent example of an app restricting how outside tools can use its data. In May 2025, Salesforce updated the Slack API Terms of Service to prohibit bulk export of message and file data by third-party applications, along with the creation of persistent copies, archives, or indexes of that data. Third parties were pointed to Slack’s Real-Time Search API instead, which returns results at query time rather than supporting a stored index. Vendors that had built on bulk ingestion had to re-architect.
GoSearch shifted its shared Slack connector to the real-time API. Figma has moved in a similar direction, with rate-limited REST access and MCP access restricted to an approved client catalog.
If you’re running a build-versus-buy analysis, weigh this carefully. An index-first architecture is a bet that source vendors won’t change their data access rules. When they do, the connector breaks. Search stops returning that app’s data, and your team has to rebuild the integration on whatever access the vendor still allows.
Real-Time Federated Connectors: Read Fresh, Store Nothing
A real-time federated connector skips the copy entirely. When a user searches, the platform makes an API call to the source system, fetches the result, and returns it. The platform stores nothing. Instead of checking the phone book, you call the person directly.
Federated connectors predate MCP and solve a narrower problem, but the underlying idea is the same one MCP later standardized: go get the data where it lives instead of copying it.
Two things change when you work this way.
Data stays in the source app. Security reviews often start with a question: where will the vendor store customer data? With federated connectors, the vendor doesn’t store it. There’s no copy to breach, retain, or delete during offboarding.
Permissions defer to the source system. Federated connectors run on the individual user’s credentials. What you can see in Jira is what you can see in Jira through search. IT and security teams don’t maintain a mirrored access control list, because there’s no second system holding the data. In index-everything deployments, maintaining those lists becomes an ongoing operational cost — in some organizations, a dedicated headcount.
Indexed and federated connectors can also work together in a hybrid architecture. GoSearch, for example, indexes shared company knowledge for speed and queries personal and sensitive data in real time through federated connectors, so that data stays in the source app.
MCP Connectors: The Write Layer
MCP connectors work like federated connectors: real-time calls, each user’s own credentials, and no index. The difference is in what they do.
Federated connectors read. MCP connectors act. Need to create a Linear issue, update a Notion page, or delete a document? That’s the MCP layer. Anthropic introduced the Model Context Protocol as an open standard, replacing the previous pattern of building a custom integration against every platform’s individual API. That shift also changed the economics of enterprise integrations.
That raises a fair question: if MCP can read data, why doesn’t it power search?
Technically it can. MCP servers can expose search tools, and under the hood, the Jira MCP hits the same Jira API the GoSearch federated Jira connector already uses. For the end user, the retrieval path is equivalent. GoSearch keeps them separate by design — federated connectors feed search results, MCP feeds GoAI and agents — which is why connecting Jira for search and connecting the Atlassian Rovo MCP are currently two distinct steps. Merging them is an architecture decision, not a protocol limitation.
Indexed vs. Federated vs. MCP Connectors Compared
The same document can show up through one connector, stay hidden through another, and lag behind in a third. Connector type determines which.
| Indexed | Real-time federated | MCP | |
|---|---|---|---|
| How data is accessed | Pre-processed copy stored by the platform | API call at query time | API call at query time |
| Freshness | Delayed by the re-index cycle | Current | Current |
| Powers search | Yes | Yes | Can, but built for actions |
| Takes action | No | No | Yes — create, update, delete |
| Permission model | Indexed at the lowest permission level | Individual user credentials | Individual user credentials |
| Data stored by the platform | Yes | No | No |
| Best for | Stable, org-wide content | Current results from personal and sensitive data | Taking action in connected apps |
How the Mix Shortens Security Reviews
Alongside hybrid search, MCP connectors power GoAI, agents, and no-code workflow automation, so users can act on what they find without leaving the search interface. The full mix also makes three recurring procurement conversations shorter.
Data residency. Minimal indexing means minimal replication. Security teams don’t have to approve a full copy of their data in a vendor’s cloud.
Access control. Permissions defer to the source system, so the customer isn’t maintaining a second access list and checking it against the source app.
Storage cost. Indexing everything carries real cloud storage expense, and that expense lands somewhere in the contract. Indexing less means less of it to pass along.
If you’re in the middle of an evaluation, ask every vendor you’re considering which connector type backs each app you use, how often the index refreshes, and what happens to results when a source vendor restricts its API. The answers will tell you more than the connector count on the pricing page.
Want to see how each connector type handles your own apps? Schedule a GoSearch demo to walk through permissions, freshness, and MCP-backed actions.
Search across all your apps for instant AI answers with GoSearch
Schedule a demo
Common Questions About Enterprise Search Connectors
What is the difference between an indexed and a federated search connector?
An indexed connector stores a pre-processed copy of your data in the search platform and refreshes it on a schedule. A federated connector queries the source system’s API when the user searches and stores nothing. Indexed connectors return results faster; federated connectors return results that are current.
Do MCP connectors replace enterprise search?
No. MCP connectors are built for actions — creating, updating, and deleting resources — rather than retrieval. In GoSearch, search runs on indexed and federated connectors, while MCP powers actions in GoAI and agents.
Why can’t I find a document I just created?
If the source application is connected through an indexed connector, net-new resources aren’t searchable until the next full re-index. Partial re-indexes pick up changes to existing resources, not new ones.
Who manages permissions with federated and MCP connectors?
The source system does. Both connector types run on the individual user’s credentials, so search returns only what that user can already access in the connected application. There’s no separate access control list for IT to maintain.
