Model Context Protocol (MCP): 30 Questions and Answers on the Open Standard for AI Integrations

Model Context Protocol: The Open Standard for AI Integrations  

AI applications such as Claude, ChatGPT and Cursor are only truly useful once they can reach external data, tools and APIs. Until recently, every integration meant building a bespoke connection – a fragmented M-by-N problem in which every combination of AI application and data source had to be wired up by hand. The Model Context Protocol (MCP) removes that burden with an open standard that connects AI applications to external systems in a single, consistent way .

Anthropic released MCP in late 2024 and describes it as "USB-C for AI applications" : rather than building a separate adapter for every data source, MCP defines a universal protocol through which any AI host can talk to any server. It is built on JSON-RPC 2.0, supports stateful connections and is now backed by a broad alliance – including Claude, VS Code, Cursor, Gemini CLI and Amazon Q, among many others; for ChatGPT, OpenAI states that the scope currently depends on the plan, mode and deployment .

Whether you are trying MCP for the first time or refining an existing architecture, this article gives you 30 well-researched answers, from the fundamentals and architecture through to security and best practices.

Interactive Demo: MCP in Action  

Explore the three core concepts of MCP step by step, from the architecture through the JSON-RPC lifecycle to tool calling:

JSON-RPC-Nachricht erscheint nach Start...

Antwort erscheint nach Simulation...

Table of Contents  

Quick Overview: All 30 Questions  

Click on a question to jump to the detailed answer.

Category 1: Fundamentals & Concepts  

Category 2: Architecture & Components  

Category 3: Transport & Connections  

Category 4: Server Features in Detail  

Category 5: Ecosystem & Clients  

Category 6: Security & Best Practices  

Category 7: Practice, Dos & Don'ts  

1.1. What is the Model Context Protocol and what problem does it solve?  

Short answer: MCP is an open standard from Anthropic that connects AI applications to external data sources, tools and APIs through a single, unified protocol – solving the M-by-N problem of fragmented integrations .

Detailed explanation:

Without MCP, every AI application (Claude, ChatGPT, Cursor and so on) has to build its own integration for every data source (GitHub, Slack, databases and the rest). With M applications and N data sources, that adds up to M × N separate connections – a huge effort that scales badly .

MCP brings this down to M + N: each AI application implements the MCP client once, and each data source implements the MCP server once. From then on, every client can talk to every server .

Real-world use cases from the MCP documentation include connecting Google Calendar and Notion to an AI, turning Figma designs straight into web applications, querying enterprise databases in plain language, and creating 3D designs in Blender through AI .

1.2. How does MCP differ from classic API integrations?  

Short answer: Classic APIs are static and purpose-built; MCP adds dynamic discovery, standardised capability negotiation and stateful sessions within a single, unified protocol .

Detailed explanation:

A decisive advantage is dynamic tool discovery: an MCP server can change the tools it offers at runtime and notify the client via notifications/tools/list_changed. The client then calls tools/list again and immediately knows the new capabilities – no restart or manual intervention required .

On top of that, client and server negotiate their capabilities when the connection is established: which primitives are supported? Which protocol version? This handshake makes MCP connections more robust and future-proof than rigid API contracts .

1.3. Who developed MCP and who supports it?  

Short answer: Anthropic built MCP and released it as an open standard. It is now supported by Microsoft (VS Code, GitHub Copilot), Google (Gemini CLI), Block, Amazon and numerous tool vendors; for OpenAI/ChatGPT, the scope of MCP currently depends on the plan, mode and use case .

Detailed explanation:

Anthropic published MCP as an open standard with the aim of replacing fragmented AI integrations with a single, unified protocol . Early adoption has been remarkably fast:

Block CTO Dhanji R. Prasanna sums up its significance: "Open technologies like the Model Context Protocol are the bridges that connect AI to real-world applications" .

The full specification, all SDKs and the reference servers are available at github.com/modelcontextprotocol under an open licence , and the community can contribute directly to its development.

1.4. What does the "USB-C for AI" analogy mean?  

