Seeing the Light: The Design Philosophy and Best Practices of MCP Core Concepts (Prompt, Resource, Tool)

Last weekend at the 2025 AIGC Shanghai Developer Conference (MCP lead Agent Internet new era) shared the theme of "large language model, Agent, MCP co-evolution trend of thinking" speech, sharing predictions for the next year, large language model, Agent, MCP ecological development trends, need PPT friends, you can click the card above to follow me, reply to the keyword ( MCP) can receive.

The content of this article is derived from one of the pages of the PPT in-depth thinking

The following is the text:

01 / Origin

The MCP (Model Context Protocol) ecosystem has been quietly developing for more than half a year, but looking around, most Server implementations seem to focus on the construction of Tools. When Google's A2A release categorized MCP as an Agent tool protocol, it made people think: Is MCP really just a tool protocol? Where are the original ideas and application blueprints for those elaborate Prompt and Resource concepts? Why do most MCP Servers only implement Tool functionality?

02 / Context in MCP: A Cornerstone of Modeling the World

To answer the above questions about the core concepts of MCP, we first need to go back to its name, Model Context Protocol. What does "context" mean? It is the information about our surroundings, the historical conversations, and the references we have at hand when we perceive the world. For a large language model, context is all the input it needs to think and act effectively. It usually consists of a few core components:

• Prompts: These are not only direct commands from the user, but also domain-optimized "signposts" that guide the model to efficient output.
• Static Resources: Like reference books or background materials at the model's desk, these can be documents, images, or URI-directed data, providing the model with the stable background knowledge needed for decision making.
• Tool Results: After a model interacts with an external tool, the results returned by the tool-whether successes, failures, or process data-become the key dynamic context for the model's next steps.

Together, these elements weave an "information field" for the model to understand the task, the environment, and even the user's true intentions.

03 / The Nature of MCP: A Connector for Models to Understand and Transform the World

If we stop at the above definition, we will only see the surface of the MCP protocol. What is the deeper nature of MCP?

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

Modeling the world of understanding: the read-only power of context

By model understanding the world, we mean that the model injects and interprets contextual information to recognize the user's environment, the specific details of the problem to be solved, and the immediate or non-immediate feedback generated during the execution of the task. This contextual information is read-only and idempotent to the environment, and does not have direct side-effects: Prompts for guidance, Resources for knowledge supplementation, and Tools for feedback on execution results.

1. Prompts: well-tuned scenario best practices

In MCP's design, Prompts are much more than simple questions that users type into a dialog box. I positioned them as a collection of best practices for instructions in a specific vertical.

Imagine an MCP Server that integrates Baidu's mapping capabilities, it should not just be able to passively respond to an atomic query like "find the nearest cafe". Ideally, it would proactively provide a series of carefully tuned Prompt templates, such as:

// Sample trip planning Prompt template:
Please help me plan a detailed 3-day driving trip with the following requirements:

 1 . Start at [origin name or latitude/longitude], destination at [destination name or latitude/longitude].
 2 . Pass at least3[type of point of interest, e.g., "national forest" or "historical and cultural attraction"]  along the way."Historical and Cultural Attractions"].
 3 . Avoid congested roads as much as possible (you can use real-time road conditions to determine this), and give preference to scenic roads (e.g. coastal highways or highly rated driving routes).
 4 . Limit the distance traveled to a maximum of [number of kilometers] kilometers  per day , and suggest that you  leaveat 8:30 and arrive at your accommodation by17:00. 5 .
5. recommend suitable fuel stops (with name, latitude and longitude, type of service) for each leg of the journey,at least once every150km.
 6 . recommend reasonable accommodation close to the end of the day's journey, with name, rating, price range and latitude/longitude.
 7 . return with a full routing proposal including:
 - list of starting and finishing points for each day's journey and a list of landmarks/attractions to be visited, with th eir latitude and longitude
 - estimated length and distance of each leg of the journey - estimated time and distance of each leg of the journey Estimated length and distance
 - Recommended list of daily refueling and lodging points

Please output in a structured format, calling on tools such as Map Search, Route Planner, Points of Interest Search, and other tools for parameter completions if necessary.

