What is MCP? — Complete Guide

Curso MCP Engineering · M0

This guide explains, from scratch and taking nothing for granted, what the Model Context Protocol (MCP) is, what problem it solves, and the vocabulary you'll work with throughout the course. Read it slowly: if you understand this guide, the rest of the course will feel natural.

In one sentence

MCP (Model Context Protocol) is an open standard for connecting artificial intelligence applications (like Claude) with external tools and data (your GitHub, your database, your calendar, a weather API…). The core idea: you build the connection once and it works everywhere.

A "standard" is simply an agreement about how two programs talk to each other. When everyone follows the same agreement, they no longer have to invent a different way for every combination.

The problem it solves — the "N×M problem" explained

First, what those two letters mean:

• M = the number of AI applications that exist (Claude Desktop, an editor like Cursor, your own app, ChatGPT…).
• N = the number of tools or data sources you want to connect (GitHub, Slack, Google Drive, a database, an API…).

Without a standard, each application has to build a custom connection for each tool. In other words, you have to build M × N different connections (M multiplied by N), each one by hand.

Let's look at it with concrete numbers. Suppose 3 AI applications and 4 tools:

That's 3 × 4 = 12 connections built by hand. Each of those cells is code that someone has to write, test, and maintain. If a new app appears tomorrow, you have to add 4 more connections; if a new tool appears, 3 more. It grows very fast, it's expensive, and it breaks often.

With MCP the problem flattens to M + N (M plus N, not multiplied):

• Each application learns to "speak MCP" once (3 times total).
• Each tool exposes an MCP server once (4 times total).
• Result: 3 + 4 = 7 pieces, and everything connects to everything automatically.

We go from 12 custom connections to 7 reusable pieces. And best of all: when you add a new app, as long as it speaks MCP it already works with the 4 tools that existed. That's the leap.

The idea to remember: MCP turns a problem that multiplies (M×N) into one that adds (M+N). Less work, fewer things that break, everything reusable.

Analogies that help (you've seen something like this before)

MCP isn't the first time a standard has solved this kind of mess:

• APIs standardized how the front-end (what you see on screen) talks to the back-end (the server). Before, everyone did it their own way; today there are common conventions.
• The LSP (Language Server Protocol) standardized how your code editor understands any programming language. Thanks to it, a single editor works for Python, Go, Rust… without reinventing the integration for each one.
• MCP does the same for AI: it standardizes how an AI talks to tools and data.

The three roles (the course vocabulary)

In MCP there are always three parts. You'll name them in every lesson, so it's worth having them clear:

• Host: the AI application where you work. Examples: Claude Desktop, an editor like Cursor or VS Code. It's "the house" where the conversation with the model lives.
• Client: a connector that lives inside the host. There is one client per server you connect to. It's the "translator" that speaks MCP with one specific tool.
• Server: the program that exposes capabilities (tools, data) through MCP. This is what you'll learn to build in this course.

Watch out, an important nuance: "client" and "server" are logical roles, not different computers. A single application can be a server for one thing and a client for another at the same time. Don't think of two machines; think of two parts.

A server's three primitives (a preview of Module 1)

When you build a server, you'll expose capabilities of three kinds. They're called "primitives" because they're the basic pieces everything is built from:

• Tools: functions that the model decides to run in order to do something (search an API, write to a database, send a message). They are actions.
• Resources: read-only data that the application attaches as context (a file, an image, a JSON). They don't run anything; they provide information.
• Prompts: reusable templates triggered by the user (for example, a command like /summarize). They give the user ready-made shortcuts.

The key difference is who controls each one: tools are controlled by the model, resources by the application, and prompts by the user. That separation is intentional and you'll understand it in detail in Module 1.

A real-life example

Imagine you ask Claude: "Check the open issues in my repository and create a task for each one in my project manager." To do this:

1. Claude (the host) uses an MCP client to talk to GitHub's server.
2. That server exposes a "list issues" tool → Claude runs it and receives the list.
3. Another server (the task manager's) exposes a "create task" tool → Claude runs it once for each issue.

All of that works without anyone having programmed a specific "Claude ↔ GitHub ↔ task manager" integration: each tool exposed its MCP server once, and Claude speaks MCP. That is M+N in action.

Glossary

• MCP (Model Context Protocol): open standard for connecting AI with tools and data.
• Standard: a common agreement about how two programs communicate.
• N×M / M+N: the integration problem that multiplies (by hand) vs. the one that adds (with MCP).
• Host: the AI application where you work.
• Client: connector inside the host; one per server.
• Server: the program that exposes capabilities via MCP — what you'll build.
• Tool / Resource / Prompt: the three primitives a server exposes (action / data / template).

To remember

1. MCP is a standard for connecting AI with tools and data.
2. It turns the N×M problem (hand-built integrations, they multiply) into M+N (reusable pieces, they add up).
3. The three roles: host, client, server — and you'll learn to build servers.
4. A server exposes tools, resources, and prompts.

Turning Point Academy · MCP Engineering Course · Module 0 · Lesson 0.1