MCP & Federated Enterprise Search

Your retrieval stack, built carefully across the previous five modules, is now genuinely good, and it has a distribution problem. The sales team wants it available inside their chat app. Engineers want it inside their IDE. A new internal agent platform wants it exposed as a callable tool. Meanwhile your own agent, from Lesson 17, wants to reach systems you’ll never fully index: live ticket status, today’s Slack messages, the CRM’s current state. In the pre-2025 world, every single one of those pairings required a bespoke, hand-built integration, and platform teams routinely drowned under the resulting N-by-M connector matrix, where N systems needing to talk to M other systems meant N times M separate integration efforts to build and maintain.

The Model Context Protocol collapsed that matrix into something far more tractable. Anthropic open-sourced it in November 2024; through 2025 it was adopted by the other major model vendors and a long tail of developer tools, and by 2026, “do you have an MCP server?” has become the standard way enterprise software is asked “can my AI actually talk to you?”

What MCP actually standardizes

MCP is a client-server protocol in which servers expose three kinds of things to any compliant client: tools (callable functions described by JSON schemas), resources (readable content a client can fetch), and prompts (reusable prompt templates a server can offer). Clients, meaning assistants like Claude, IDEs, and various agent frameworks, discover what a given server offers at connection time, and the underlying model decides when to invoke what’s been discovered. Authentication matured significantly through 2025 into OAuth-based flows built into the protocol itself, which turns out to matter enormously for the permissions story covered in detail below.

For a RAG platform team specifically, MCP cuts usefully in both directions simultaneously, and both directions are worth actively building toward rather than picking just one:

• You as server: your carefully tuned two-stage, ACL-filtered, contextually enriched retrieval stack becomes a tool called search_knowledge_base, available identically across every MCP-compliant client the company happens to run. The many hours spent getting reranking right in Module 4 now silently improves the answer quality of an IDE assistant you’ve personally never even configured.
• You as client: your own agentic loop from Lesson 17 gains access to get_ticket, search_slack, query_crm, tools built and maintained by other teams entirely, reaching genuinely live data that your own index will never hold, no matter how good your sync pipeline gets.

Exposing the stack: a minimal server

# kb_server.py: your retrieval stack as an MCP server.
# pip install "mcp[cli]"  (the official Python SDK's FastMCP)

from mcp.server.fastmcp import FastMCP, Context

mcp = FastMCP("company-knowledge")

@mcp.tool()
async def search_knowledge_base(
    query: str,
    source: str = "any",     # confluence | drive | jira | any
    ctx: Context = None,
) -> str:
    """Search company knowledge. Returns top passages with
    titles, dates, and links. Refine and retry if results
    miss the target."""

    # THE line that keeps this from becoming a leak API:
    # resolve the END USER from the authenticated session,
    # never a service account. The user's ACL tags flow into
    # the same filtered retrieval as every other path.
    user = await resolve_user(ctx.session)

    chunks = await retrieve_and_rerank(
        query=query,
        source=None if source == "any" else source,
        acl=user.permission_tags,
        final_k=6,
    )
    if not chunks:
        return "No results. Try different terms or check source."

    return "\n\n".join(
        f"[{c.doc_title} > {c.section}]({c.url}) "
        f"(updated {c.updated_at:%Y-%m-%d})\n{c.text}"
        for c in chunks
    )

Twenty lines of adapter code, and it’s worth noting exactly what those twenty lines are an adapter onto: the identical retrieve_and_rerank function used by every other entry point covered elsewhere in this course. One single retrieval implementation, one single permission model, many different doors leading in. The moment a team forks off a “special” retrieval path specifically for MCP clients, quality and security both start drifting apart from the main path silently, usually without anyone noticing until much later.

The quiz’s warning above deserves body text too, since it’s the single most common way this pattern goes wrong in real deployments: the classic mistake is running this server under a shared service identity with broad read access across the whole corpus. Every client then effectively searches with the service’s eyes, not the actual asking user’s eyes, silently bypassing the entire permission model built in Module 7. MCP’s OAuth flows exist precisely so resolve_user can reliably bind the active session to a real, specific person; refuse to ship this server into production until that binding genuinely works end to end.

Federation versus central index: a per-source decision

With MCP normalizing access to essentially everything, you now get to choose per individual source, not as one blanket architectural decision, between two distinct modes of access:

flowchart TD
    A["Agent + router"] --> KB["search_knowledge_base\n(central index: wiki, Drive,\ncontracts, policies)"]
    A --> T1["get_ticket / search_jira\n(live MCP tool)"]
    A --> T2["search_slack\n(live MCP tool, recent)"]
    A --> T3["query_crm\n(live MCP tool)"]
    KB --> SYN["Synthesis with citations"]
    T1 --> SYN
    T2 --> SYN
    T3 --> SYN

    style A fill:#EEF0F7,stroke:#6366F1,color:#0F172A
    style KB fill:#f0fdf9,stroke:#0D9488,color:#0F172A
    style T1 fill:#fff7ed,stroke:#f59e0b,color:#0F172A
    style T2 fill:#fff7ed,stroke:#f59e0b,color:#0F172A
    style T3 fill:#fff7ed,stroke:#f59e0b,color:#0F172A
    style SYN fill:#f0fdf9,stroke:#0D9488,color:#0F172A

Central indexing, everything built across Modules 2 through 4, buys real ranking quality: hybrid search, contextual enrichment, cross-encoder reranking, and clean cross-source fusion, all of it. It costs real sync infrastructure to maintain and accepts a window of minutes-to-hours of staleness by design. It wins clearly for large, relatively stable, ranking-hungry corpora: wikis, document stores, contracts, formal policies.

Federation, live MCP tools reaching source systems directly, buys genuinely perfect freshness and requires zero sync infrastructure at all, and it delegates permission enforcement entirely to the source system itself, since the source API simply won’t return data the authenticated user isn’t allowed to see in the first place. It costs query-time latency for each call, per-source rate limits that can throttle a busy agent, and meaningfully weaker ranking quality in practice, since most SaaS search APIs underneath these tools are fairly basic keyword engines that would compare unfavorably against the hybrid-plus-rerank stack built across this course. It wins clearly for volatile, point-lookup data: tickets, live message threads, CRM records, anywhere “as of right now” is a genuine hard requirement rather than a nice-to-have.

The failure pattern worth actively avoiding is going all-federation: “we’ll just hand the agent twelve MCP tools and skip building an index entirely.” Twelve mediocre keyword searches, executed serially and each individually rate-limited, with no coherent cross-source ranking tying results together, produce a slow assistant that reliably misses relevant results; teams who tried exactly this approach through 2025 mostly ended up rebuilding a proper central index within a couple of quarters once the pattern’s limits became clear in production. The architecture that actually holds up combines both deliberately: index whatever genuinely benefits from careful ranking, federate whatever genuinely demands live freshness, and let the router established in earlier modules, together with the agent’s own judgment, choose the right tool per individual question rather than committing to one approach for everything.

Module 6 is now complete: generation you can genuinely audit, agentic loops that dig deeper when needed, and standardized doors connecting to essentially everything a user might need answered from. Which makes the next module urgent rather than merely thorough, because every door opened in this module is, by definition, also a door for something to go wrong through: permissions, injection attacks, and the security engineering that keeps a knowledge system from quietly becoming a breach. That’s Module 7.