These templates have an optimized understanding of the parameters of the mapping service built into them, encapsulating the "best posture" for asking questions that can significantly broaden the user's horizons, guiding them to take fuller advantage of the model and the capabilities of the service behind it, and leading to far greater results than they could ever hope to achieve.

This is the core value of Prompts in MCP - lowering the threshold for quality results and improving the certainty and efficiency of interactions. The question is, why do most existing practices ignore this and simply leave the construction of Prompts to the MCP Host or end-user?

2. Resources: On-demand Injection of Static Knowledge

Resources are positioned in MCP as static, referenceable units of contextual information. It can be a piece of text, a document, a URI pointing to a knowledge base, or even an image, a video, or a data file in any agreed format.

These static resources can be valuable "deposits" generated by the MCP Server from past interactions (e.g., an analysis report, a design drawing, a dataset), or they can be pre-prepared examples, case studies, industry specifications, or up-to-the-minute data dynamically accessed through URIs.

{
  "resources":[
     { 
       "uri":"file:///travel_guides/beijing_classic_routes.md",
      "name":"Beijing Classic Tourist Routes Guide",
      "description":"Includes classic one-day itineraries of the Forbidden City - Tiananmen Square - Jingshan Mountain - the Beihai.
      "mimeType":"text/markdown"
     } 
 ] 
 }

According to the original intent of the protocol, the selection and injection of Resources is more likely to be carried out by people (users or developers) in specific scenarios, rather than being left to the judgment of the model , and the MCP Host will decide when and how to incorporate the content of these Resources into the final context given to the model based on the current task and the user's choices at the time of the application in order to assist the model in more accurately understanding the user's intent and the user's choice of content. MCP Host will decide when and how to incorporate these Resources into the final context for the model based on the current task and the user's choices, to help the model more accurately understand the user's intent and specific context.

Imagine that a user writing a market analysis report can actively @ bring in an industry benchmark Resource, or an excellent example Resource of a similar report, and the model can "stand on the shoulders of giants" in its creation. This explicit, controlled knowledge injection is a key consideration in Resource design.

3. Tools Execution Results: Instant Access to Dynamic Feedback

In order to accomplish complex tasks, AI Agents often require multiple rounds of collaborative invocation of multiple tools. In this cycle of "observe-think-act-observe", the execution result of each tool invocation, no matter successful or not, constitutes a 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 tries to book a flight (Tool call) and fails due to insufficient tickets, the result of this "failure" and the possible reasons (e.g., "Economy class is sold out, should we consider business class?") are the basis for the model to reflect and adjust. This is a direct input for the model to reflect on and adjust its strategy (e.g., ask the user if they want to upgrade to a new class, or change to a closer date).

Thus, the results of a Tool's implementation act as a dynamic context provider in the "understanding the world" phase, helping the model to continuously calibrate its perceptions as it interacts with the world .

Models Change the World: The Mystery of Tools' Dual Identity

After talking about understanding the world, let's look at how models "change the world". In the MCP framework, this is done through the execution of Tools - actions that have a Side Effect on the external environment, such as sending an email, creating a schedule, placing a purchase order, controlling a smart home, and so on.

However, the reality is interesting: whether it's read-only context for understanding the world (e.g., checking the weather, searching for knowledge), or performing write operations that have side effects, the industry seems to be united in packaging and implementing them as Tools , which creates a tension with the clear positioning of Prompts and Resources in providing context when designing protocols. This creates a tension with the clear positioning of Prompts and Resources in providing context during protocol design.

This "everything is a Tool" status quo, on the one hand, simplifies the implementation complexity of the MCP Server-it only needs to focus on one interaction mode; on the other hand, it blurs the essential distinction between different types of information interactions, which may result in a loss of potential for Prompts and Resources. On the other hand, it blurs the essential distinction between different types of information interactions, which may lead to the under-exploitation of Prompts and Resources. Is this phenomenon a contradiction between design and reality, or an inevitable convergence at a specific stage of development? It deserves our deeper consideration.

04 / Application Scenarios and Interaction Patterns: Bringing Complete MCPs to Life

To date, the MCP Host applications we know are almost exclusively focused on the use of Tools, and the native support and interaction design of Prompts and Resources seems to be a virgin land yet to be explored. This leaves us without a concrete picture of what a complete implementation of the MCP protocol trio can bring.

