The application requests data from a service through a communication component, the service returns results, and then the application decides how to use them. The model does not spontaneously gain access to all information on the computer or external systems.
It is recommended to first understand MCP's Role and Use Cases. This page uses the accompanying course materials for experimentation to explain roles and information flow; no prior programming knowledge is required.
What Applications, Clients, and Services Each Do
| Name | Everyday Explanation | What It Is in This Experiment |
|---|---|---|
| Host Application (Host) | Manages tasks, UI, or other functions, decides which services to connect to | The command-line teaching client provided by the project, organizes this experiment; does not connect to a model |
| Client | A component within the application responsible for communicating with a single service | The ClientSession from the official SDK |
| Server | A program that provides specific capabilities or data | The course materials program provided by the project, only exposes fixed data reading and template capabilities |
In everyday AI applications, the Host also organizes user requests, models, and result display. To isolate protocol verification, this experiment shrinks this part into a command-line program that actually executes communication but does not call the model. This should not be used to claim that any desktop AI product has completed integration.
Client and service negotiate version and capabilities; client sends initialization completion notification.
Client → ServerClient sends tools/list, service returns tool names, descriptions, and parameters.
Client ↔ ServerClient sends tools/call with course ID and other parameters.
Client → ServerService returns materials or error; application verifies if required content was obtained.
Server → Client → HostThe method names in the diagram belong to the protocol 2025-11-25 used in this experiment. Applications may use other supported versions; do not treat these initialization messages as a process that remains unchanged across all versions forever.
Step 1: First, Learn What Both Sides Can Do
In this version, the client first sends an initialization request, and both parties agree on the protocol version and declare supported capabilities. When a service declares support for tools, resources, or prompt templates, it does not guarantee that it provides every specific operation you might want.
You can then query specific lists. For example, the tools list returns get_course_material, with a description indicating that a course ID is required. This description lets the application know how to make the request. When connection versions are incompatible or required capabilities are missing, these should be handled here—you should not guess a tool name and continue.
Step 2: Request a Specific Capability
The core of the request to read this lesson is:
{
"name": "get_course_material",
"arguments": {"course_id": "silk-road-01"}
}This is a human-readable excerpt of parameters, not a complete protocol message. The service looks up fixed example data by course ID and returns the course title, student background, 40-minute session duration, and M01–M03 content. If you use a non-existent ID, the actual experiment yields an error.
The protocol specification governs how the two parties communicate; whether data exists, whether content is current, and whether accounts can access it are determined by the service and actual environment.
Step 3: How the Application Passes Results to the Model
In a real AI application, after obtaining returned data, it can select relevant content and place it into the Context that the model can reference for this request. The application may also filter, truncate, or process the data first; connecting to a service does not mean the entire database has been loaded into the model input.
The model can then generate answers or propose follow-up operations based on this data. The correctness of this stage differs from whether the protocol call succeeded—you should verify against original sources, user requirements, and actual output. This experiment ends after returning and verifying the data, without executing this model generation stage.
How Tools, Resources, and Prompt Templates Differ
| Capability | What You Get | Verified Examples in This Experiment |
|---|---|---|
| Tool | Result of an operation, which may be data or an error | get_course_material returns data by course ID; tools can be read-only queries or other operations |
| Resource | Content retrieved by identifier | course://catalog returns the course catalog |
| Prompt Template | A reusable requirement with parameters to fill in | prepare_lesson returns lesson preparation requirements containing the course ID; retrieving the template itself does not generate a lesson plan |
In the referenced specification, tools are typically meant for model invocation, resources are handled by the application, and prompt templates are for user selection. Specific interfaces may vary. This experiment directly calls these capabilities for repeatable verification, without simulating autonomous model selection.
The "Prompt" in prompt templates relates to everyday prompts—both are requests or interaction content; MCP additionally specifies how templates are listed and retrieved. Skills can organize methods, templates, and other materials into a package; the two terms are not directly equivalent.
Local vs. Remote: What's the Difference?
This experiment uses standard input/output (stdio)—the client starts a local service program, and messages are exchanged through inter-process input and output. No public URLs, remote accounts, or listening ports are required.
Remote services can use HTTP connections, where the application communicates by address and may require authentication. Whether a transport method, protocol version, and authorization flow are supported must be verified for both application and service. Filling a local command into a settings field that only accepts URLs typically fails to establish a connection.
Why Permissions Still Matter
Tool descriptions may include "read-only" markers, but descriptions or annotations cannot replace real restrictions. This example only implements reading fixed files by existing course ID, does not accept arbitrary paths, and does not provide modification, deletion, or sending tools.
This means the scope of operations exposed by MCP is limited; it does not turn the entire service process into an OS-level read-only sandbox. When switching to a service that can modify business systems, you should verify its actual access control and provided operations—do not assume permissions are the same just because it is also called MCP.
Think About It
You have successfully retrieved a lesson preparation prompt template. Does this mean you have queried the course materials, called the model, and generated a lesson plan?
Reference answer: No. A template is a reusable requirement; reading materials and generating a lesson plan are separate subsequent actions, each requiring its own result evidence.
Next Steps
Read Practical Usage and Reproduction Guide to compare against actual returned results; or return to the MCP Basics page to continue with other topics.
Sources and Scope
Verification date: 2026-09-09. Role explanations reference the MCP Architecture Description. The experiment steps respectively reference the protocol 2025-11-25's Lifecycle, Tools, Resources, and Prompt Templates. The experiment SDK is Python SDK v1.26.0. The diagram is a mechanism illustration organized according to the actual experiment flow; original results are stored separately in verification records.