Every MCP interaction, no matter which server or tool is involved, follows the same shape. This lesson traces one complete, realistic example through every step, using the official Filesystem reference server.
Learning Objectives
- Trace a complete MCP request from user input to a returned result.
- Read a realistic tool registration and invocation together.
- Decide when MCP is actually the right choice versus a plain REST API call.
The Scenario
A user, working inside an MCP-compliant host application, asks: "Summarize what's in today's error log." The host has an active connection to the Filesystem reference server.
The Full Workflow
User Asks
Model Decides: Needs a Tool
Client Calls Server
Filesystem Server Reads File
Result Returns
The model itself decides a tool call is needed here, it can't read a local file directly, so it requests the read_file tool through the client rather than guessing at the log's contents.
Step by Step, With the Actual Messages
{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }
// Server responds with: read_file, write_file, list_directory, ...{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "read_file",
"arguments": { "path": "/var/log/app/error.log" }
}
}{
"jsonrpc": "2.0",
"id": 2,
"result": {
"content": [
{ "type": "text", "text": "[ERROR] 03:12:01 DB connection timeout\n[ERROR] 03:14:55 DB connection timeout\n..." }
]
}
}"Today's error log shows repeated database connection timeouts starting around 3:12 AM, occurring roughly every 2-3 minutes. No other error types appear."
Steps 1 through 3 all happen through the protocol, structured, predictable JSON-RPC messages. Step 4 is the model doing what it's actually good at, turning retrieved information into a clear, readable answer, once it already has the real data in hand.
When MCP Is the Right Call vs a Plain REST API
| Situation | Better fit |
|---|---|
| An AI model needs to decide, at runtime, whether and how to access a tool | MCP |
| A fixed, predetermined API call your own application code always makes the same way | A plain REST API call |
| Multiple different AI applications need the same integration | MCP (built once, reused everywhere) |
| A one-off internal script with no AI decision-making involved at all | A plain REST API call |
MCP earns its complexity specifically when an AI model needs to dynamically decide to use a tool, and when that tool should be reusable across more than one application. For a fixed, predetermined integration your own code always calls the same way, a direct API call is simpler and perfectly sufficient.
Common Beginner Mistakes
- Skipping the tools/list discovery step and hardcoding assumptions about what a server exposes, servers can add, remove, or change tools.
- Reaching for MCP for a fixed, internal integration an application always calls the same way, where a direct API call would be simpler.
- Forgetting that step 3's raw tool result still needs the model to actually turn it into a useful answer, the protocol delivers data, it doesn't summarize it on its own.
- Not handling the case where a tool call fails or returns an error, a real workflow needs to account for that path too, not just the success case.
FAQ
Does the model always call tools/list before every single tool call?
Not necessarily every time, a host application can cache the list of available tools after the initial discovery and only re-check if it suspects the server's capabilities changed. The first connection typically does discover what's available.
What happens if the file in this example doesn't exist?
The server would return a JSON-RPC error response instead of a successful result, which the host and model then need to handle, for example, by informing the user the file couldn't be found, rather than fabricating log content.
Could this same workflow use a different server instead of Filesystem?
Yes, the shape stays identical regardless of which server is involved, tools/list, tools/call, a result. Only the specific tool name, arguments, and what happens inside the server change.
Interview Questions
Walk through what happens, step by step, when a model needs to read a local file through MCP.
The client discovers available tools (tools/list), the model decides a tool call is needed and requests it (tools/call with the file path), the server executes the read and returns the content, and the model then turns that raw content into a useful, readable answer for the user.
In this workflow, which step is the model actually responsible for, versus the protocol?
The protocol handles discovering and invoking the tool and returning raw data. The model is responsible for deciding a tool call is needed in the first place, and for turning the raw returned data into a clear final answer, neither of those is something the protocol does on its own.
When would a plain REST API call be a better choice than building an MCP integration?
When the integration is a fixed, predetermined call your own application code always makes the same way, with no AI model needing to dynamically decide whether or how to use it, and no need to reuse it across multiple different applications.
Why does the client call tools/list before tools/call, rather than just calling the tool directly?
The client and model can't assume in advance which tools a given server exposes, or exactly what arguments each one expects, discovery ensures the tool call it eventually makes actually matches what the server currently supports.
Summary
A complete MCP workflow follows one consistent shape regardless of the server involved: discover available tools, the model decides a call is needed and requests it, the server executes and returns raw data, and the model turns that data into a final answer. MCP is worth its complexity specifically when a model needs to dynamically decide to use a tool that's reusable across applications, not for a fixed, one-off integration a plain API call would handle just as well.
What's Next?
That completes the MCP section. The final lesson in this course brings RAG and MCP together, comparing both directly now that each has been covered in full.