OMCP architecture, functional and non-functional requirements.

[vvcb]

This thread is to discuss the high level architecture, features, ideas, etc. as they relate to OMCP server.

[sshenzha]

this is the initial draft for the OMCP high level architecture:

flowchart LR
    %% User and client
    u([User])
    c[MCP Client]
    %% Main server components
    subgraph omcp["MCP Server - OMCP"]
        os[Orchestrator Server]
        subgraph ts["Tooling Servers"]
            %% Tool internals
            subgraph sql["SQL Execution Tool"]
                glot["SQLGlot"]
            end
            subgraph vt["Vocabulary Tool"]
                vdb["Vector DB"]
            end
            subgraph pes["Python Execution Sandbox"]
                psanal["Statistical Analysis"]
            end
            subgraph res["R Execution Sandbox"]
                rsanal["Statistical Analysis"]
            end
        end
    end

    db[(Database)]
    u <---> c
    c <---> omcp
    %% Internal connections
    os <---> ts
    sql <---> db

Loading

Each of the boxes within the Tooling Servers are MCP servers, the idea is to have a "meta" MCP server, where the orchestrator (also a MCP server) coordinates the communication with the different Tooling Servers

[sshenzha]

I need some suggestions in terms of how is the communication between the different actual Tooling Servers, in case they are going to have it, because the current state is that the tooling servers have no communication between them and all the information goes through the orchestrator.

[nikomoegre]

I think here the A2A bit will hopefully come in handy as it might facilitate communication between different agents if we can implement it. This could look something like this:

flowchart TD
    A{General Model} <-->|Query input/ Receiving data & Concepts| B[A2A server]
    
    subgraph MCP_Server_1[MCP Server]
        C{SQL Model} <--> E[SQL Database]
        
        subgraph SQL_Tools[Tools]
            direction TB
            S1[SQL Query Generation]
            S2[SQL Query Validation]
            S3[SQL Query Execution]
        end
    end
    
    subgraph MCP_Server_2[MCP Server]
        D{Semantic Model} <--> F[Vector Database]
        
        subgraph Semantic_Tools[Tools]
            direction TB
            V1[Concept Search]
            V2[Concept Retrieval]
        end
    end
    
    subgraph MCP_Server_3[MCP Server]
        G{Analytical Model}
        
        subgraph Analytical_Tools[Tools]
            direction TB
            A1[Python Sandbox]
            A2[R Sandbox]
        end
    end
    
    B <-->|Querying/ Receiving Data| C
    B <-->|Querying/ Receiving concepts| D
    B <-->|Querying/ Receiving analysis results| G
    

Loading

[vvcb]

@nikomoegre , how is this different from tool use? Isn't the A2A server in your diagram simply another MCP server that is acting as a server-of-servers? Or are you thinking about moving the analytical, semantic and SQL models out of the MCP server box because they are also agent or LLM driven?

Would something like the below work better? I have made it a simper with just 3 agents. They could all be the same LLM with different prompts or they could be entirely different LLMs. We need a much clearer distinction between tool use (through MCP) and agents. We may get to a state where we expose tools which are themselves using LLMs and returning structured responses but for now, let's pretend that tools are dumb.

flowchart TD
    
user[User]
    subgraph a2a[A2A]
        user_agent[General Agent]
        semantic_agent[Semantic Agent
        Prepares user's query for tool use. 
        e.g. Converts T2DM to Type 2 Diabetes Mellitus
        or Parses the PDF of a published paper]
        safety_agent[Safety Agent
        Ensures that queries are safe to run against OMOP. 
        E.g. Reject questions from users that are aimed at identifying a single patient.
        This is different from the SQL validation that happens at the MCP server.
        Also ensures that outputs generated from MCP tools are safe for disclosure.
        This will be in addition to disclosure controls at the MCP tool level.]
    end

    subgraph mcp[ ]
        mcp_mcp[MCP Server-of-Servers]
        mcp_sql[SQL MCP Server]
        mcp_python[Python Sandbox MCP Server]
        mcp_R[R Sandbox MCP Server]
        mcp_vocab[Vocab MCP Server]
    end

    subgraph resources[ ]
        db_omop[OMOP Database]
        db_vocab[Vocab VectorDB]
    end
user --> a2a
user_agent --> semantic_agent --> user_agent
user_agent --> safety_agent --> user_agent

a2a --> mcp_mcp

mcp_mcp --> mcp_sql --> db_omop
mcp_mcp --> mcp_python --> db_omop
mcp_mcp --> mcp_R --> db_omop
mcp_mcp --> mcp_vocab --> db_vocab

Loading

[nikomoegre]

@vvcb yes, good point! In a setting as we've had it so far this isn't really different to tool use. It will only become relevant once we introduce different models for the different tasks. Then A2A becomes very efficient in letting the models themselves talk to each other and organise tasks independently. Each model then is exposed to an agent card for the other agents and their capabilities (e.g task proficiency, mcp tools and resources, message formats, return formats) and the models can message each other over the A2A server requesting the compilation of different tasks to then continue with the results incorporated in their tasks. I agree that if we can use a sufficiently generalised model to handle the MCP, we might not need any A2A there.