Short answer: Just as USB-C gives devices a universal connection, MCP gives AI integrations a universal standard – one protocol in place of many proprietary adapters .

Detailed explanation:

The official MCP introduction puts it like this: "Think of MCP like a USB-C port for AI applications" . The analogy holds on several levels:

The comparison highlights the core benefit: instead of building a bespoke integration for every combination of AI application and data source, both sides implement the MCP standard once. The result is universal compatibility – every MCP client works with every MCP server, just as every USB-C device works with every USB-C cable.

1.5. What is the relationship between MCP and the Language Server Protocol?  

Short answer: MCP is inspired by the Language Server Protocol (LSP) and applies its principle – standardised communication between hosts and capability servers – to the world of AI integrations .

Detailed explanation:

LSP solved a similar M-by-N problem in the IDE world: rather than writing a separate language service for every combination of editor and programming language, LSP defined a single, unified protocol. As a result, one language server for Python works in VS Code, Neovim and any other LSP-compatible editor.

MCP applies exactly this principle to AI applications :

Both protocols build on JSON-RPC and follow the principle of capability negotiation: when they connect, server and client agree on which features they support. By taking its cue from LSP, MCP lets developers with LSP experience get up to speed quickly.

2.1. How is the MCP architecture structured (Hosts, Clients, Servers)?  

Short answer: MCP follows a three-layer architecture: the host (e.g. Claude Desktop) manages multiple clients, each of which maintains a 1:1 connection with a server .

Detailed explanation:

Each of the three layers has a clearly defined role :

A concrete example from the MCP documentation: VS Code acts as a host and internally spins up one MCP client for the Sentry connection and another for file system access. Each client negotiates its capabilities independently with its respective server .

Two further levels sit beneath these architectural layers: the data layer (JSON-RPC 2.0 as the message format) and the transport layer (stdio or Streamable HTTP as the transmission channel) .

2.2. What are the three server primitives (Tools, Resources, Prompts)?  

Short answer: MCP servers expose three kinds of capability: Tools (model-driven actions), Resources (application-driven data) and Prompts (user-driven interaction templates) .

Detailed explanation:

The key difference comes down to who is in control – that is, who decides when each primitive is used :

Tools are the most commonly used primitive: the LLM decides which tool to call based on the context. Tools can have side effects (such as sending emails or writing files) and return structured results .

Resources, by contrast, simply provide data: the application decides which resources to include as context. They behave much like GET endpoints in REST – read-only and addressed via URIs such as trips://history/ .

Prompts are invoked explicitly by users, typically as slash commands. A plan-vacation prompt might expect structured arguments such as destination and travel dates, and turn them into a multi-part conversation .

2.3. What are client primitives (Sampling, Elicitation, Roots)?  

Short answer: Client primitives are back-channel capabilities that the server can request from the client: Sampling (LLM completions), Elicitation (structured user input) and Roots (file system boundaries) .

Detailed explanation:

Where server primitives deliver data and functions to the client, client primitives open up the reverse path – the server can make requests back to the client :

Sampling is especially powerful: it enables agentic behaviour within a server's features. The server can effectively "ask the LLM for advice" without needing its own API key – the request goes through the client, which controls access to the model .

Elicitation is a newer primitive introduced in the current specification. It is deliberately limited to flat objects with primitive properties (String, Number, Boolean, Enum) .

Roots tell the server which working context applies – for example file:///home/user/project/. They are intentionally advisory and not technically enforced, which keeps things flexible .

2.4. How does the protocol lifecycle work?  

Short answer: The MCP lifecycle has three phases: initialisation (capability negotiation), operation (bidirectional message exchange) and shutdown (closing the connection cleanly) .

Detailed explanation:

As the connection is set up, client and server negotiate their capabilities through a standardised handshake :

// 1. Client sends initialize request
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
  "protocolVersion": "2025-11-25",
  "capabilities": {
    "roots": { "listChanged": true },
    "sampling": {}
  },
  "clientInfo": {
    "name": "ExampleClient",
    "version": "1.0.0"
  }

