Seeing the Sun Through the Cloud: The Vision and Best Practices Behind MCP's Core Concepts (Prompt, Resource, Tool)

Last weekend at the 2025AIGC Shanghai Developer Conference (MCP leads the new era of Agent Internet) shared the theme as "Thinking on the trend of co-evolution of large language model, Agents, and MCP" 's speech shared and predicted the development trend of large language model, Agents, and MCP ecology in the next year. Friends who need PPT can click the card above to follow me and reply to the keyword (MCP) to receive it.

The content of this article comes from the in-depth thinking of PPT on one page

The following is the main text:

01 / OriginThe 

MCP (Model Context Protocol) ecosystem has quietly developed for more than half a year, but looking around, most Servers ' implementation seems to focus on the construction of the Tool. When Google A2A released the classification of MCP as the Agent tool protocol, it was thought-provoking: Is MCP really just a tool protocol? Where are the original concepts and application blueprints of those carefully designed Prompt and Resource concepts? Why do most MCP Servers only implement Tool functionality?

02 / Context in MCP: The cornerstone of the model's cognitive world

To answer the above questions about the core concepts of MCP, we first need to return to its name-model Context Protocol. What exactly does this "context" mean? It is like the surrounding environmental information, historical dialogue, and reference materials at hand when we understand the world. For a large language model, context is the entire input for its effective thinking and action. It is usually composed of several core parts:

• User Directives (Prompts): This is not only a direct command of the user, but also a "guide sign" that has been optimized by the field and efficiently output by the boot model.
• Static information (Resources): Like a reference book or background material at the edge of a model's desk, it can be documents, pictures, and data pointed to by URIs, providing the model with stable background knowledge required for decision-making.
• Dynamic Feedback (Tool Results): After the model interacts with external tools, the results returned by the tool - whether it is success, failure, or process data- become the key dynamic context for the next action of the model.

Together, these elements weave the "information field" of model understanding tasks, environments, and even users' real intentions.

03 / The essence of MCP: the connector for model understanding and transforming the world

If we only stay at the above definition, what we see is the appearance of the MCP protocol. So, what is its deeper nature?

This connector connects the powerful inference core of the model at one end and extends to the vast world of digital and physical at the other end.

Model understanding the world: read-only power of context

The so-called model understanding of the world refers to the model injecting and interpreting context information to understand the user's environment, the specific details of the problem to be solved, and the immediate or non-instant feedback generated during the execution of tasks. This contextual information is read-only, idempotent for the environment, and will not directly cause side effects. Prompts' guidance, knowledge supplements of Resources, and feedback on tools' execution results are all in this list.

1. Prompts: carefully tuned best practices

In the design of MCP, Prompts are much more than simple questions entered by users in the dialog box. I positioned it as a collection of instructional best practices under specific vertical fields.

Imagine an MCP with Baidu map capabilities Server, it should not be content with the ability to passively respond to atomic queries like "find the nearest cafe". More ideally, it can actively provide a series of carefully tuned Prompt templates, such as:

// Travel planning Prompt template example: 
Please help me develop a detailed three-day self-driving route plan, the requirements are as follows: 

1. The departure point is [The departure point name or latitude and longitude], and the destination is [The end point name or latitude and longitude]. 
2. Along the way, you need to pass at least 3[types of interest points, such as "National Forest Park" or "Historical and Cultural Attractions"]. 
3. The route should be avoided as much as possible (real-time road conditions can be used to judge), and the scenic sections (such as Binhai Highway or high-rated self-driving routes) should be preferred. 
4. The daily driving distance is controlled to not exceed [km] Kilometres per day. It is recommended to set off every day. 8:30 Depart, 17:00 Arriving at the accommodation point before. 
5. Recommended suitable gas stations (need to include name, latitude and longitude, service type) for each itinerary, and recommended at least once per kilometer. 
6. Reasonable accommodation points are recommended, requiring it to be close to the end of the day's itinerary, including name, rating, price range and latitude and longitude. 
7.  Return to the complete route suggestions, including: 
 - Daily itinerary start and end points, pass through landmarks/attractions list and their longitude and longitude
  - Estimated duration and distance of each distance
  - Recommended list of daily refueling points and accommodation points
Please output in a structured format, and call map search, route planning, interest search and other tools to complete the parameters if necessary. 

These templates have built-in optimized understanding of map service parameters and encapsulate the "optimal posture" of the question. They can significantly broaden the user's usage horizons and guide users to make full use of the model and the capabilities of the services behind them, thereby achieving far exceeding expectations.

This is the core value of Prompts in MCP - lowering the threshold for obtaining high-quality results and improving the certainty and efficiency of interaction. So, the question is, why do most existing practices ignore this and simply throw the construction of Prompt completely to the MCP Host or end users?

2. Resources: On-demand injection of static knowledge

Resources are positioned in MCP as a static, referenceable context information unit. It can be a piece of text, a document, a URI to the knowledge base, or even a picture, a video, or a data file in any conventional format.

