From Function Call to MCP: How to call external tools in large models

Although the large language model has powerful generation and understanding capabilities, it is essentially a "pre-training" model.

In other words, its knowledge source is training corpus, not real-time data. It lacks knowledge of facts after 2023  , personal data, dynamic databases, etc. For example:

• It doesn't know what stage the expense report you submitted last week is at now;

• It cannot directly read case details in a legal system;

• It also doesn't have the ability to check the latest weather or stock market data.

  
  

The answers to these questions often lie in the "external system interface". Therefore, we hope that the model can call the interface, obtain data, and complete tasks like a programmer when needed.

This is the value of Function Call  .

For example, in model platforms such as DeepSeek  , users can use online search plug-ins to obtain real-time information. This is actually a typical  Function Call  practice:

1.  The plugin is registered to the model in  the form of a schema  (e.g. search_news );

2.  The model determines whether a search is needed based on the user's question;

3.  Initiate a call to the Internet interface, obtain the search results, integrate them into the prompt words, and then continue to generate answers.

The ability to call external tools is also one of the core capabilities in building agent applications : allowing the agent to independently decide whether to call a tool and which tool to call based on the current task.

Function Call  means that when the big model answers user questions, it determines whether it needs to call an external tool to obtain real-time or structured data based on the built-in function definition ( Function Schema ).

For example:

User asked: "How much money does Zhang San still owe?"

The model may call a function called `getLoanStatus(user_id)`  and pass in "Zhang San" as a parameter to obtain and integrate the results returned by the interface.

The key to implementation is:

1.  Encapsulate all supported call interfaces into  Function Schema in JSON  format  ;

2.  Inject these schemas into the system prompts  ;

3.  The model automatically selects and passes parameters according to the definition to initiate the call.

PS: Schema can be simply understood as the description document of the interface, telling the model: what is the function called, what it does, what parameters are required, and what structure is returned. However, this description document is specially customized for large models, so that the model can  " understand "  and participate in the call.

The question is, what if there are many interfaces?

In a real business scenario, there may be dozens or even hundreds of different interfaces involved, such as database access, online search, OCR access, map services, chart generation, etc.

If each interface needs to manually define the schema and register it with the model, it will not only be cumbersome and repetitive, but also difficult to manage.

In addition, if these interfaces are to be shared by multiple agents  or deployed to multiple platforms (such as  Coze , dify , Fastgpt), unified standards and centralized management are even more necessary. Moreover, different large models (such as GPT, GLM, DS, etc.) may have different function call formats. MCP can also serve as an adaptation layer, allowing different models to call tools using the same set of standard protocols, thus achieving decoupling between models and tools.

This is  exactly the value of MCP  .

MCP , the full name of  Model Context Protocol, is essentially a set of protocol specifications used to describe multiple external tools / services into a format that is recognizable and callable by large models (i.e.  Function Schema ), and expose them centrally for model loading and use.

You can understand the role of MCP  like this :

Automatically package  multiple  APIs  into Function Schema  format;

Expose a unified plug-in service entry;

For loading by model application platforms that  support  the MCP  protocol (such as Dify );

MCP  no longer requires each tool to write a separate  schema , but instead generates a unified format based on standardized  OpenAPI  interface descriptions (such as  swagger.json ), greatly reducing tool management and access costs.

Based on my recent experience with Dify 's MCP function, I speculate that the overall flow of this mechanism is as follows:

1. Develop and write interfaces (such as RESTful APIs ) using document formats that  conform to the OpenAPI  specification (such as swagger.yaml  or  JSON );

   
   

2. MCP Server  reads the interface document and automatically generates  a Function Schema (i.e., a tool call description) for each interface.

   
   

3. A platform that supports the MCP  protocol (such as  Dify ) acts as  an MCP Client , connects to  the MCP Server , and loads the Function Schema of all tools  ;

   
   

4. MCP Client (such as  Dify ) will inject the schema  of these tools  into the prompt of the big model ;

   
   

5. After receiving the user's question, the big model determines whether a function needs to be called. If so, it generates a structured request that meets the tool parameter requirements;

6. MCP Client parses the function call request formats generated by different models, converts them into a standard format that complies with the MCP protocol, and communicates with the MCP Server;
7. MCP Server executes the corresponding tool logic and returns the results for the large model to process.

Function Call  is the key mechanism that enables large models to have "tool usage capabilities".

MCP  is the context protocol standard that makes this set of capabilities "manageable, extensible, and composable."

Working together, they are gradually building an intelligent service ecosystem with "intelligent entity  +  tool chain" as the core.