Once initialisation is complete, client and server exchange messages in both directions: the client can call tools and read resources, while the server can send sampling and elicitation requests. Notifications (which expect no response) enable event-based updates .

2.5. What role does JSON-RPC 2.0 play in MCP?  

Short answer: JSON-RPC 2.0 forms MCP's message layer: all communication – requests, responses and notifications – is encoded as standardised JSON-RPC messages .

Detailed explanation:

MCP uses three JSON-RPC message types :

Choosing JSON-RPC 2.0 brings several advantages: the format is language-agnostic, well documented and lightweight. It supports both synchronous request-response patterns and asynchronous notifications. Two error types are defined: protocol errors (as JSON-RPC error objects) and tool execution errors (as a result with isError: true) .

The protocol version is exchanged during the handshake in a protocolVersion field; the current version is "2025-11-25" . Over Streamable HTTP, an MCP-Protocol-Version header is also sent with each connection .

3.1. Which transport mechanisms does MCP support?  

Short answer: MCP defines two official transports: stdio for local subprocesses and Streamable HTTP for remote servers. Both carry the same JSON-RPC messages .

Detailed explanation:

stdio is the simpler transport: the client starts the server as a child process and communicates through the standard streams. Each JSON-RPC message is sent on its own line. stderr is reserved for logging and must never contain protocol messages .

Streamable HTTP replaces the earlier HTTP+SSE transport. The client sends JSON-RPC messages as HTTP POST requests to the server endpoint, and the server either responds directly with JSON or opens an SSE stream over which several messages can be streamed .

3.2. What is the difference between stdio and Streamable HTTP?  

Short answer: stdio communicates through a child process's standard streams (simple, local); Streamable HTTP uses HTTP POST with optional SSE streaming (flexible, remote-capable, with session management) .

Detailed explanation:

With stdio, the client starts the server as a subprocess and communication works like this :

With Streamable HTTP, the server operates as an HTTP endpoint :

3.3. How does session management work with Streamable HTTP?  

Short answer: After initialisation, the server issues an Mcp-Session-Id, which the client then sends as an HTTP header on every subsequent request. The server can reject invalid or missing session IDs .

Detailed explanation:

Session management in Streamable HTTP follows a defined sequence :

This mechanism makes stateful connections possible over the otherwise stateless HTTP protocol. The server can hold session-specific data (such as active subscriptions or user context) and end sessions when needed .

3.4. What is resumability and how is message loss prevented?  

Short answer: Resumability uses SSE event IDs and the Last-Event-ID header to pick up seamlessly from where a dropped connection left off .

Detailed explanation:

With Streamable HTTP, connections can drop at any time – through network issues, timeouts or server restarts. Resumability stops messages being lost when that happens :

This pattern matters most for long-running operations such as large file exports or complex tool executions. Without resumability, the client would have to restart the whole operation from scratch after every disconnection; with event IDs, only the missing portion is re-delivered .

4.1. How do MCP Tools work – from discovery to execution?  

Short answer: Tools follow a four-stage lifecycle: discovery (tools/list), selection by the LLM, execution (tools/call) and dynamic updates via notifications .

Detailed explanation:

Each tool is described via a structured definition :

Tool results can return several content types: text, images, audio, resource links and embedded resources . For errors, MCP distinguishes between protocol errors (a JSON-RPC error) and tool execution errors (a result with isError: true), which allows for more nuanced error handling.

4.2. What are MCP Resources and how do they differ from Tools?  

Short answer: Resources are URI-identified, read-only data sources that supply context, whereas Tools carry out actions .

Detailed explanation:

Resources represent data that an AI application can pull in as context – much like GET endpoints in REST . There are two kinds:

Resources support a range of URI schemes: https://, file://, git:// and custom schemes such as calendar://events/2024 or trips://history/ . Their content can be text or binary (Base64-encoded).

The fundamental difference from Tools is that Resources have no side effects: they supply data but change nothing. They act as a context interface, whereas Tools are geared towards execution and actions .

