AI agents are only useful if they can access the right information at the right time. The previous articles covered how Airweave syncs data into collections and how your code can search those collections via the SDK or REST API. But there's a growing class of AI applications where you don't write the search logic yourself. Tools like Cursor, Claude Desktop, VS Code Copilot, and the OpenAI Agent Builder all have their own agent loops. They decide when to search, what to search for, and how to use the results.

The question becomes: how do you give these agents access to your Airweave collections without building custom middleware?

The Integration Gap

When you build a custom agent using the SDK, you control the entire flow. You decide when to call collections.search(), how to format the results, and what to do with them. This works well for purpose-built systems like the error monitoring agent described earlier in this series.

But most developers also use general-purpose AI assistants throughout their day. You ask Cursor to refactor a function, and it needs to understand your codebase conventions. You ask Claude Desktop to draft a response to a customer, and it needs context from your support tickets. You ask an OpenAI agent to summarize project status, and it needs data from Linear and Slack.

Each of these assistants has its own way of discovering and calling external tools. Without a shared protocol, connecting Airweave to each one would require writing a separate integration for every client. This is the problem the Model Context Protocol solves.

What is MCP?

The Model Context Protocol (MCP) is an open standard for connecting AI applications to external data sources and tools. It defines how an AI assistant discovers available tools, understands their parameters, and calls them during its reasoning loop.

Think of MCP as a USB-C port for AI agents. Just as USB-C standardized how devices connect to peripherals, MCP standardizes how AI assistants connect to external capabilities. An MCP server exposes a set of tools. An MCP client (the AI assistant) discovers those tools and calls them when needed.

This matters for context retrieval because it turns search from something you code into something the agent does natively. Instead of writing glue code that intercepts the agent's reasoning and injects search results, the agent itself decides when to search your Airweave collection, formulates the query, and incorporates the results into its response.

How the Airweave MCP Server Works

Airweave ships an MCP server that exposes your collections as searchable tools. When an AI assistant connects to it, the assistant sees a tool called search-{collection} (for example, search-engineering-context) and can call it with a natural language query at any point during its reasoning.

The server supports two deployment modes:

Local mode runs as a process on your machine, communicating over stdio. This is the standard setup for desktop AI clients like Cursor, Claude Desktop, and VS Code. You configure it with your API key and collection ID, and the assistant discovers it automatically.

{
  "mcpServers": {
    "airweave-search": {
      "command": "npx",
      "args": ["-y", "airweave-mcp-search"],
      "env": {
        "AIRWEAVE_API_KEY": "your-api-key",
        "AIRWEAVE_COLLECTION": "your-collection-id"
      }
    }
  }
}

{
  "mcpServers": {
    "airweave-search": {
      "command": "npx",
      "args": ["-y", "airweave-mcp-search"],
      "env": {
        "AIRWEAVE_API_KEY": "your-api-key",
        "AIRWEAVE_COLLECTION": "your-collection-id"
      }
    }
  }
}

{
  "mcpServers": {
    "airweave-search": {
      "command": "npx",
      "args": ["-y", "airweave-mcp-search"],
      "env": {
        "AIRWEAVE_API_KEY": "your-api-key",
        "AIRWEAVE_COLLECTION": "your-collection-id"
      }
    }
  }
}

{
  "mcpServers": {
    "airweave-search": {
      "command": "npx",
      "args": ["-y", "airweave-mcp-search"],
      "env": {
        "AIRWEAVE_API_KEY": "your-api-key",
        "AIRWEAVE_COLLECTION": "your-collection-id"
      }
    }
  }
}

Hosted mode runs as a stateless HTTP service at https://mcp.airweave.ai/mcp, designed for cloud-based AI platforms. Each request is fully independent, with authentication and collection selection happening via HTTP headers. No sessions, no server-side state. This is the setup for platforms like the OpenAI Agent Builder, where you can't run a local process.

In both modes, the MCP server is a thin wrapper around the Airweave SDK. It validates the agent's parameters, calls the search API, and formats results for the assistant. The architecture is deliberately simple:

The server never caches results or maintains state between requests. Every search hits the live collection, which means results always reflect the latest synced data.

What the Agent Can Do

The primary tool, search-{collection}, accepts the same parameters as Airweave's search API. The agent can control the search strategy (hybrid, neural, or keyword), set result limits, apply recency bias, enable reranking, and choose between raw results or an AI-generated summary.

What makes this powerful is that the agent maps natural language to these parameters automatically. When a developer asks Cursor "find the most recent docs about authentication," the assistant translates that into a search call with an appropriate recency bias. When someone asks "give me a summary of our onboarding flow," the assistant sets response_type: "completion" to get a synthesized answer rather than raw chunks.

This is the key difference from SDK-based integration. With the SDK, you decide the search parameters at development time. With MCP, the agent adapts its search strategy to each query at runtime. It can start broad, narrow based on initial results, and adjust parameters on the fly, all within its own reasoning loop.

Where This Fits

MCP and SDK-based integration serve different use cases, and most teams end up using both.

Use MCP when the AI assistant controls the reasoning loop. Cursor deciding when to search your codebase. Claude Desktop pulling context while drafting a document. An OpenAI agent answering questions about your project. In these cases, you want the assistant to discover and use your collection as a native capability without you writing search logic.

Use the SDK when you control the reasoning loop. A custom pipeline that searches specific sources with specific filters at specific times, like the error monitoring agent. Programmatic workflows where search is one step in a larger orchestration. Scenarios where you need precise control over query construction and result processing.

The two approaches share the same underlying infrastructure. Whether a search comes from Cursor via MCP or from your Python script via the SDK, it hits the same Airweave search API, queries the same Vespa index, and returns results ranked by the same hybrid retrieval pipeline. The difference is who decides when and how to search.

A Practical Example

Consider a team that has connected GitHub, Linear, and Slack to an Airweave collection called engineering-context. Here's what their setup enables:

A developer working in Cursor asks: "What's the context behind the rate limiting changes in the payments service?" Cursor calls search-engineering-context with that query. Airweave returns relevant GitHub PRs, Linear tickets, and Slack discussions. Cursor synthesizes the context and explains the history behind the changes, with source attribution. The same MCP server works identically in Claude Desktop, VS Code, or any other MCP-compatible client.

The same collection also powers their error monitoring agent via the SDK, which runs on a schedule and searches with specific source filters (source_name: "GitHub", source_name: "Linear").

One collection, two access patterns (MCP for interactive assistants, SDK for programmatic pipelines), zero custom integration code per client.

Looking Ahead

MCP is still a young protocol, but adoption is accelerating across AI clients. As more assistants support MCP natively, the value of having your organizational context available through a single MCP server compounds. Every new AI tool your team adopts gets immediate access to the same retrieval layer.

This connects to a broader theme running through this series: context retrieval works best when it's treated as shared infrastructure rather than something each application builds from scratch. MCP makes that infrastructure accessible not just to your code, but to every AI assistant or application in your workflow.