MIVC - Memory, Interface, Verifier, Client -- A MCP Server Design Framework
Memory MCP Servers
An MCP server requires fetching very specific information with the right context. We have already seen multiple memory fetching implementations in order to serve the current context length limitations. Even if context length is increased (Gemini 2.5 Pro), the ability to serve intelligently on vast data decreases. Thus, there seems to be a clear need for intelligent fetching systems for blobs of information. Multiple methods for the same have emerged:
1. LLM Schema Generation + Database Record Creation
In this technique, the information blob is understood and a schema is created. Then with this format, the information is stored in the database. Once the database is populated, the schema is conveyed to the LLM for writing queries on the database to fetch required information.
2. (1.) + Vector Columns
A lot of times LLMs need to understand the relational context for different records. The idea here is not direct inference (SQL) but contextual inference (vectorized words). This requires some columns to be vectorized.
3. Cyclic Knowledge Graphs
This is where LLMs generate knowledge graphs which are connected to each other in a cyclic pattern where edges denote relationships and nodes store specific information.
YADA YADA YADA.
Designing a memory layer should be able to encompass these use cases for information retrieval and any future implementations as well.
Example Code
Example code could look something like this:
fetch_gmail = MemoryClass(desc="fetch gmail email information via Vector Columns")
res = fetch_gmail.lookup(summary="flight tickets from india to new york")
The MemoryClass itself would look like:
Id = email id
Subject = string
Summary = Vector DB
def lookup(input):
return model.summary.find(input)
This could also be cyclic knowledge graphs or Retrieval Augmented code.
Now one could load a compatible Vector Database from it like Pinecone, Milvus, or MongoDB. More thought needs to be put into how the actual code would look like. I'm happy to take feedback on the same. Right now this is akin to how models work in MVC architecture in Ruby on Rails.
Interface MCP Servers
Often these LLMs are required to act upon specific interfaces - e.g., Browsers, Software, Blender, Linux Terminals, Operating Systems. There are a limited number of interfaces where these LLMs can interact. The idea is to load an interface akin to a 'ruby gem'. The developer of these interfaces can constrain and define how the LLM talks to these interfaces. For example, in case of a browser, a DOM can be served as input, whereas output can be executed on the Browser console. In the case of software, the input can be different menus/clicks on the software and the output will be a screenshot of the software window after different actions.
Interface Components
Each interface will have three main components:
Service Command - This is similar to MCP servers' commands with arguments. The difference is it points to terminal opening command, starting of docker command, running an operating system VM...
Input Interface Experience - The inputs to these interfaces will be required to be constrained by the LLM. This will be based on the choice of interface developer.
Output Interface Experience - The output design from the interface requires LLM communication. This again will be based on the choice of interface developer.
Unique Features of Interfaces
- Each interface will be an MCP server in itself
- Each interface can be loaded within another MCP server, to serve as a base layer to be built further
Example Interface Code
An example code can look like this for defining an interface:
Interface ABC
Service Commands:
@command
def start():
args = ["commands"] / "start.sh"
@command
def stop():
args = ["commands"] / "stop.sh"
Input Interface:
# take input as screenshot
screenshot.validate(type: image)
definition: "this image describes the state of the software, try to understand if the user is clicking something and how this image is different from base software..."
Output Interface:
# take output as actions on a software
mouse.click(x: 123, y: 122)
keyboard.input("top players")
dom.execute("$('.find').click()")
More thought needs to be put into how the actual code would look like. I'm happy to take feedback on the same.
Verifier MCP Servers
The responses from the LLM need to be verified by a separate black box whose context is not visible to the LLM.
For example, the verifiers can be used to understand the LLM response, if it:
A. Serves the purpose or not. If the response further requires a deeper LLM probe or multiple subagents to complete the task.
B. Should be served to the individual asking it (based on role of the individual or personalization of the individual). If there is further personalization that can be done to the response.
Another example can be if the input is correct and needs to be further detailed or explained before giving it to the main interface/further passed on.
Verifier Features
These are basically a black box unit serving as an LLM which runs when the developer wants to. It can be:
- Just after the LLM input
- After the LLM response
- During the interface communication
They can access the memory for personalization, fetching roles. They can modify the LLM response. We also want this to serve as an integral layer to integrate with other eval services for agents that exist such as TensorZero, LangChain evals. The idea, although, is that eval intelligence should be a black box to the definition of the agent.
Verifier Code Example
# response/input = as defined previously in code
bool_access, sanitized_response = Verifier.verify(
"this is meant for a HR professional in an organisation, check if they should have access to this answer/tool call"
)
if bool_access:
return response
else:
return sanitized_response
Client
This can be a pub/sub Kafka on a socket, it can be terminal commands, it can be a chat interface. The idea here is to make the current IO for MCP servers more flexible to serve different clients. The client can be customized to have authentication, social OAuth, yada yada again loaded into the server with packages/gems/libraries which can act as proxy. The idea here is to build composable client units for main IO. Right now what's defined by Python decorators actually needs to be a lot more flexible serving more use cases. The idea here is to not restrict the intelligence by a single "chat client" design but allow more feature-rich clients to exist.
Example Agent Flow
Here is what an example flow and code for an agent may look like. This is an agent which checks my email address for specific flights, finds my passport information from a personal database and applies to VISA for a country I am travelling to:
email_memory = MemoryClass(desc="Gmail flight information via Vector DB")
personal_vault = MemoryClass(desc="Personal documents storage")
browser_interface = Interface("BrowserAutomation")
visa_verifier = Verifier("travel_document_validator")
country_verifier = Verifier("country_verifier")
def travel_visa_agent():
flights = email_memory.lookup("recent flight tickets")
destination_country = email_memory.lookup(flights + " countries as an Indian I need visa to and can be given online")
can_proceed, destination_country = country_verifier.verify("check if it is valid country, just return the country name, indian citizens require a visa and visa can be obtained online")
if !can_proceed:
return
passport_info = personal_vault.lookup("passport document current")
can_proceed, sanitized_data = visa_verifier.verify(
f"visa application for {destination_country}",
context={"flights": flights, "passport": passport_info}
)
if !can_proceed:
return
browser_interface.start()
browser_interface.navigate("visa-portal.gov")
browser_interface.fill_form(passport_info, flights)
browser_interface.submit()
return "Visa application submitted successfully"