Resources also support subscriptions: the client can register for change notifications and is informed whenever a resource changes. Annotations such as audience, priority and lastModified provide metadata for prioritisation .

4.3. How do MCP Prompts work and what are they used for?  

Short answer: Prompts are user-driven interaction templates that are discovered via prompts/list and invoked with arguments via prompts/get – typically surfaced as slash commands in the UI .

Detailed explanation:

MCP Prompts differ fundamentally from Tools and Resources in who controls them: they are triggered explicitly by users, not by the LLM or the application .

A prompt consists of :

A practical example: a plan-vacation prompt might expect arguments such as destination and dates. When invoked, the server builds a multi-part conversation from these, which the LLM then uses as a starting point for holiday planning – including embedded resources like trips://history/ for past trips .

Prompts also support multi-turn conversations: the server can return several consecutive messages with alternating roles to pre-structure complex interaction patterns .

4.4. What is sampling and how can a server request LLM completions?  

Short answer: Sampling lets an MCP server request an LLM completion through the client – without needing its own API keys. Users stay firmly in control via a human-in-the-loop approach .

Detailed explanation:

Sampling solves a practical problem: MCP servers sometimes need an LLM's help to do their job – for example to analyse unstructured data or make a decision. Without sampling, the server would have to manage its own API keys; with sampling, it borrows the client's access instead .

During sampling, the server can express model preferences :

The human-in-the-loop works in two directions: users can review and amend the server's request, and they can also inspect and authorise the LLM's response before it goes back to the server. The client has the final say – it can override the model choice, trim requests or reject them outright .

4.5. What is Elicitation and how does a server request user input?  

Short answer: Elicitation is a newer MCP primitive that lets servers request structured data directly from users – with JSON schema validation and three response actions: accept, decline or cancel .

Detailed explanation:

Elicitation addresses the case where a server needs information that cannot be inferred from the LLM context or from existing data. For example, a deployment server might need confirmation of the target environment before it proceeds .

The workflow runs as follows :

The JSON schema is deliberately restricted: only flat objects with primitive properties (String, Number, Boolean, Enum) are allowed – no nested objects or arrays .

5.1. Which AI applications support MCP as a client?  

Short answer: MCP is supported by a broad range of AI applications, including Claude Desktop, Claude Code, Claude.ai, VS Code (via GitHub Copilot), Cursor, Gemini CLI, Amazon Q, and numerous others. ChatGPT also offers MCP support; however, according to OpenAI, the extent of this currently depends on the plan, mode, and specific use case .

Detailed explanation:

Client support varies with the features each client implements. The MCP documentation tracks the following capabilities per client; for ChatGPT, you should also consult OpenAI's current documentation, since availability and permissions presently depend on the plan and mode :

Many other applications support MCP too: Cline, Continue, Goose, fast-agent, OpenAI Codex, 5ire, AgenticFlow, BoltAI, Chatbox and many more .

ChatGPT is currently a special case: according to OpenAI, full MCP with write/modify actions is in beta rollout for Business, Enterprise and Edu, while Pro supports MCP in Developer Mode with read/fetch permissions .

VS Code offers particularly comprehensive MCP integration: configuration via .vscode/mcp.json, sandbox support on macOS/Linux, auto-discovery of Claude Desktop configurations and CLI installation via code --add-mcp .

5.2. Which SDKs are available and in which languages?  

Short answer: Official SDKs exist in three tiers: Tier 1 (TypeScript, Python, C#, Go), Tier 2 (Java, Rust), and Tier 3 (Swift, Ruby, PHP). Kotlin is planned .

Detailed explanation:

All SDKs are maintained at github.com/modelcontextprotocol :

The tier classification reflects maturity and how actively each SDK is maintained: Tier 1 SDKs get the fastest updates for new spec versions, Tier 2 follows soon after, and Tier 3 with a slight delay .

5.3. Which reference servers does the official repository provide?  

Short answer: The official repository contains 7 active reference servers (Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, Time) and over 12 archived servers that serve as learning resources .

Detailed explanation:

The active reference servers at github.com/modelcontextprotocol/servers :

There are also over 12 archived servers in the servers-archived repository, among them AWS KB Retrieval, Brave Search, GitHub, GitLab, Google Drive, Google Maps, PostgreSQL, Puppeteer, Redis, Sentry, Slack and SQLite . These have since been spun out as independent projects and serve as reference implementations for a variety of integration patterns.

5.4. How do you build your own MCP server?  

Short answer: Pick an official SDK, define your tools, resources and/or prompts, configure the transport you want and register the server. A minimal server can be built in under 100 lines of code .

Detailed explanation:

Building an MCP server follows the same pattern whatever the language :

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
name: "weather-server",
version: "1.0.0",
});

