[RFC] Support MCP in OpenSearch

[zane-neo]

Problem Statement

With the recent surge in Large Language Models (LLMs) and AI agents, there's an increasing demand for AI systems to access the latest data from various sources, including databases and public APIs. The Model Context Protocol (MCP) has emerged as a universal, open standard for facilitating these connections. This presents an opportunity for OpenSearch to join this AI revolution by supporting MCP servers and exposing OpenSearch APIs as tools. This integration would allow diverse AI systems to interact with OpenSearch with minimal modifications.

Proposed Solutions

Since MCP is working based on JSON-RPC, so an example of index/_mapping API would look like below:
Request

{
  "jsonrpc": "2.0",
  "method": "index/_mapping",
  "headers": {
    "Content-Type": "application/json",
    "Authorization": "Bearer xxx"
  },
  "params": "test_index",
  "id": 1
}

Response

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "mappings": {
      "properties": {
        "text": {
          "type": "text"
        }
      }
    },
    "settings": {
      "index": {
        "translog": {
          "sync_interval": "30s",
          "durability": "async"
        },
        "number_of_replicas": "1",
        "number_of_shards": "2"
      }
    }
  }
}

We are considering two primary approaches to support MCP in OpenSearch:

1. Modifying OpenSearch Core:

   • Implement support for the MCP protocol directly within the OpenSearch core.
   • As MCP is based on JSON-RPC, we would need to:
     a) Handle and parse incoming JSON-RPC requests.
     b) Construct corresponding OpenSearch requests based on the JSON request body.
     c) Route these requests to the appropriate OpenSearch handlers.

2. Developing a New OpenSearch Plugin:

   • Create a dedicated plugin (e.g., 'opensearch-mcp') to implement MCP protocol support.
   • This approach may require:
     a) Exposing a new port to handle JSON-RPC requests.
     b) Implementing logic to dispatch these requests to various OpenSearch handlers.
   • Further investigation is needed to determine the feasibility and specifics of this approach.

Each solution has its own set of advantages and challenges, which will need to be carefully evaluated to determine the most effective implementation strategy.

For now, let's focus on discussing this proposal at a high level. If there's consensus to move forward, I will iteratively refine this RFC, incorporating more detailed low-level design.

Related component

Other

Describe alternatives you've considered

No response

Additional context

No response

[dbwiddis]

The Model Context Protocol (MCP) has emerged as a universal, open standard for facilitating these connections.

Enthusiastic +1 for supporting "universal, open standards".

Without digging into the details of the protocol, is it more of a streaming or just more of a parsing/formatting thing?

[zane-neo]

Without digging into the details of the protocol, is it more of a streaming or just more of a parsing/formatting thing?

From the official document: https://modelcontextprotocol.io/docs/concepts/architecture#transport-layer, the protocol follows client-server architecture, and uses HTTP with SSE transport to send streaming results back to client.

[jngz-es]

Without digging into the details of the protocol, is it more of a streaming or just more of a parsing/formatting thing?

I think it is more of a parsing/formatting thing, not streaming which is specially for huge responses.
Basically it is about making OpenSearch as MCP server to provide standard tool APIs that MCP client can use to get standard tool metadata and responses, then provide them to LLMs. I guess LLMs are well-trained against these standard message format and could respond in a better way.