Introduction to MCP for Developers

Update November 2, 2026 — Le Chat is now Vibe. As of May 28, 2026, Le Chat has been rebranded as Vibe (still at chat.mistral.ai): a single agent for work and code, carrying over your conversations, settings, and subscriptions. The legacy Le Chat experience remains accessible in Chat mode; in Work mode, agents have become skills (invoked with @), memories have become the knowledge base, and deep search has become the Deep Research skill. The plans are now called Mistral Free, Pro, Team, and Enterprise. This lesson uses the name Vibe; some menus described here may have changed names or locations.

Why MCP Is a Game-Changer for Developers

The Model Context Protocol (MCP) is an open standard that redefines how AI applications interact with the outside world. Before MCP, every framework imposed its own grammar for declaring and calling a tool: LangChain had one, CrewAI another, and Mistral Agents and OpenAI Assistants had yet others. In practice, a developer who wrote a connector for their billing API in LangChain had to rewrite it entirely to make it work in CrewAI, and then a third time for a custom in-house agent. Work was duplicated with every tooling change, and sharing a tool between teams was a patchwork effort.

MCP solves this problem with a unified communication protocol between an AI client and tool servers. The best analogy is a USB port: no matter the client—Claude, Vibe, Cursor, VS Code—and no matter the server—GitHub, Notion, your internal API—the connection format stays the same. You write your connector once, and it works everywhere.

The Client-Server Architecture

MCP relies on a deliberately simple client-server architecture. On one side, the client is the application implementing the AI: a chatbot like Mistral’s Vibe or Claude, a development environment like VS Code or Cursor, or an agent SDK such as the Mistral Agent SDK or the Claude Agent SDK. On the other side, the server is the program that exposes capabilities—tools, resources, and prompts—to that client.

The entire conversation between the two happens in JSON. The client starts by asking the server what tools it offers; the server responds with a text description of each one: its name, parameters, role, and return format. The language model uses this description, and this description alone, to decide when and how to call a tool.

Client (Vibe)                 MCP Server (GitHub)
      |                              |
      |--- "What tools do you have?" ->|
      |<-- JSON tool descriptions -----|
      |                              |
      |--- Call: create_issue({}) --->|
      |<-- JSON Result ---------------|

How MCP Differs from Function Calling

Classic function calling and MCP are not mutually exclusive; they simply draw the boundary in different places. With function calling, you define tools on the client side, pass them to the model, and manage their execution yourself—each framework having its own definition format. With MCP, tools live on a server, local or remote; the client knows only the text description, and the server handles execution.

The decisive advantage is reusability. A GitHub MCP server written once plugs indifferently into Vibe, Claude, Cursor, or your own SDK without a single line of rewriting. This is what turns an internal connector into a shareable building block at enterprise scale.

The Three Protocol Primitives

MCP is not limited to tools. The protocol defines three types of capabilities, distinguished by what the server actually makes available. Tools are executable functions: create a ticket, send an email, query an API—the model triggers them to act on the world. Resources are readable data—files, databases, documentation—that the client can read without triggering any action; exposing the content of a configuration file falls into this category, not tools. Finally, prompts are reusable prompt templates with parameters: a team server can thus distribute a proven code review instruction, rather than leaving everyone to rewrite it from memory.

In practice, tools account for about 90% of current use cases: they are what you connect first, and often the only things you implement. However, resources and prompts open up possibilities that we will explore in detail in Lesson 3.

The Model’s Decision Flow

When a user asks the client a question, the model runs through a five-step cycle:

1. It receives the question and the list of available tools (MCP descriptions)
2. It decides: answer directly, or call a tool?
3. If it calls a tool, it formulates the arguments in JSON
4. The server executes and returns the result
5. The model integrates the result and formulates its response (or calls another tool)

This cycle repeats as many times as the task requires. Imagine a user asking to turn a complaint spotted on Reddit into a development ticket: the model queries Reddit, creates an entry in Linear, then opens the corresponding GitHub issue—three servers chained together, without the user ever leaving the chat interface.

A Rapidly Expanding Ecosystem

As of April 2026, hundreds of MCP servers are available: GitHub, Notion, Slack, Gmail, PayPal, Hugging Face, Semgrep, and many others. Major AI clients support the protocol natively. More importantly, nothing limits you to consuming what already exists: you can create your own servers to expose your internal tools, business databases, or custom procedures.

That is precisely the goal of this course: to enable you to understand, use, and build MCP servers in Python.

Key Takeaways

• MCP is an open standard for client-server communication in AI
• It unifies the fragmented function calling ecosystem
• The architecture relies on a client (chatbot, IDE, SDK) and a server (tools, resources, prompts)
• Communication happens in JSON using text descriptions
• An MCP server is reusable across all compatible clients