// Define tool
server.tool(
"get-weather",
"Retrieve current weather for a city",
{ city: z.string().describe("Name of the city") },
async ({ city }) => ({

The official clients page documents which clients support which features – be sure to test your server with clients that support the primitives you have implemented .

6.1. Which security principles does MCP define?  

Short answer: MCP defines four core principles: User Consent and Control, Data Privacy, Tool Safety and LLM Sampling Controls .

Detailed explanation:

MCP's security architecture rests on the principle that the user remains the ultimate authority :

These principles are normative – implementations must follow them to be MCP-compliant. The host (the AI application) carries the primary responsibility: it must enforce the security policies, obtain user consent and keep different MCP servers isolated from one another .

6.2. How are tool calls secured (Human-in-the-Loop)?  

Short answer: Hosts must have tool calls confirmed by the user before execution. The LLM proposes a tool call, the host displays it, and the user approves, amends or rejects it .

Detailed explanation:

The human-in-the-loop model in MCP works on several levels :

Tool annotations support this process: readOnlyHint signals that a tool does not modify data, while destructiveHint warns of potentially destructive operations. Hosts can use these annotations to auto-approve safe tools and require extra confirmation for risky ones .

6.3. What are the risks of MCP and how can they be minimised?  

Short answer: The main risks are prompt injection (malicious content in tool results), excessive permissions and a lack of input validation. The countermeasures are strict validation, the principle of least privilege and server isolation .

Detailed explanation:

The specification recommends a defence-in-depth approach :

6.4. How does MCP handle data privacy and user consent?  

Short answer: MCP requires explicit consent before any data is shared, follows the principle of least privilege and puts hosts in charge of controlling the data flow between the LLM and servers .

Detailed explanation:

MCP's privacy model assigns clear responsibilities :

A particularly strict consent model applies to sampling: the human sees both the server's request and the LLM's response and can amend or reject either. This stops a server from making uncontrolled use of LLM capacity or feeding the LLM manipulative prompts .

The principle of minimal exposure means a server is given access only to the data it needs to do its job. Hosts should not make every resource on every server globally visible; they should deliberately control which server receives which context data .

7.1. What are the most important dos and don'ts when using MCP?  

Short answer: The key principles are focused servers rather than monoliths, strict input validation, meaningful tool descriptions and consistent human-in-the-loop control .

Detailed explanation:

7.2. What does the future of MCP look like?  

Short answer: MCP is evolving quickly, with new spec versions, a growing ecosystem and increasing industry adoption. New features such as Elicitation and Tasks (experimental) are extending what it can do .

Detailed explanation:

Several developments point to a strong future for MCP:

The ecosystem's momentum is especially striking: the MCP architecture documentation already lists experimental features such as Tasks (for long-running operations), Notifications and Progress Tracking . The open specification on GitHub lets the community contribute directly to its ongoing development .

7.3. How do I configure MCP in VS Code, Cursor or Claude Desktop?  

Short answer: Each host application has its own configuration method – VS Code uses a .vscode/mcp.json file, Cursor is configured through its settings, and Claude Desktop uses a local JSON configuration .

Detailed explanation:

The three most popular MCP hosts each configure servers differently:

{
"servers": {
  "filesystem": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-filesystem", "/pfad/zum/projekt"]
  },
  "github": {
    "type": "http",
    "url": "https://api.githubcopilot.com/mcp"
  }
}
}

Summary