Why Federated Search is Still Relevant Today

Glean’s recent blog post, “Is MCP + federated search killing the index?”, makes a bold claim that federated search is on its way out. From our vantage point, not only is that premature—it misses what’s really happening in the world of search. 

Federated search isn’t dying. If anything, it’s more relevant today than ever. In fact, federated search and indexes are both core to any effective enterprise search strategy. And the emergence of protocols like MCP isn’t replacing either—they’re making them work better together.

What Really Is Federated Search? 

Federated search, at its core, means sending a user’s query to multiple data sources or applications in real time—without reindexing or storing all that data yourself. Classic examples include Vivisimo’s meta search, the Google Search Appliance’s “OneBox,” (think: “weather chicago”) and, more recently, Swirl AI’s platform. 

Why do enterprises lean on federated search? 

• • Security context: You can respect each source’s security without constantly syncing entitlements. 

• • Freshness: Get live results without waiting for the next crawl. 

• • Simplicity: Tap into SaaS apps or external search engines directly, sidestepping data gravity and API headaches. 

Federated search shines when direct reindexing isn’t practical, or when user context and permissions are hard to replicate. For instance, some platforms (like Jive) never exposed APIs to accurately reflect user access, making true enterprise search almost impossible without federated querying. Others (Salesforce, Microsoft 365) limit how often you can crawl, making near-real-time indexing and security syncing a fantasy. 

Federated Search is also very akin now to “Query Routing” that RAG workflows are using.  When you classify a query you can perform a real time look up in the system of record or perform a search against that system thereby increasing your precision.  

The Drawbacks—And Realities—of Federated Search 

Glean is correct that federated search is limited by the APIs and capabilities of the source systems. 
But let’s clarify what that actually means: 

• • API limitations aren’t new: This exists for federate search as well as when building a universal index.  This has always been the bottleneck—rate limits, incomplete data, security context, etc. 

• • Search quality varies: Most enterprise apps treat search as an afterthought, offering limited or low-quality search APIs. This is largely a ranking and relevancy problem—not an architecture flaw—and can often be addressed by reranking and enriching in the query pipeline. 

• • Connector fragility: A federated system is only as strong as its weakest connector or slowest API. However, every system has some type of means to query it, simply.  Universal indexes centralize monitoring and boost consistency—but at the cost of losing “live” freshness and full security fidelity. 

What’s not true is that federated search is only good for user-authenticated data. That’s simply incorrect or a misreading of the landscape—federated search can access and unify any data the underlying APIs permit. 

Everything Is Still an Index 

Glean’s article does highlight the power of a universal index: 

• • Consistent relevancy and ranking across all content. 

• • Centralized monitoring, control, and analytics. 

• • Unified experience for users and admins. 

But this comes with its own costs. The index is only as up-to-date and comprehensive as the connectors feeding it. If an API lags, or a data source blocks full crawling, the index loses value. 

Having written dozens of commercial connectors, we know these pains all too well. 

The real world? No single approach wins. Federated search and universal indexing are two sides of the same coin—each compensates for the other’s weaknesses.  The better your search index is, the better your federate search is and the better your MCP or RAG workflows perform. 

The Future: Federated Search + Universal Indexes + Modern Protocols 

At MC+A, we see the future as a blend of: 

• • (Universal) indexes where feasible for performance, relevance, analytics, and unified experience. 

• • Federated search as a central role for handling query routing, “live” access for hard to index, and dynamic security context. 

• • Smart query pipelines that can rerank, dedupe, and blend results from both methods. 

• • Emerging protocols like MCP that make it all composable and API-driven. 

The winners will be those who can combine these approaches—using each where it shines. 

What Is MCP—and What Isn’t It? 

The Model Context Protocol (MCP) is being touted as a game changer, but let’s be clear: 
MCP is a communication standard. 
It’s designed to let large language models (LLMs) interact with tools, data sources, and plugins—think of it as “USB-C for AI.” From the specification: 

“MCP is an open protocol that standardizes how applications provide context to LLMs. Just as USB-C provides a standardized way to connect your devices to various peripherals, MCP standardizes how AI connects to different data and tools.” 

That’s it. It’s not a replacement for searching. It doesn’t kill the index, or federated search, any more than ODBC killed relational databases. It just lets the parts talk to each other, faster and more flexibly. 

In Summary: The Next Generation of Search Is Hybrid 

There is simply no perfect solution.  Just like traditional Lexical Search, Federated search isn’t dead. It’s evolving, integrating, and getting better as standards like MCP bring more interoperability. Indexes remain foundational, but their limits are real—and federated querying is the antidote. 

The future of search in the enterprise isn’t either/or. It’s both. 

If your search strategy is betting on just one approach, you’re already behind.   Need help in deciding your strategy, Contact Us.