These static resources can be valuable "salts" generated by the MCP Server in past interactions (such as an analysis report, a design drawing, a dataset), or various pre-prepared sample papers, case libraries, industry specification documents, or the latest data dynamically accessed through URIs.

{
  "resources":[
    {
      "uri":"file:///travel_guides/beijing_classic_routes.md",
      "text:"color: #D19A66;">"name":"Beijing Classic Travel Route Guide"

According to the original intention of the agreement, the selection and injection of Resources is more inclined to be carried out by people (users or developers) in specific scenarios, rather than being completely judged by the model. When applied, MCP Host decides when and in what way to incorporate the content of these Resources into the final context of the model based on the current task and user selection, so as to help the model understand user intentions and specific situations more accurately.

Imagine that when users write a market analysis report, they can take the initiative @ Introduce an industry benchmark data Resource, or an excellent similar report sample Resource, and the model can be created "standing on the shoulders of giants". This kind of explicit and controllable knowledge injection is a key consideration in Resource design.

3. Tools Execution result: Instant acquisition of dynamic feedback

AI Agent: To complete complex tasks, it often requires multiple rounds of collaborative calls from multiple tools. In this "observation-think-action-re-observation" cycle, the execution results of each tool call, whether successful or not, constitute the crucial learning material and decision-making basis for the model.

This information needs to be fed back to the model instantly and accurately. For example, if the model attempts to book a ticket (Tool call), if it fails due to insufficient remaining tickets, the "failure" result and possible reasons (such as "Economy Class is sold out, are you considering business class?") is the direct input of the model to reflect and adjust strategies (such as asking the user whether to upgrade the class, or change the near date).

So, the execution result of Tools, at the stage of "understanding the world", we play the role of a dynamic context provider, helping the model continuously calibrate cognition in its interaction with the world.

Model changes the world: The mystery of Tools' dual identity

After talking about understanding the world, let's look at how the model "changes the world". Under the framework of MCP, this is mainly achieved through the execution of Tools - those actions that can have span-friendly actions to the external environment, such as sending emails, creating a schedule, placing orders, controlling smart homes, etc.

However, the reality is quite interesting: whether it is to obtain read-only contexts that understand the world (such as searching for weather, searching for knowledge), or performing write operations that have side effects, the industry seems to have packaged them in unison to implement them in a unified way. Tools . This creates a tension when designing the protocol, the clear positioning of Prompts and Resources in providing context.

The current situation of "everything is a tool" simplifies the implementation complexity of MCP Server - only pay attention to one interaction mode; on the other hand, it also blurs the essential differences between different types of information interactions, which may lead to the inadequate release of the potential of Prompts and Resources. Is this phenomenon a contradiction between design and reality, or is it an inevitable convergence of a specific stage of development? It is worth our in-depth thinking.

04 / Imagination of application scenarios and interaction forms: Let the complete MCP "live"

To this day, the MCP Host applications we are familiar with almost all focus on the use of Tools. For the native support and interaction design of Prompts and Resources, it seems to be a virgin land to be cultivated. This makes us somewhat lack a specific picture feeling for how a new experience can an application that has fully realized the three troikas of the MCP protocol.

Based on understanding the underlying logic of the protocol and referring to some interview clips from the official team, we can try Prompts and Resources in MCP. The application scenarios and interactive forms in the ecology will make a more vivid imagination and deduction.

Prompts interaction and scene

Interaction form:

1. 1. Implicit triggering and retrieval: In the input interface of MCP Host, users can enter specific prefixes (such as / or "Evocation Command" in Chinese), quickly retrieve and select high-quality Prompt templates provided by MCP Server with keywords. For example, enter /Travel to list multiple Prompt templates related to travel planning.
2. 2. Explanatory lists and guidance: MCP Host can clearly display the available Prompt template lists in specific areas of the interface (such as the Inspiration Panel, Assistant Suggestions Area) based on the MCP Server capabilities currently connected, for users to browse and click, especially for users who are first exposed or want to explore the boundaries of service capabilities.
3. 3. Model driver and intelligent recommendation: Based on the user's current input, dialogue history, or task context, the built-in auxiliary model of MCP Host can intelligently analyze user intentions and actively recommend one or more highly relevant Prompt templates to achieve smarter guidance.

Application scenarios:

1. 1. Baidu Map MCP Server: Provides Prompt templates such as "weekend family tour planning", "three-day hiking route design", "avoid restricted commuting plan". After the user clicks, he only needs to fill in a small amount of key information (such as destination, preference) to obtain a highly customized travel plan.
2. 2. Xiaohongshu MCP Server: Provides "popular [category] product evaluation notes framework", "[city] store exploration strategy creation guide", "[skills] learning experience sharing structure", and other Prompt templates to help users efficiently generate high-quality content that meets the platform's tone.
3. 3. Code Assistant MCP Server: Provides Prompt templates such as "generate a [language] code skeleton that conforms to [a certain design pattern]", "write unit test cases for [function name]", "explain the logic of this [heterogeneous language] code", and empower developers to quickly complete standardized and high-quality coding tasks.

Resource interaction and scene

Interaction form:

1. @ symbol injection and multiple selection: Drawing on mature code editors or knowledge management tools (such as Cursor's @ file/symbol, Notion's @ page/date), when users enter in MCP Host, they can use the @ symbol to quickly search and select one or more Resources managed by MCP Server or accumulated by the user, and dynamically inject them into the context of the current conversation.

2. Context-aware recommendation and click injection: When users are handling specific tasks (such as writing reports, analyzing data), MCP Host can intelligently recommend related Resources (such as industry templates, historical cases, related data sets) based on task characteristics and loaded MCP Servers, and users can inject them with a click.

3. Visual list and drag-and-drop management: MCP Host can provide a dedicated Resource management panel, where users can clearly see the available public Resources provided by the current MCP Server, as well as the private Resources they have access to, and support drag-and-drop injection or preset loading.

Application scenarios:

1. Enterprise Knowledge Base MCP Server: Internal corporate rules and regulations, product manuals, best practices, FAQs, etc., can all be used as Resources. When dealing with customer inquiries or internal collaboration, employees can quickly @ the corresponding documents, and the model can provide more accurate answers or solutions based on this. For example, when customer service is dealing with after-sales issues, @ the product maintenance manual Resource.

Tools interaction and scenarios (review and prospects of the status quo)

Tools' interaction is currently relatively mature. Usually, after the model analyzes the user's intent, it decides which tool to call and assembles the parameters to initiate the request. The host is responsible for execution and returns the results.

The current scenarios are very wide:

• Query weather, stocks, and news.
• Reserve air tickets, hotels, and restaurants.
• Send emails, set reminders, and manage calendars.
• Execute code and apply refactoring in the code editor.

The future imagination space lies in more complex orchestration and deeper integration: For example, a "one-stop travel planning" scenario may require the model to be called in sequence: air ticket query tool, hotel reservation tool, scenic spot recommendation tool, local transportation planning tool, and use the output of the previous tool as part of the input of the next tool, and combine it with the user through @ Injected personal preferences (such as "favoring a quiet accommodation environment"), and a Prompt template that uses a "in-depth cultural experience tour". This is the ideal picture for the collaboration between the three MCPs.

05 / Why does the industry only focus on Tools and ignore Prompts and Resources?

This is a question worth discussing together. I think there may be the following reasons:

1. 1. Instant Value and Visibility: Tools are directly related to "actions", and their effects are immediate, making it easier to demonstrate the capabilities of AI Agents and meet the market's urgent need for "can-do things. By contrast, Prompts and Resources focus more on optimizing the depth and breadth of “understanding”, with a slightly longer chain of value transfer.
2. 2. Implementation threshold and standardization: The design and implementation of Tools can be compared with traditional API interfaces, and developers have mature paradigms to follow. The design of high-quality Prompts requires deep domain knowledge and insight into the temperament of the model; the management and efficient retrieval of Resources also involve more complex information architecture considerations.
3. 3. Host application maturity: At present, the MCP Host application itself is still iterating rapidly, and giving priority to ensuring the core Tool calling function is a natural choice. The refined support for Prompts and Resources requires Host to invest more in interactive design, user experience, and even built-in intelligent recommendation capabilities.
4. 4. Cognition and Habits: Developers and users may not fully recognize the huge efficiency improvements and experience improvements that structured, reusable Prompts and Resources can bring. Breaking the inertial thinking of "directly asking questions - direct calling" requires time and guidance from success stories.
5. 
   

06 / Will this situation change in the next six months?

Looking forward to the next six months, will the status of Prompts and Resources in the MCP ecosystem turn around? I am cautiously optimistic.

On the one hand, as large language model applications move from fresh to practicality, users' requirements for the reliability of results, the convenience of interaction, and a personalized experience are increasing. This will naturally drive MCP Server providers to think about how to improve the "availability" of the model through better Prompt design and how to enhance the "professionalism" of the model through rich resource support.

On the other hand, some cutting-edge thinking and practice have begun to appear in the community. For example, some teams dedicated to building complex agents may be the first to realize that relying solely on the generalization capabilities and on-site performance of the model itself is far from enough, and must be supplemented by high-quality "prompts" and "resources".

At the same time, we look forward to the MCP protocol itself or its extension proposals to provide clearer guidance and best practices on the discovery, registration, version management, and permission control mechanisms of Prompts and Resources, thereby lowering the implementation threshold of Host and Server.

07 / Conclusion: From "available" to "easy to use", regain the original intention of design

MCP's design is like a carefully outlined bridge, intending to connect the wisdom of the model with the vastness of the world. Tools are solid piers that provide interactive access. Prompts and Resources are the navigation and road books on the bridge deck, which determine the efficiency and scenery of traffic.

The reality is that we hurriedly built the piers and were eager to pass. In the future, it is time to lay flatter roads and set clearer guidance. From "knowing" the full picture of MCP to "practicing" its complete design philosophy, this is itself a journey of "understanding" and "transformation".

Looking forward to the next journey of MCP, Prompts, Resources, and Tools will work together to drive towards a smarter and better understanding of our future.