How Does MCP Actually Work Behind the Scenes? A Simple Mental Model

In my previous article, I introduced MCP and explained why so many companies are adopting it.

But what actually happens when an AI assistant uses an MCP server?

You don't need to understand every detail of the protocol to understand MCP. A simple mental model is enough.

The Big Picture

MCP Client (Claude, Cursor, ChatGPT, etc.)
                    │
                    ▼
               MCP Server
                    │
                    ▼
              Your Application

The MCP client is usually an AI application such as Claude, Cursor, ChatGPT, or Claude Code.

The MCP server sits between the AI assistant and your application. Its job is to expose information and functionality that the AI can discover and use.

You can think of it as another layer of abstraction between the AI client and your application's underlying APIs or services.

Claude
   │
   ▼
MCP Server
   │
   ▼
Your APIs / Services

But where does the MCP server come from?

Someone has to build it.

In many cases, the company behind the product provides an official MCP server. For example, GitHub, Linear, and other companies now offer MCP servers that expose functionality from their platforms to AI assistants.

If your company wants AI agents to interact with its products, your team would typically build and host an MCP server that AI clients can connect to.

Much like a REST API allows developers to interact with your application, an MCP server allows AI agents to interact with it.

What Does an MCP Server Expose?

At a high level, an MCP server can expose three types of things:

MCP Server
│
├── Tools
├── Resources
└── Prompts

Tools

Tools are actions the AI can perform.

Examples:

create_ticket
search_issues
send_message

When you ask Claude to create a Linear ticket, it is typically invoking a tool exposed by the Linear MCP server.

Resources

Resources are information the AI can read and use as context.

For example, imagine your company exposes its product documentation as a resource. An AI assistant could retrieve that documentation to answer questions or better understand how to use your product before invoking any tools.

A simple way to think about it:

• Tools → the AI wants to do something

• Resources → the AI wants to know something

Prompts

Prompts are reusable instructions exposed by the MCP server.

For example, a company might provide prompts such as:

• Summarize a project

• Review code changes

• Explain an error message

Rather than requiring every client to define these instructions, they can be exposed directly by the MCP server.

A simple way to think about it:

• Tools → the AI wants to do something

• Resources → the AI wants to know something

• Prompts → the AI wants guidance on how to do it

How Does the AI Know What's Available?

Before an AI assistant can use a tool, it first needs to discover what the MCP server provides.

A simplified version of that conversation looks like this:

Client
  │
  ├── initialize
  │
  ├── tools/list
  │
  ├── resources/list
  │
  └── prompts/list

Think of it as the AI asking:

What can you do?

The server responds with the tools, resources, and prompts it makes available.

How Do Clients and Servers Communicate?

All interactions between an MCP client and an MCP server happen through messages.

MCP standardizes these interactions using JSON-RPC, a lightweight protocol for request and response communication.

Those messages travel through a transport layer. MCP supports transports such as stdio and HTTP, which determine how the client and server communicate with each other.

Most developers interact with MCP through SDKs, which handle much of the underlying protocol and transport details for you. This allows developers to focus on the functionality they want to expose rather than the mechanics of the protocol itself.

What Happens When a Tool Is Used?

Let's say you ask Claude:

Create a Linear ticket for a login bug.

The flow looks something like this:

User
 │
 ▼
"Create a Linear ticket"
 │
 ▼
Claude
 │
 ▼
tools/call(create_ticket)
 │
 ▼
Linear MCP Server
 │
 ▼
Linear

Claude invokes the appropriate tool, the MCP server performs the operation, and the result is returned back to Claude.

Bringing It All Together

           MCP Client
      (Claude, Cursor, etc.)
                   │
                   ▼
             MCP Server
        ┌──────┼──────┐
        ▼      ▼      ▼
      Tools Resources Prompts
                   │
                   ▼
      APIs / Databases / Services

The client discovers what the server exposes and uses tools, resources, or prompts as needed.

That's the core mental model behind MCP.

In the next article, we'll look at what you actually need to build your own MCP server.