Based on our understanding of the underlying logic of the protocol, as well as some interviews with the official team, we can try to visualize and project the application scenarios and interaction patterns of Prompts and Resources in the MCP ecosystem.

Interaction and Scenarios of Prompts

Interaction Patterns:

1. 1. Implicit Triggering and Retrieval: In the input interface of MCP Host, users can quickly retrieve and select the high-quality Prompt templates provided by MCP Server by typing specific prefixes (e.g., / or the Chinese word for "evoke command") together with keywords. For example, by entering /Travel , you can list out multiple Prompt templates related to travel planning.
2. 2. Explicit list and guidance: MCP Host can clearly display a list of available Prompt templates in specific areas of the interface (e.g. Inspiration Panel, Assistant Suggestion Area) according to the currently connected MCP Server's capabilities, for users to browse and select, which is especially suitable for first-time users or users who want to explore the boundaries of the service capabilities.
3. 3. Model-driven and Intelligent Recommendation: based on the user's current input, conversation history, or the context of the task being processed, MCP Host's built-in assistant model can intelligently analyze the user's intent and actively recommend one or more highly relevant Prompt templates to achieve more intelligent guidance.

Application Scenarios:

1. 1. Baidu Maps MCP Server: Provides Prompt templates such as "Weekend Family Tour Planning", "Three-Day Hiking Route Design", and "Avoiding Traffic Restrictions on Commuting Programs". Prompt templates are available. Users only need to fill in a small amount of key information (e.g., destination, preferences) to get a highly customized travel plan after clicking on it.
2. 2. Xiaohongshu MCP Server: Provides Prompt templates such as "Hot [category] product review notes framework", "[city] shop-hunting tips creation guide", "[skill] learning experience sharing structure ", and so on. Prompt templates such as "[city] shop guide creation guide", "[skills] learning experience sharing structure", assist users to efficiently generate high-quality content in line with the tone of the platform. 3.
3. 3. Code Assistant MCP Server: Provide Prompt templates such as "Generate [language] code skeleton that conforms to [a design pattern]", "Write unit test cases for [function name]", "Explain the logic of this [heterogeneous language] code" and so on. Prompt templates such as "Write unit test cases for [function name]" and "Explain the logic of this [heterogeneous language] code" empower developers to quickly complete standardized, high-quality coding tasks.

Interactions and Scenarios of Resources

Interaction Patterns:

1. 1. @ Symbol Injection and Multiple Selection: Borrowing from mature code editors or knowledge management tools (e.g. Cursor's @ file/symbol, Notion's @ page/date), the user can use @ symbols to quickly search for 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 dialog when typing in MCP Host . The context of the current dialog can be dynamically injected into it.
2. 2. Context-aware Recommendation and Click Injection: When the user handles a specific task (e.g., writing a report, analyzing data), MCP Host can intelligently recommend related Resources (e.g., industry templates, historical cases, related data sets) based on the task characteristics and loaded MCP Server, and the user can click on them to inject them.
3. 3. Visualized List and Drag-and-Drop Management: MCP Host can provide a dedicated Resource management panel, so that users can clearly see the available public Resources provided by the current MCP Server, as well as the private Resources that they have the right to access, and support drag-and-drop injection or preset loading.

Application Scenarios:

1. 1. Enterprise Knowledge Base MCP Server: Internal rules and regulations, product manuals, best practice cases, FAQ, etc. can be used as Resources. When dealing with customer inquiries or internal collaboration, employees can quickly @ the corresponding documents, based on which the model provides more accurate answers or solutions. For example, customer service is dealing with after-sale issues @ Product Repair Manual Resource.
2. 2. Scientific Collaboration MCP Server: Researchers can register experimental data, references, project plans, meeting minutes, etc. as Resources. When writing a paper or conducting a project discussion, it is convenient to @ the relevant materials, and the model is able to provide analysis, summaries, or suggestions around these core materials.
3. 3. Educational Tutoring MCP Server: Teachers can register course syllabus, handouts of knowledge points, typical problem sets, and examples of excellent students' homework as Resources. When students ask questions or request for tutoring, they can @ the handouts of the relevant chapters or problem sets, and the AI tutor can then provide more targeted explanations and exercises.

