What Is MCP and How It Works
The Model Context Protocol (MCP) is a standard way for large language models (LLMs) to interact with external tools and real systems. An MCP server is the component that actually exposes those tools and executes real-world actions.
Rather than speaking in abstract terms, this article shows exactly what is exchanged between an LLM application and an MCP server, and how the loop between them works in practice.
The basic idea
An LLM cannot safely or reliably access databases, files, or APIs by itself. It can only generate text.
With MCP, the LLM is given structured descriptions of available tools. When it needs something from the outside world, it produces a structured request. The MCP server receives that request, runs real code, and sends back structured results. Those results are then fed back into the LLM so it can continue reasoning or produce a final answer.
In short:
- The LLM decides what should be done.
- The MCP server does it and returns the result.
MCP in practice: what is sent and what comes back
Think of MCP as a very structured chat between an LLM app and a tool server.
The LLM itself does not talk to your database or APIs. It only produces text like: “I want to call this tool with these inputs.” The MCP server is what actually runs the tool and sends back results.
Step 1: The MCP server advertises its tools
When an application connects to an MCP server, the first thing the server provides is a list of available tools and how to call them.
Example response from an MCP server:
Json
This information is placed into the LLM’s context. From this point on, the model knows which tools exist and what inputs they accept.
Step 2: The user makes a request
User input:
“Create a high priority ticket for [email protected].”
The application sends this message to the LLM along with the available tool descriptions.
Step 3: The LLM requests a tool call
Instead of responding in natural language, the LLM may choose to request a tool call.
Example LLM output:
Json
At this point, nothing has been executed. The LLM has only expressed intent: it wants the system to run a specific tool with specific inputs.
Step 4: The MCP server executes the tool
The application forwards the request to the MCP server.
The MCP server then:
- Validates the request
- Applies authentication and permissions
- Calls the real database or API
- Formats the result
Example MCP server response:
Json
Step 5: The result is returned to the LLM
The application feeds this result back into the LLM conversation. The model now has new factual context and can decide what to do next.
The LLM produces another tool request:
Json
Step 6: The MCP server runs the second tool
The MCP server creates the ticket in the real system and returns:
Json
Step 7: The LLM produces a final response
This result is again provided to the LLM. Now it has everything it needs to answer the user.
Final LLM output:
“Your high-priority ticket has been created. Ticket ID: TCK-9912.”
How the LLM–MCP loop works
Conceptually, the loop looks like this:
User → LLM → tool request → MCP server → real system ← tool result ← → LLM → final answer
The LLM never talks directly to internal systems. The MCP server is always the controlled execution layer.
A second short example: reading a file
User input:
“What’s in the Q3 report?”
LLM output:
Json
MCP server response:
Json
Final LLM answer:
“The Q3 report says revenue grew 18% quarter-over-quarter.”
The key takeaway
An MCP server is not an AI model. It is a tool server.
It exposes real capabilities (databases, files, APIs, workflows) in a standardized way. The LLM reasons about when and how to use those capabilities. The MCP server executes them safely and returns structured results.
This separation is what allows AI systems to move from isolated text generation to reliable, auditable interaction with real software systems.
