MCP Technical Architecture

Updated November 2, 2026. Le Chat is now Vibe. As of May 28, 2026, the platform formerly known as Le Chat (still at chat.mistral.ai) is now Vibe: 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 are now skills (invoked with @), memories form the knowledge base, and deep search is the Deep Research skill. 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.

Understanding the Protocol Mechanics

Using a connector requires no technical knowledge. Diagnosing issues when it misbehaves, choosing the right authentication mode, or deciding where to host your own server, however, requires knowing what happens under the hood.

Transport Modes

The protocol defines two main transport categories. The first, STDIO (Standard Input/Output), is designed for servers running on the same machine as the client: communication uses the operating system’s standard input and output streams. You’ll find it in command-line tools, local file system access, and desktop application integration. The advantage is obvious—no network, immediate execution—but so is the limitation: STDIO works only locally and remains unusable with Vibe, which is a cloud service. It’s the preferred mode for IDEs like VS Code or Cursor, where the server runs directly on the developer’s machine.

The second category, Streamable HTTP, is the current standard for remote servers. It replaced the SSE (Server-Sent Events) protocol, whose major drawback was requiring a permanent connection between client and server. Streamable HTTP eliminates this requirement, making it more robust and easier to scale; it suits cloud services, third-party APIs, and tools shared between teams, and exposes its endpoint at the URL /mcp. SSE is still accepted by most clients, but it is considered deprecated and expected to disappear in the coming months: do not write new servers based on it.

For Vibe, the consequence is direct: as a cloud application, it only communicates with remote servers, and a server on your localhost means nothing to it. If you develop an MCP server and want to test it, two paths are open to you—deploy it to a cloud service, or expose it temporarily with a public URL via a tool like ngrok.

Authentication Mechanisms

Three security levels coexist. The simplest is no authentication: the server is accessible to anyone who knows its URL, suitable for public tools handling non-sensitive data, for example, a server that fetches public information from Reddit or returns the weather.

The second level relies on an access token that you generate from the relevant service, with a specific scope of rights—read-only, write, access to certain repositories. The GitHub connector is a typical example: you create a Personal Access Token checking exactly what Vibe will be able to do, read your repos, create issues, open pull requests. This token is stored securely and linked to your user account, never to the organization.

The third level, OAuth 2.0, offers the most complete integration. Rather than handling a token manually, you authorize Vibe to access your account via a standardized flow. On the Linear connector, clicking « Connect » opens an authorization window; once confirmed, Vibe gets full rights to your account and you can revoke them at any time. The benefit is twofold: no manual handling of secrets, and immediate revocation in case of doubt.

Multi-Server Architecture

In practice, Vibe never talks to just one server but to several simultaneously, each bringing its own tools, prompts, and resources. When a server is activated, Vibe first sends it a discovery request, to which the server responds by describing in text each available tool:

{
  "name": "get_weather",
  "description": "Returns the weather for a given position",
  "parameters": {
    "latitude": { "type": "float", "description": "Latitude" },
    "longitude": { "type": "float", "description": "Longitude" }
  },
  "returns": "string"
}

This description is the only element the model has to decide when and how to use the tool. A vague description like “does things with data” dooms the tool to never be called at the right time. MCP server creators must therefore craft the wording as carefully as the typing and examples.

With each message, the model then runs a decision loop: it analyzes the request, determines if one or more tools are needed, selects the most relevant and prepares its arguments, sends the request to the server and waits for the result, then decides whether to call something else or if it can formulate its response, before synthesizing everything in natural language. This loop can run several times and engage different servers within the same conversation.

Performance Considerations

Two factors condition the quality of the experience. The first is the number of tools: like any agent system, the model loses precision as the list grows. Activate only the connectors useful for the task at hand, turn off those you no longer need, and prefer specific, well-described tools over generic ones. The second is latency: each MCP call is a network request, whose cost depends on the location and performance of the server. For a critical workflow, choose optimized and geographically close servers.

Key Takeaways

• Vibe uses Streamable HTTP mode to communicate with remote MCP servers
• Three authentication levels are supported: none, token, and OAuth 2.0
• Vibe can connect to multiple MCP servers simultaneously
• The model uses text descriptions of tools to decide when to use them
• Limit the number of active connectors to optimize model precision