Tools Interactions and Scenarios (Review and Outlook)

The interaction of Tools is relatively mature, usually the model analyzes the user's intention, decides which Tool to call, and assembles the parameters to initiate the request, and the Host is responsible for executing and returning the result.

Existing scenarios are very broad:

• Checking weather, stocks, news.
• Booking air tickets, hotels, restaurants.
• Send emails, set reminders, manage calendars.
• Execute code in the code editor, application refactoring.

The future imagination lies in more complex orchestration and deeper integration For example, a "one-stop travel planning" scenario may require the model to sequentially call: Airline Ticket Inquiry Tool, Hotel Booking Tool, Attraction Recommendation Tool, Local Transportation Planning Tool, and use the output of the former Tool as part of the input of the latter Tool, and at the same time, combine with the personal preference Resource ( e .g., "prefer quiet environment for accommodation" ) that is injected by the user via @ , and choose a Prompt template for "in-depth cultural experience tours". Resource (e.g., "Prefer quiet accommodation"), and a Prompt template for "In-depth cultural experience tours". That's the ideal picture of the three MCPs working together.

05 / Why is the industry focusing on Tools at the expense of Prompts and Resources?

This is a question we should discuss together. In my opinion, there may be several reasons:

1. 1. Immediate value and visibility: Tools are directly related to "actions", and their effects are immediately visible, making it easier to demonstrate the capabilities of AI agents and meet the market's urgent need for "can-do". In contrast, Prompts and Resources are more focused on optimizing the depth and breadth of "understanding", and their value delivery chain is a bit longer.
2. 2. Implementation threshold and standardization: The design and implementation of Tools can be compared to traditional API interfaces, and developers have a mature paradigm to follow. The design of quality Prompts requires deep domain knowledge and insight into model temperament; the management and efficient retrieval of Resources also involves more complex information architecture considerations.
3. 3. Host application maturity: Currently, the MCP Host application itself is still under rapid iteration, and it is a natural choice to prioritize the core Tool call functions. The refined support for Prompts and Resources requires Host to invest more in interaction design, user experience, and even built-in intelligent recommendation capability.
4. 4. Cognition and Habits: Developers and users may not have fully realized the huge efficiency and experience improvements that structured and reusable Prompts and Resources can bring. It will take time and success stories to break the inertia of "ask directly - call directly".
5. 
   

06 / Will this change in the next six months?

Looking ahead, will the status of Prompts and Resources in the MCP ecosystem change in the next six months? I am cautiously optimistic.

On the one hand, as large language model applications move from being a novelty to a reality, users will demand more and more reliability of results, ease of interaction, and personalized experience . This will naturally drive MCP Server providers to think about how to improve the "usability" of the model through better Prompts design, and how to enhance the "professionalism" of the model through rich Resources support.

On the other hand, some cutting-edge thinking and practices have begun to emerge in the community. For example, some teams working on building complex Agents may be the first to realize that it is not enough to rely only on the model's ability to generalize and play on the spot, but must be complemented by high-quality Prompts and Resources. "It must be complemented by high-quality Prompts and Resources.

At the same time, we expect the MCP protocol itself or its extension proposal to give clearer guidance and best practices on the mechanisms of Prompts and Resources discovery, registration, versioning, permission control, etc., so as to lower the threshold of Host and Server implementation.

07 / Conclusion: From "usable" to "usable", the original intention of the design is restored.

The design of MCP is like a well-drawn bridge, which intends to connect the wisdom of the model and the vastness of the world, with Tools being the solid piers, carrying the pathway of interaction, and Prompts and Resources being the solid piers. Tools are the solid piers that carry the path of interaction, while Prompts and Resources are the navigation and roadmap on the bridge, determining the efficiency and scenery of the passage.

The reality is that we hastily build the bridge piers and then rush to pass through. In the future, it's time to pave a smoother surface and set clearer guidelines. From "knowing" the whole picture of MCP to "practicing" its complete design philosophy, it is a journey of "understanding" and "transformation". This is a journey of "understanding" and "transformation".

We look forward to the next journey of MCP, in which Prompts, Resources, and Tools will drive hand in hand towards a smarter and more understanding future.