AI Product Managers Think About the MCP Protocol (1): Foreseeing MCP - My "Universal Library" and the Road to Standardization

MCP (Model Context Protocol) is popular. This open protocol proposed by Anthropic aims to unify the way large models (LLMs) call external data and tools. After OpenAI officially announced its support, it is becoming a new industry standard and has also become a hot topic.

According to the official explanation: Model Context Protocol (MCP) is an open standard launched by Anthropic, which aims to standardize how artificial intelligence applications (chatbots, IDE assistants or custom agents) connect with external tools, data sources and systems.

There are many interpretations of MCP, but I feel that they are all too superficial. What problem does MCP solve? What is the difference between it and Function Call? Why is it so important? I rarely see anyone talking about it. This article may give you some inspiration. Different from a purely technical interpretation, I will explore the value of MCP as an AI product manager, combining my practical experience of building a similar framework, "Universal Library", in the past six months.

In my opinion, the core of MCP lies in "standardization". This series of articles will focus on the following points:

• •  Design the background and process of the “universal library” and understand the reasons for the emergence of MCP.
• •  Benefits of MCP
• •  Prediction of the next steps for MCP (important!).

Let us understand why MCP appears from my previous practical experience.

Let’s start with the Universal Library

Before talking about MCP, I would like to share a concept that I have been thinking about and practicing for the past six months - I call it "OmniLab". In our internal tests, it significantly reduced the workload (reduced the amount of repeated work by 70%) and accelerated the experimental efficiency.

This idea originated last summer. During that time, I intensively disassembled and analyzed various AI products on the market. After disassembling so many, I suddenly realized that no matter how different the product forms are, the underlying logic is the same. In essence, they all use large models (LLM) to respond to and meet the specific needs of users.

Moreover, almost all AI application processes can be simplified and abstracted into three core stages:

" Input - Processing - Output ".

Let’s look at a few seemingly different AI products: AI smart writing, AI smart meeting minutes, AI smart editing

I analyzed at least a dozen products at the time, from various common AI writing products to Riffo, DeepSearch... and even concept games (user input -> LLM processing -> game progress output), none of them could escape this pattern.

Let's define these three stages more strictly:

1. 1.  Input:  This is the raw information fed to the AI. It can be text, audio, images, web links, or data passed from the previous step in the workflow. Often a lot of preprocessing operations are required, such as modality conversion: no matter what the original modality is, it often needs to be converted into a format that the large language model can understand - usually text , because the core engine of the "processing" step is mostly the large language model.
2. 2.  Process:  This is the "brain" of AI applications. The core is usually  a large model (such as GPT, Claude, etc.) with carefully designed prompts . Sometimes, in order to complete complex tasks, an agent composed of multiple models may also be used. But fundamentally, it is the LLM that understands, infers, and generates.
3. 3.  Output:  This is the result delivered by AI after completing the task. Practical AI products are by no means limited to simple chat replies. The output needs to be specific and valuable content or format, such as a Word document, an Excel table, a piece of standardized JSON data (for system docking) or a visual result (Canvas) directly presented on the interface. This stage usually still requires external program assistance.

After seeing the underlying logic, an idea will naturally emerge: since the underlying implementation is similar, can we "componentize" these common functional modules to achieve reuse?

We can build a reusable module library according to the idea of ​​"input-processing-output":

• •  Input module library: various data capture modules, responsible for pre-processing the data and passing it to the model
• •  {Text extractor, web content scraper, speech-to-text module, image recognition module}
• •  Processing module library: Combined with Prompt to process the content of input module
• •  {GPT, Claude, DeepSeek, Gemini... }
• •  Output module library: responsible for converting the output content of the processing module into actual products
• •  {Word document generator, Excel table generator, JSON formatting, email sending...}

Want to make AI meeting minutes? Combination: voice-to-text input + (summary prompt) large model call + text output.

Do you want to develop AI intelligent writing products in the future, such as AI official document writing or AI paper assistant? You only need to reuse the existing modules and adjust the prompt in the "processing" link . This "assembly" mode greatly improves development efficiency and experimental speed.

I immediately used my framework to rewrite all the demos I had written before. In terms of core functions, they can be adjusted in as fast as a few minutes, and then the front-end page can be simply packaged for quick testing and verification.

import  asyncio
from  omni_lab.inputs.text  import  TextInput
from  omni_lab.processor.minimax  import  MiniMaxProcessor
from  omni_lab.outputs.excel  import  ExcelOutput
from  omni_lab.prompts.manager  import  PromptManager

# Your API key
api_key =  '' #

async  def main ():
    # Initialize each component
    input_data =  "balabala" # Input data
    text_input = TextInput(input_data=input_data)
    prompt_manager = PromptManager()
    system_prompt = prompt_manager.get( "minimax.excel_system_prompt" ) .format ()  #prompt word loading
    processor = MiniMaxProcessor(api_key=api_key, system_prompt=system_prompt)
    excel_output = ExcelOutput(output_path= '' )
    pipeline = MiniMaxPipeline(
        text_input, 
        processor, 
        excel_output
    )
    ## Processing data using pipeline
    result =  await  pipeline.process()

(Omnilab's quickstart document)

However, in order for these independent modules to be smoothly put together, a key prerequisite must be met: standardization. Modules need to use an agreed format to transfer data. The data processed by the input module needs to be passed in a way that the processing module can understand; the results generated by the processing module also need to be passed out in a way that the output module can receive. So at that time, I naturally thought of using JSON as a universal data exchange format.

If you have read this far, I believe you have understood the root cause and necessity of MCP: we are really doing a lot of repetitive and unnecessary work, and it may even reduce performance! So MCP tries to solve this problem. According to the official explanation of MCP, MCP provides

• •  A growing list of pre-built integrations that your LLM can directly plug into
• •  The flexibility to switch between LLM providers and vendors
• •  Best practices for securing your data within your infrastructure

Let's take a look at the diagram provided by the MCP official. Compared with the universal library, MCP is not divided into input and output. Instead, the input and output are unified into MCP Server, which is responsible for providing MCP services to large models. The large model part becomes MCP Client, but in essence, it has the same logic as the universal library, standard interface, and fast splicing.

The benefits of this are enormous. For example, if a web page extraction function is made into an MCP tool, all large models that support MCP can be called directly, and no one needs to rewrite this function... and there are dedicated people to optimize this module.

Now we know the feasibility of standardization. But this naturally leads to a deeper question: Is standardization really necessary? Are we reinventing the wheel?